If you’re a tech company, chances are you have some kind of code review process. But first we should ask…
What is code review?
It simply means someone spending time specifically to read someone else’s code. Software is made up of code. We write the code that make up the software, then release the software into the wild. It is possible for this to happen without anyone ever having to read someone else’s code — for example, if it were a solo project.
Now, anyone can read code. You just open up a file that someone else wrote, and you look at it. But what makes code review a process? First, you must make time to read code. Then, you put rules in place so that no code can be released to the next stage without being reviewed. And voilà — you have a code review process.
Does it actually… work?
The most common justification for code review is that it catches bugs.
That might be true. We get careless when writing code. Having someone else look at your code can be a great way to find gaps in your logic that you yourself have failed to find.
Even so, bugs may still make it past the code review process and into the next stage. Why? The fundamental problem is that reading code in and of itself doesn’t work all that well. For simple pieces of code, a quick look may suffice. But for more complicated code, you’ll need to spend more time examining it, or even pull the code onto your computer and run it yourself to be really sure.
In general, the more time one spends reviewing code, the fewer bugs potentially make it through. And the more complex a piece of code is, the more time it takes for someone to review it.
On the other hand, we can also address the source of the bugs themselves. The author of the code can produce fewer bugs to catch in the first place. As they say, git gud. However, this would either mean a) you hire stronger developers, b) you make time to train your developers, or c) you give your developers more time to write the code, so that they don’t cut as many corners. All of which is expensive.
What this points out is that code review can serve as a short-term cost savings, likely at the cost of long-term value.
Pre-commit
Up until now we’re only talking about pre-commit code review — the act of reviewing code before it moves on to the next stage. As such, code review is a way to block potential bad outcomes.
While pre-commit checks are indeed very useful, code review may not be the most effective tool in the pre-commit arsenal. Computers are much more efficient than humans at analyzing code in certain ways — such as linting, type checking, and occasionally thread safety. You could also write automated tests so that computers do the work of checking business logic for you. Of course, building up automation requires time and effort.
What this points out is that code review can serve as a lower-cost replacement when certain complex problems demand advanced solutions.
Sowing seeds
One can also argue that code review creates space for engineers to interact with each other in constructive ways. During code review, engineers leave comments, point things out, refer to best practices, offer advice, and lead by example. Code review can also be used to enforce certain coding conventions across the team (which would otherwise not be addressed by automated pre-commit checks) and generally keep the code in as good of a shape as possible.
What this points out is that code review can be used as a means for both mentorship and stewardship. While it is useful for that purpose, good mentorship consists not only of code review, but also other things. And good code stewardship is a continuous, habitual process, the majority of which occurs outside of code review contexts.
Closing thoughts
At the end of the day, it turns out that code review is a temporary patch for many things. And like so many other temporary things in the industry, it ended up becoming a permanent fixture.
Nonetheless, there is no quick cure-all for just getting good and writing quality code, or for designing intelligent processes around engineering, or for a continuous habit of mentorship and stewardship. The limiting factor for us is always going to be time. And of course time costs money.