I am the ghost of groovymother.com. Woooooo!

This is an old page from Rod Begbie's blog.

It only exists in an attempt to prevent linkrot. No new content will be added to this site, and links and images are liable to be broken. Check out begbie.com to find where I'm posting stuff these days.

Filed under 'softwareengineering'

January 23, 2012

Salary Negotiation: Make More Money, Be More Valued

“The first rule is what everyone tells you it is: Never give a number first” and other important info for engineers.

(Fun fact: The only time in my career I’ve ever offered an answer to the question “What sort of salary are you expecting?”, I gave myself a 33% bump over my then-current salary-and-bonus, and it was immediately accepted by the recruiter. I still wonder what I could have made.)

October 11, 2011

Rethrick: The Mythical Man-Month

Behind-the-scenes look at Google Wave - more around the struggle of big teams than about the product itself.

“Instead of shaving one Yak, you’re shaving the entire Yak pen at the Zoo, and pretty soon traveling to Tibet to shave foreign Yaks you’ve never seen before and whose barbering you know little about.”

May 28, 2011

Depression, Burn Out and Writing Code

“When your livelihood depends on what you can do with your brain, fighting depression and the fatigued fog that swirls around it is a frightening battle.” I agree with everything in this post.

March 3, 2010

2010 CWE/SANS Top 25 Most Dangerous Programming Errors

Every programmer should read this list now. If you don’t have a high-level understanding of all of these (and a deep understanding of the ones that affect the platform you build on), you’re dangerous.

March 1, 2010

Programming as an objective art

“Not to say older engineers aren’t emotionally invested in their work, in my experience they typically are, it’s just a matter of being better at picking battles.”

July 2, 2009

Stevey's Blog Rants: "Shit's Easy Syndrome"

I normally can’t be arsed with Steve Yegge, but this one is good — describing the very real disconnect between “I have an idea!” and “How will that idea work in practice?” (Read at least up to where he goes off on Marijuana legalization — it becomes repetitive at that point)

April 21, 2008

The book that is indirectly responsible for me getting my new job

A few months ago, I was in the pub with a couple of geekchums. The topic of job interviews was going round the table, in part because I’d been talking about my goal of getting a job and moving to the Bay Area. Someone mentioned that they’d interviewed at Google, had read Programming Interviews Exposed the night before the interview, and nearly every question they’d been asked was pretty much out of the book.

This caught my attention, because a few months earlier I’d had a phone interview with a division of Google that rhymes with TouYube which had gone pretty well until they pulled out one of those algorithmic questions that Google loves; Something about finding the median value in two sorted lists of integers. I’d come up with a solution, but clearly not a satisfactory solution. (As Keith later described it, every Google interview question has to have an O(log n) solution… and at that time, Big O notation hadn’t been on my radar in freakin’ years). The next day, the recruiter called to say they’d decided to pass on me.

So, the morning after the discussion, once the hangover had subsided, I ordered myself a copy. I read the whole thing in a few days, absorbing details about graph theory, pointers, recursion and, oh yes, Big O notation that I hadn’t thought about since receiving my CompSci degree 10 years ago.

But more important were the example interview questions throughout the book. Generally these would be structured as the question, followed by a naïve solution, a better solution, and then any follow-up questions or limitations the interviewer might introduce. For example, if you get the classic “Reverse the order of words in a string” question, it guides you through the initial solution of “Start at the end of the string, scan backwards, and when you find whitespace, copy the word to a temporary buffer, then replace the original string with the new one”, then explains what to do when the interviewer inevitably asks you to do it without using another buffer (reverse the whole string, then iterate through reversing the characters in each word).

A week or so later, I had a phone interview and was able to answer algorithmic questions speaking authoritatively about binary trees and heaps. That was enough to get me flown out to SF for in-person interviews, which at one point included a question word-for-word out of the book!

All that said… For a variety of reasons, I didn’t take that job. It just helped because I first spoke to Current during the weekend I was in town for the interviews, and got a chance to spend some face-to-face time at Current’s offices that day.

(In fact, the interviews with Current went by without a single algorithmic pointers-and-big-O question. And to me, that was a good sign, because as I say, I haven’t cared about that shit in 10 years—In my line of work, rather than optimizing lines of code, I’m more to get more bang by tweak a SQL query or throwing memcache at a problem.)

Which raises an interesting question: Is reading this book cheating? Is it the equivalent of just reading the answer key before an exam? In my opinion, no. For two reasons:

  1. For the most part, it was just refreshing details I’d already learned during my CompSci course, but had filed away in the trashcan of my neurons, along with “Where’s the best deep-fried pizza in Edinburgh?”, as no-longer relevant to my life. This book probably won’t help too much if you don’t have the first clue about pointers or recursion to begin with.
  2. If your ability to answer algorithmic questions is the only (or most important) thing the employer is rating you on when you interview you, then they’re fucking idiots and will get everything they deserve.

The book is just a handy tool for your belt when preparing for interviews, to get your mind in the right place to push past the algorithmic questions so you can present all the other amazing reasons why they must hire you right now. Similarly, I highly recommend reading Joel Spolsky’s Smart and Gets Things Done and Rands’s guide to how your resumé is being read for an idea on what the person on the other side of the phoneline or table is (or should be) thinking.

But without this book, I might not have passed that phone screen, and thus might not have been in SF when Current called, and might not have met with them, and might not have gotten excited by the opportunity, and might not have the job I have now.

And for that reason, I unreservedly recommend this book to every software engineer who might be on either side of the interviewing process soon.

January 21, 2008

hudson: an extensible continuous integration engine

This looks worth investigating — Continuous integration server that can also monitor other jobs (eg. cron jobs or backups), then serves the results at RSS, email or IM alerts.

September 21, 2007


JUnit test tester. Works by changing your code and making sure your unit tests break! Wonder if there’s a Python version…

August 21, 2007

Selenium Remote Control: About

Saw a presentation on this at BarCampBlock, and I absolutely have to delve into it further. “Selenium Remote Control is a test tool that allows you to write automated web application UI tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser.”

August 3, 2007

Welcome to Hadoop!

Open-source project to allow the creation of massive massively-parallelized systems. I’m so glad my CompSci course taught me about parallel programming in 1997, because it’s only going to become more important.

July 26, 2007

Beautiful Code: Leading Programmers Explain How They Think

Just picked this up, and a quick skim shows it’s something a bit special: Learn good coding practices by reading experts choice of “the most beautiful code they’ve seen”, with plenty of commentary. I’m halfway tempted to take a day off next week and just sit and read this all day.

July 17, 2007

The Fishbowl: Understanding Engineers: Feasibility

Every person who has any contact with software engineers Must Read This. Accurate definitions of the oft-used words “impossible”, “trivial”, “unfeasible”, “non-trivial”, “hard” and “very hard”.

May 11, 2007

Violet UML Editor : easy to use, completely free

Free open-source simple UML editor that plugs-into Eclipse. Recommended by co-workers.

May 9, 2007


Capturing for posterity my scribblings from a mailing list discussion:

The “You can’t have 2 women deliver a baby in 9 months” metaphor always bugged me, because there’s no room for changing scope in that (You can’t opt to just birth the torso in 5 months, then add the head and limbs at a later date).

My preferred metaphor for explaining the mythical man month is that of getting a piano up a narrow stairwell. One person trying on their own would take ages, and there’s a high risk of failure. Two or three can probably get it done reasonably quickly. But if you try to get eighty people to do it, they’ll spend ages arguing about how to go about it, get in each others’ way, and in the end, two or three of the more productive ones will probably do most of the heavy lifting while the others stand around.

I usually illustrate this point with a shot of Laurel & Hardy from their 1932 classic The Music Box

(A quick Google shows that I nicked this metaphor from this blog comment.)

March 14, 2007

Adobe edits the development cycle | Reg Developer

Some good thoughts on how to manage code quality in a product development world. “Probably the most effective thing we did was institute per-engineer bug limits: if any engineer’s bug count passes 20, they have to stop working on features and fix bugs instead. The basic idea is that we keep the bug count low as we go so that we can send out usable versions to alpha testers earlier in the cycle and we don’t have the bugalanch at the end.”

November 4, 2006

Software by Rob : Nine Things Developers Want More Than Money

It would just seem like bragging if I were to say how many of these (at least my corner of) RhymesWithNose meets.

Filed under : :
via |

June 13, 2006

Raganwald: My favourite interview question

Interesting article. Though I like the Monopoly question, I think I’m going to steal the “design a control system for an elevator” one from the comments for the next time I interview someone.

April 12, 2006

MONEY Magazine's Best Jobs: Software engineer

Apparently, I have the “Best Job in America”. Can’t say that I disagree with that statement. Good software engineers should be able to find jobs they love, or at the very least, jobs they hate that pay staggeringly well.

Filed under : : :
via |

April 8, 2006

It's Enterprisey

This is why I’m such a hack. I just don’t think Enterprisey-enough.

March 30, 2006


“Daversy is a source control tool for relational databases.” Man, something like this has been needed for years.

January 18, 2006

What Works In Software Development

A really good summary of the best bits of Agile, XP, etc. plus some common sense. Turns a bit Perl-centric near the end, but that aside it’s an excellent read for software engineers.

December 27, 2005

Seven Habits of Highly Effective Programmers

Some excellent tips for living the programming life, with plenty of examples.

November 7, 2005

Visual Studio Express

Microsoft have release the various versions of Visual Studio Express for free. Very smart move on their part — It reduces the cost of Windows programming to essentially zero for those who aren’t willing to pay, and MS can make up the money with their “professional” Team solutions and MSDN subscriptions.

November 2, 2005

Producing Open Source Software

Free ebook on the hows and wherefores of running an open source project, from someone who’s been round the block a couple of times.

October 5, 2005

A lot of people have the phone number (214) 748-3647

Which, coincidentally, is the largest number that can be held in a 32-bit integer. Remember, kids: Just because it’s a number, doesn’t mean you should store it in a number database field.

Filed under : : :
via |

September 9, 2005

Why Good Programmers Are Lazy and Dumb

Compare with Larry Wall’s “Laziness, Impatience, Hubris” virtues of a programmer theory.

Filed under :

About This Site

This is an archive of groovmother.com, the old blog run by Rod Begbie — A Scottish geek who lives in San Francisco, CA.

I'm the co-founder of Sōsh, your handy-dandy guide for things to do in San Francisco this weekend.