Why We Overlook Our Own Coding Mistakes

During code reviews, whenever someone finds an issue with my code, I feel a pang of guilt. How did I miss that public visibility modifier, and why am I a software engineer if I’m not capable of catching such problems in my own code? Self-doubt sets in.

Then I review another open PR. My inner Sherlock Holmes comes into play. Amazingly I find several glaring errors, including those around visibility modifiers.

What is going on?

The code review double standard is common, and something familiar to software developers.

One second you’re a frightened rabbit, in a long night of getting lost unable to find the obvious issues in your own code. I’m sure we’ve all had the experience of combing through our own work trying to make it as good as possible, only for it to be ripped apart by senior developers. You’ve produced the absolute best code you think you can, and then you see that it’s not quite good enough.

*Image by DALL-E 3 and The Secret Developer*

When you’re reviewing code you find spotting trivial mistakes (and larger more consequent errors) easy. It seems like you’re wired to downplay your own mistakes while amplifying those of others and ignore the risk of damaging the relationships with those around you.

Why does this happen, and what can we do about it?

Cognitive bias

When you think that you are right, you think that you are right even when information comes in to tell you the opposite.

*Photo by* *BUDDHI Kumar SHRESTHA* on *Unsplash*

This is confirmation bias, where people favor information that confirms their existing theories (and you’ll have the theory that your code works) and end up disregarding information that contradicts them. Since so much time and effort are engaged in writing code you are vulnerable to this phenomenon.

You might have previously felt this when you insist that your code is correct even though your tests are failing (probably the compiler is broken).

It’s a natural human tendency but one that needs to be managed, especially since continuous learning is crucial in the field.

The Real-World Impact

This isn’t all about visibility modifiers, errors picked up in code review can be vital in our journey to creating great software.

*Photo by* *Elyas Cile* *@elyas_cile in Unsplash*

The damage can be caused by toxic environments where code review became a nitpick game of one-upmanship. Developers dreaded reviews because they felt that they’d be unfairly scrutinized while senior reviewers got a free pass. Ultimately this led to a slow development process and a release schedule that slowly became a nightmare.

We can all find nitpick problems in other’s code. That shouldn’t be the object of the exercise, we should all aim to create great software.

Fighting the Bias

We need to work to fight the tendency to overlook our own bugs, but luckily we have strategies to overcome this very real issue.

*Photo by* *Super Snapper* *@supersnapper27 in Unsplash*

Peer Programming

Pair programming can help because it forces you to explain your thought process as you code. It’s harder to miss something when someone else is watching your every move.

Automated Tools

Linting tools and automated code review software can help catch common mistakes, taking some of the bias out of the equation.

Breaks

Take a break before reviewing your own code. A little time and distance can make your own bugs more apparent.

Team Reviews

Encourage a culture where everyone’s code is reviewed by at least two people. This makes it less likely that biases will slip through the cracks.

Self-Reflection

Simply being aware of the bias can make you a better reviewer. Next time you’re looking at your own code, try to adopt the same critical eye you use on others. Have a generous heart towards both yourself and others.

Conclusion

Struggling to find bugs in your own code while finding it incredibly easy to tear apart someone else’s? It’s not just you.

The double standard is real, and it’s baked into our psychology. The trick is to recognize it and then do something about it. Great code isn’t written, it’s rewritten and built for the future. It’s a team sport, and we should take feedback from wherever we can get it — just make sure that you can accept comments in the same spirit as you give them, with generosity and a loving spirit.