Managing Programming for CEOs Part 4 – Great Debuggers

Great programmers are all great debuggers (although not necessarily vice versa) since much more time is spent debugging code than writing it in the first place. Great programmers are orders of magnitude more productive than run-of-the-mill programmers so you really want to hire them if you can.  However, great debuggers are easier to spot so let’s start there.

The great debuggers have iron control over their egos and an uncanny knack for splitting a problem in half.

Debugging for a programmer is the science of finding your own mistakes.  Ego constantly gets in the way because it tells us that we didn’t make a mistake, couldn’t have made a mistake.  Maybe the Java engine is faulty or the compiler generated faulty code.  Must be that Windows or the Macintosh Toolkit is broken.  Usually its our own mistake that causes a program to crash or perform other unsociable acts and we have to beat back the voice that says it’s someone else’s fault before we can find what we did wrong.

Experienced debuggers make good proofreaders, even of their own material.  A comma instead of a semicolon sticks out like a sore thumb to me whether it’s in text or in code.  That’s because, in so many of the programming languages I used, a comma instead of a semicolon made a world of difference in what a computer was going to do when my program ran.

Now let’s talk about splitting a problem in half.  Pick a number, any integer between one and 1000.  I can guess what it is in no more than ten guesses so long as you tell me whether I’m right, high, or low on each guess.  Obviously, that can’t be done by either random guessing or starting at one end or the other of the range.  The first guess is 500.  Whether I was high or low, we’ve now eliminated half of the possible numbers.  If I was low, next guess is 750; if I was high, next guess is 250.  Either way, there are only going to be 248 possibilities left after two guesses (unless I happen to hit the nail on the head).  Two to the tenth power (2^10) is 1024 so I’m always going to be able to narrow down to the integer you chose from within the range of a thousand in, at most, ten guesses.

OK, so if you’re at all mathematical, you knew that.  But it’s amazing how many people who should understand the importance of splitting a problem in half with each test do their debugging sequentially.  Is the problem here?  No, try the next possibility.  Is the problem here? No, try the next.  That’s like guessing the number by starting with one and counting sequentially until you get there.  Five hundred guesses on the average to find one out of a thousand numbers instead of a maximum of ten when you do binary reduction as in the paragraph above.

There can easily be millions of places where a bug is hiding.  If you do a binary search of a million elements, it will take, at most, twenty tests to narrow down to one possibility – two to the twentieth power (2^20) is 1,048,576.  In the real world, tests usually can’t be developed which neatly eliminate half the possibilities at each stroke but you can come pretty close if you try.  Or you can just proceed sequentially: one? no. two? no…  If you don’t mind taking forever to debug.

By the way, these debugging principals are useful for much more than programming.  They are the right way to find a leak in a pipe, a break or a short in an electric line, or a disease in a patient.  Binary search can be used to identify a target market, capture a thief, or find an accounting error.  And suppression of ego is even more valuable in figuring out where you’ve gone wrong and how to go right.

But you’re the CEO now, or want to be, not a programmer.  How do you spot these great debuggers?  For one thing, in an interview it’s easy to get them to tell you how they’ve learned from their own mistakes.  People who don’t know they make mistakes or can’t talk about them aren’t great debuggers so they can’t be great programmers.  Second tell-tale trace of great debuggers is their approach to problem solving.  Give them a problem without enough information to solve it and see whether their questions to you about the problem are a binary search – narrowing down the possibilities with each probe – or whether they take a sequential approach.  Great debuggers are always great at twenty questions but you may feel a little silly playing that in a job interview.

Part 1 of this series is a phrase book of programmer-speak.

Part 2 is the meaning of “done” and how to know when you’ll get there.

Part 3 is about features that kill projects.

I’ve also blogged on how programmers can manage CEOs.

Part 1 is on managing non-technical CEOs.

Part 2 is on the even harder job of managing technical CEOs.