Skip to content
January 21, 2013 / alipeles

6. Always look for the bug in your own code first

  • Check whether you made a mistake before blaming someone else
  • Rushing to blame others reflects little concern over your own quality
  • Second-guessing your own work can be valuable, even when it’s not your fault

 
A new colleague promised to meet you for coffee at noon. It’s now 12:15, you’re sitting alone at Starbucks, and you haven’t heard from her. Which is your first instinct?

a)    Send her a note asking how long she’s going to be

b)    Check your email to make sure you’ve got the right time and place

You may later find out that she’s disorganized or even just plain blew you off. But, you still want to be the kind of person who answers b, because being darn sure you’re right before you point to someone else makes you organized, efficient, and a good team player.

In software development, we have a special case of this principle. Software projects build on the work of other developers: stockpiles of legacy code, open source, standard libraries, vendor packages, work currently being done in parallel, etc. When a programmer makes a mistake (e.g. passes along bad data), it’s likely to make some of this other code in the project misbehave or even fail. So, when something goes wrong, the rule is always to look for the bug in our own code first.

I once had the misfortune to work with a software developer who held near perfect faith in his own genius. When he ran into difficulties, he would look anywhere for a smoking gun instead of in the code that he had just written. I would walk by his desk and find him debugging Microsoft’s libraries or ages old company code in order to find “the problem”.

Of course he was arrogant to assume that somebody else made the mistake. He was also terribly inefficient, wasting his time and that of others on wild goose chases. First, all of that other code in the project (the code he didn’t write) gets used by lots of other people all the time. So, it is highly likely that other developers have already found the really glaring bugs. And second, it’s very hard to debug code that you don’t know very well. So, it’s much easier to rule out your own work, first.

But, the worst consequence of jumping to the conclusion that “someone else messed up” is that it belies sloppiness. Careful people take pride in their work. Any hint of a flaw scares them into doubling back to verify. Someone who hurries to blame others isn’t too fussed about the quality of his or her own output.

Looking for the bug in your own code isn’t just a good rule for programmers. When anything goes wrong, start by figuring out whether you did everything right. If someone didn’t follow your instructions, were your instructions clear enough? Did you effectively communicate the importance of following instructions? Did you give the assignment to the right person?

If it turns out that it wasn’t your fault, you’ll still likely learn something about how to shield yourself from other people’s foibles. E.g. next time, maybe you should reconfirm the same morning that coffee with your possibly flaky colleague is still on for noon.

By the way: The right way to go after an actual bug in someone else’s code isn’t to open up the hood and look for the error directly, but to construct a simple example of your own that pinpoints the issue and proves the bug is there, eliminating all risk of confusion and false accusation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: