Reviewing code is a skill
Reviewing code is a skill
Intended audience: Software developers interested in getting better at developing software. Initially, I meant this post more for junior developers, but some parts are more applicable for tech leads etc. So if the post appears a bit muddled, please accept this apology from my inner Pascal, “Sorry, I did not have the time to break it up into two posts.”
In developer communities, there has been a lot of discussion<br>on code review, especially over the course of 2025-2026.<br>For example, you may have seen claims like:Not necessarily all from the same people.
“Code review is the bottleneck”
“Mandatory pre-merge code review is for low-trust environments; you should push directly to main”
“Code review doesn’t find bugs”
“Code review is not for X, it’s for Y”
“LLMs are better than humans at reviewing code”
“LLM code reviews are much better than humans at finding edge cases/bugs”
“You should stop looking at the code; you should be doing XYZ instead”
and so on.
Out of this, zooming in on “Code review is not for X, it’s for Y”<br>for a moment, the research has the following to say:
By coding our interview data, we identified four key themes for what Google developers expect from code reviews: education, maintaining norms, gatekeeping, and accident prevention. Education regards either teaching or learning from a code review and is in line with the initial reasons for introducing code review; norms refer to an organization preference for a discretionary choice (e.g., formatting or API usage patterns); gatekeeping concerns the establishment and maintenance of boundaries around source code, design choices or another artifact; and accidents refer to the introduction of bugs, defects or other quality related issues.
– Modern Code Review: A Case Study at Google (2018)
Similarly, Expectations, outcomes, and challenges of modern code review (2013) points out:
Our study reveals that while finding defects remains the main motivation for review, reviews are less about defects than expected and instead provide additional benefits such as knowledge transfer, increased team awareness, and creation of alternative solutions to problems. Moreover, we find that code and change understanding is the key aspect of code reviewing and that developers employ a wide range of mechanisms to meet their understanding needs, most of which are not met by current tools
So at least, hopefully we can agree that code review<br>serves many purposes.
I will get to the other points in a bit.
But before that, I want to articulate a framing which I haven’t seen much elsewhere.<br>Namely, that reviewing code is a skill. Specifically, I posit that:
It’s possible to get better at reviewing code. By “better”,<br>I mean across all of the purposes above: catching bugs,<br>catching design issues, increasing one’s awareness of what’s<br>going on, and understanding the code.
It’s possible to teach someone to get better at reviewing code.
By virtue of it being a fairly modern skill, we don’t quite know<br>where the human skill ceiling lies<br>(e.g. what is the Pareto frontier in terms of speed vs quality?).
If you’re a software developer, and if you believe that people<br>will continue to be involved in the development and maintenance<br>of programs for the foreseeable future, then it’s valuable<br>to get better at reviewing code.
First, I will give three small examples taken from the<br>past few weeks of work of me finding bugs when<br>reviewing code. I’ve specifically chosen bugs for discussion because<br>they’re relatively unambiguous.
Next, I will provide some of my own historical background<br>related to code review, and some arguments in favor<br>of the core thesis.
After that, I discuss some ideas for experimenting with<br>and improving code review.
Finally, I discuss the aforementioned oft-repeated memes around<br>code review and how they hold up to scrutiny with<br>the thesis in mind.
Let’s get started.
A tale of three almost-introduced bugs
A bunch of details have been elided in the course<br>of explaining the different examples below,<br>in an attempt to make them digestible.<br>It may be valuable to keep an eye on stray thoughts of the form,<br>“well, that seems like a code smell, no wonder you almost had that bug”<br>or “duh, this could’ve been avoided with XYZ”.
In two out of the three cases, the person who wrote<br>the PR had experience with the surrounding code.
The other thing to note is that LLM reviews<br>with a mixture of high-end coding models (around Jun 2026)<br>were run for all of the PRs described below.<br>They did not catch the issues that I caught.
It may be helpful<br>to consult this handy table from Lorin Hochstein’s<br>Traditional versus resilience engineering views:The post is short and recommended reading. The table below is a subset of the one in the original post.
Traditional view focuses on<br>Resilience engineering view focuses on
objectives<br>production pressure
reducing complexity<br>navigating complexity
root cause<br>interaction of multiple...