Reliable Systems

One of the first things I’m listening for when interviewing developers is for how they relate to problems with authoring code, namely how do they approach a defect. Depending on how much experience they have and how much they’ve thought about it, I’ve found developers go through three levels of Zen when considering problems:

It’s Not the Compiler

Similar to the classic discussion that Select isn’t Broken, every developer when first starting out runs into something they are just sure is the compiler’s fault. The code is right, the compiler just doesn’t agree. It may be tempting to even use #pragma or the equivalent in the language to get rid of the warning or error.

In the end, it isn’t the compiler, it’s your code. Try explaining carefully and thoroughly to another developer why the code is right and the compiler is wrong, and most of the time in the middle of your explanation it’ll hit you what the real problem is, and that the compiler was right (if perhaps obtuse in how it is reporting the problem). This is an excellent trick to breaking through cognitive bias: Explain to someone else exactly why the world is flat, and in so doing your mind will often make the creative or fresh jump to what the real problem is.

It’s In Your Code

It’s one thing to trust the compiler – compilers have generally matured over decades, and even newer languages like C# and Java have very low defect rates of compiling because even if the syntax is new, the basic lexical parsing is very close to C++ and the long standing family of engineering behind it.

If the compiler is the most trustworthy code, what’s the least trustworthy? The code you’re writing right now. Everything else is more tested and more reviewed. In general, the probability you’re going to run into a defect in an operating system library or framework is relatively low, low enough compared to the probability of defects in your own code as to be statistically insignificant.

Even in areas of high churn, like evolving web standards and CSS for Internet Explorer, if the output isn’t right the defect is virtually guaranteed to be in your code.

It Doesn’t Matter Where It Is – You Have To Fix It

The ultimate evolution of this thinking is practical: It doesn’t matter where the defect is, you have to fix it – and you have to fix it in your code (or at least code you control). In the end, you’re writing software to deliver features for someone, and you’re only successful if it works. They really aren’t going to care whether you can’t make headway because of a problem in your code, an underlying library, or the operating system: They all produce the same effective result of the feature not working. So in the end, it isn’t a question of who’s right but rather what you’re going to do to resolve it.

There is some danger in this last point. There is a fine line between pragmatically realizing you have to make it work one way or another and just hacking away at a problem you don’t understand under the assumption that you’ve found an underlying defect you need to work around. Before you assume this is the case, you should prove not just to your satisfaction you’ve found an honest defect in another library but seek some independent evidence of this: A knowledgebase article, defect report from the library owner, or at least corroboration of your peers is a good place to start. Developers that charge straight to attempting to work around a perceived defect in a library without verification are really back at the first level.

Listen To Where You Are

When I’m talking with developers, I can usually find out where they are by listening for key phrases, such as “it works on my box.” If you hear that and it’s offered in anything other than a sheepish or self deprecating tone, this developer probably has a way to go. Listen to your own language – what do you say when you run into something? If you find yourself getting into a cognitive bias death spiral, that’s the time to get up, take a break, and come back to it. Repeating my favorite trick: Go find a talented friend to explain just how right your thinking is. In my experience, that exercise invariably has me figure out where I’m off track even if the other party can’t follow what I’m saying.

Editors Note: Sometimes you let an article spend too long cooking before you publish it. Jeff Atwood came at this from a very similar angle on Coding Horror while this was in review. Check out his article as well.