The Simple Version
A code review is when engineers read each other’s proposed changes before they go live. It looks like a technical process, but what it actually does is transfer knowledge, establish norms, and signal who holds power on a team.
What People Think Is Happening
The official story is this: one engineer writes code, another engineer reads it to catch bugs, and better software ships as a result. That’s the value proposition. It’s why nearly every serious software organization requires them.
The problem with this story is that it’s mostly wrong, or at least radically incomplete. Studies of real code review data, including research from Microsoft published in IEEE Software, consistently show that a minority of review comments actually catch functional bugs. The majority address style, naming conventions, readability, and design preferences. These things matter, but they are not what people mean when they say code review catches bugs.
If the goal were purely defect prevention, there are more efficient tools. Static analysis software catches entire categories of errors automatically. Automated test suites run faster than any human reviewer. Formal verification, in high-stakes domains, provides mathematical guarantees. Code review persists not because it’s the best bug-catching mechanism, but because it’s doing several other things simultaneously.
The Knowledge Transfer Problem
Software teams have a serious, underappreciated problem: knowledge about how a system works lives almost entirely in individual people’s heads. When someone leaves, that knowledge walks out with them. When someone joins, they have to reconstruct it from documentation that’s usually out of date and code that’s usually cryptic.
Code review is one of the few forcing functions that moves knowledge between people. When a senior engineer reviews a junior engineer’s pull request and says “this approach will cause problems when the database is under load, here’s why,” that’s not a bug fix. That’s institutional memory transferring from one brain to another. It’s apprenticeship, conducted asynchronously through comment threads.
This also explains a pattern that puzzles a lot of newer engineers: why do experienced engineers sometimes leave extensive review comments on code that technically works? Because the code working is not the point. The point is whether the person who wrote it now understands the system more deeply than they did before. Good reviewers are teaching, not auditing.
This connects to something worth understanding about how expert developers store and retrieve knowledge. The externalization of reasoning through review comments mirrors the same cognitive process.
Norms, Power, and Who Gets Heard
Every code review is also a negotiation about what the team values.
Consider two teams. Team A’s reviews focus on performance and correctness. Comments about variable naming are rare, and when they appear, they’re ignored. Team B’s reviews spend half the time on naming, formatting, and documentation. Neither team is wrong, but they have different implicit hierarchies of what matters.
These norms don’t get written down in any official document. They emerge through the accumulated weight of review comments over months. What gets flagged and what gets waved through teaches every engineer, especially junior ones, what the team actually cares about, as opposed to what the style guide says it cares about.
Power dynamics are equally present. In many teams, certain engineers’ approvals carry more weight than others. A comment from a senior architect can functionally block a change even if that person has no official authority to do so. The code review process makes status hierarchies visible and, in some cases, rigid. Teams that don’t manage this actively end up with review processes where only certain voices matter, which means the process stops being educational and becomes gatekeeping.
This is why code review at high-performing teams looks qualitatively different from code review at struggling teams. It’s not that one has better bug-catching. It’s that one has built a culture of genuine knowledge transfer and psychological safety, and the other has built a culture of approval-seeking.
The Costs Nobody Tracks
Code review has real costs that organizations frequently underestimate because they’re diffuse and hard to measure.
Waiting for review is one of the largest sources of latency in software delivery. A change that takes two hours to write might sit in a queue for two days before anyone reads it. During that time, the engineer who wrote it has moved on mentally, context has switched, and when the review comments finally arrive, re-engaging costs additional time. Multiply that by dozens of engineers and hundreds of changes per week.
There’s also the cost of review done badly. Nitpicky, inconsistent, or hostile reviews demoralize engineers, particularly those who are newer or from underrepresented backgrounds. Research on code review bias is consistent: the same code is evaluated differently based on who reviewers believe wrote it. An organization that treats code review as a neutral technical process and doesn’t examine these dynamics is leaving real costs unaddressed.
The irony is that deletion and simplification often generate more value than the review of complex new additions, but teams rarely budget review time with that in mind.
What Good Code Review Actually Looks Like
Good code review treats the social and educational functions as primary, not incidental.
That means reviewers explain the why behind comments, not just flag the what. It means distinguishing between blocking issues (this will break something) and preferences (I’d personally do this differently). It means senior engineers doing substantial review work, not delegating it entirely to juniors. And it means tracking review cycle times the same way you’d track any other bottleneck in the delivery process.
The teams that get this right don’t have fewer bugs because their reviewers are smarter. They have fewer bugs because their engineers share context, build shared intuitions, and catch problems before they’re written, not after. The review process made them better engineers, and better engineers write better code.
That’s the actual mechanism. It just looks like reading code.
