Checking Your Assumptions
Wednesday, April 2nd, 2008 by Enrico
Jeff Atwood recently wrote about what he calls The First Rule of Programming: it’s always your fault. That is, we should resist the temptation to blame the OS, the tools, the framework, and other technologies when the problem might still lie with our own code. To explain some of the merit in this idea, he quotes an anecdote from The Pragmatic Programmer about a senior programmer who was solidly convinced that an OS system call was buggy until he was forced to read over the documentation carefully. Once he fully understood how the system call was actually supposed to work, he fixed the problem in his own code within a few minutes. This story reminds me of many debugging sessions I’ve had while working at Tenthline.
One very common scenario we run into, especially when learning new technologies, is going over misbehaving code that we’ve written with a fine-toothed comb and not being able to identify a single problem with it. At that point, it’s all too easy to jump to the conclusion that there’s something wrong with the technologies that we’re using. Then, without fail, Michael always says “wait a sec, let’s check our assumptions.” At that point, we start analyzing the code very carefully to see if we’ve made any implicit assumptions about the way that the code we’re calling on works that actually aren’t true. After all, sometimes abstractions leak or we’re in such a rush to apply the technologies to what we’re working on that we skip over some of the important details when reading the documentation. If our assumptions turn out to be incorrect, it is usually much easier to fix the problem in our code from there. And even if we can’t fix the code, we still end up with a fuller understanding of the problem.
Even if it isn’t always our fault, I think that it’s definitely a good habit to force ourselves to assume that it is. At the very least, it forces us to do extra work to fully eliminate the possibility that the fault lies with us instead of just jumping to conclusions.
Tags: Programming
April 4th, 2008 at 2:12 pm
It’s not just programming, oh no.
In Windows, when you have Windows Explorer open, if you tap a key, it will take you to the first file starting with that key. Tap it again, and it will iterate one down the line.
This behaviour does not exist on Macs. In fact, I was continually annoyed when I would have my application window open and wanted to get to CocoaMySQL. The first c would do what I expect, the second, to something entirely random (to me).
I was complaining about this to Enrico one late night when he pointed out that it was actually trying to match the entire string of letters I typed in a short bit of time. That is, if I type “Sh” I’d find it matching “Shoes.app” instead of matching the first thing that started with h — the default windows behaviour.
This is a much better way of doing things, but it confused me because, up until recently, I was using a different operating system.
Check your assumptions indeed.
April 4th, 2008 at 3:42 pm
Really, it’s a general statement on troubleshooting and solving problems in general. Bad assumptions keep us away from the actual facts and those are what we need to solve the problems we face.