Why Your Code Isn’t as Great as You Think
Photo by Craig Lovelidge on Unsplash
That feeling comes around every so often. How did I miss that public visibility modifier? When it’s caught at code review, I ask myself if I’m worthy of being a software developer — self-doubt sets in, coupled with imposter syndrome.
I move on. I decide to review an open PR. My inner Sherlock Holmes suddenly springs to life. I find several glaring errors, including those around visibility modifiers that I just couldn’t find in my own code.
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.
Image by DALL-E 3 and The Secret Developer
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 Amanda Sandlin @amanda_sandlin on 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 David Clode @davidclode on 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.