Cognitive Biases in Programming

As developers, we’re familiar with the various problems that interfere with our productivity. But often we overlook the broad picture. Some subtle, some huge, some you can do something about, and some you just, well, can’t.

These all combine to form a sort of internal feedback loop that can lead to lost hours of productivity, bugs, and just all-around frustration. If we can minimize the impact of one or two of these, we can break the cycle and neutralize the rest. Here’s a list of 5 cognitive biases you should be aware of while programming:

Hyperbolic Discounting

Going for an immediate payoff instead of a delayed larger one

Have you ever delayed writing a test? Have you ever found yourself using the arrow keys in Vim? Congrats, you exhibited hyperbolic discounting. The immediate payoff of using the arrow keys far exceeds the pain you have to go through to find the right syntax to navigate to the correct line. However, once you learn how to navigate faster, the payoff in future is far higher. You end up saving a lot of time.

IKEA Effect

Overvaluing your own solutions to a problem, and thus in contrast undervalue other solutions

The IKEA effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. We tend to overvalue our own solutions to a problem, and thus in contrast undervalue other solutions. If you’ve ever worked for a company that used a dumb internal tool rather than a better out-of-the-box solution, you know what I’m talking about.

Premature Optimization

Optimizing before you know that you need to

Self-explanatory. Adding an aerodynamic spoiler wing on you old car before fixing the engine wont help it go much faster. A great example of this is writing the perfectly tuned and performant code on what is ultimately a mere experiment.

Planning Fallacy

Optimistically underestimating the time required to complete a task

Planning fallacy is one that most of us should be able to relate to. Whether it’s us, or project managers, or those using our products, we all tend to be optimistic as to when we’ll actually finish. This is well demonstrated by the old aphorism,

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Recency Bias

Placing higher value on recent events than ones that occurred further in the past

Recency bias often hits us when we need a solution for a problem and, hey, we just solved a similar problem so let’s use that solution because it worked, and we remember it! Do you find yourself using the same design patterns over and over again? If yes, you’re probably looking at different problems from the same lens.

We can never completely eliminate our biases, by being aware of how it is affecting us, we can somewhat mitigate the problems it causes.

Thanks to Rob Trame for helping me with this. Image courtesy clipartfest.com.