Lend me your eyes and read this article about the importance of code reviews.
In a recent job interview, I mentioned that I tend to be a bit of a nitpicker when reviewing pull requests, albeit in an ever-gentle manner. As a follow-up, I was asked why I thought code reviews were so important. Unfortunately, I only managed to blurt out a few phrases like code quality and knowledge sharing – job interviews bring out the best deer-in-the-headlights version of me. In this article, I'll try to elaborate on my out-of-tune answer.
The most obvious reason to do code reviews is to catch errors, enforce codebase standards and suggest improvements related to efficiency, readability, or maintainability. To put it slightly more dramatically: unless it's part of a deliberate strategy to deliver quickly and refactor later, it's your last chance to stop technical debt from piling up. For some developers, that's all a code review is – a gatekeeper for quality. But guess what? There's a lot more to it. Otherwise, this article would be ridiculously short.
Are you sad because you're on your own?
Have you ever been on a team where everything grinds to a halt because the one VID1 who knows how to fix the broken service is out? Yes, I'm certain that it happens all the time. Code reviews are a simple way to break down developer silos – though it might take a bit of patient persuasion to get that VID to open pull requests and tag reviewers.
Whether it's about getting to know a project, dipping your toes into a new technology, or understanding an unfamiliar algorithm, I see every PR I review as a learning opportunity – and so should you. This, along with having backup developers, falls under the umbrella of knowledge sharing.
Could it be anybody?
Code reviews can be a powerful democracy-enabler within teams. There's often an imbalance between team members, whether due to seniority or codebase knowledge. This can lead to both conscious and unconscious beliefs that one opinion matters more than another2. While code reviews don't erase these hierarchical differences, they do help soften them.
Reviewing also promotes shared ownership: the quality of the work is the responsibility of both the author and the reviewer(s). This fosters better team collaboration, reduces finger-pointing and increases pride in the work. Dare I say it? Two (or more) brains working together are generally better than one.
What do you see when you turn out the light?
Where pair programming is clearly the extrovert's playing field, the pull request is a natural habitat for introverts (like me). While I see the value in occasionally working together on the same task, I think I'd find it rather stressful as a structural approach3. One could also argue that pair programming isn't a substitute for code reviews, since the setups are different: when you're pair programming, you might be biased towards your partner's view, while you normally approach a code review with a fresh perspective.
In that light, I should also briefly mention tests. On the one hand, they are absolutely necessary and offer a certain degree of trust; on the other, they're still code that could contain bugs or fail to cover all use cases. To ensure a healthy codebase, you need both a comprehensive test suite and proper code reviews. Two things are true.
Would you believe in approval at first sight?
Of course, you can't achieve any of the above if you don't take code reviews seriously. That means putting in the time and effort to run the code and understand the changes – always approving without comments quickly becomes suspicious. Everyone approaches them a little differently, but it's a good idea to define a baseline within your team – both for reviewing and creating pull requests. A few pointers on the latter: keep the PR size limited, make small and meaningful commits, and provide context when needed.
As a curious end note, I've always wondered why the practice of reviewing is so ingrained in the world of software yet often absent in other fields. Wouldn't everyone benefit from a second pair of eyes checking their work? Either way, the next time they ask me this question in a job interview, my answer should be ever so slightly more robust.
Gonna try,
Johan
