A few months ago I watched a junior engineer on my team mass-approve six pull requests in an afternoon. All green CI, all well-tested, all technically correct. Two weeks later we hit a production incident that lived inside one of those PRs. The code worked. It just solved the wrong problem.
That incident rewired how I think about code reviews.
Reviews Are Not Quality Gates
Most teams treat code reviews like airport security. Scan for contraband, wave people through. The mental model is: the code is done, we just need someone to check it.
This is backwards.
A code review is not an inspection. It is a conversation. The difference matters enormously. An inspection catches defects. A conversation transfers understanding. When I review your code, I am not just looking for bugs. I am building a mental model of what you built, why you built it that way, and how it fits into the system I also own.
Think of it like a musician sitting in on another musician’s rehearsal. You are not there to catch wrong notes. You are there to hear the interpretation, to absorb the phrasing, to understand what the piece is becoming. The wrong notes will surface naturally. The real value is shared understanding of the music.
The Hidden Function
Code reviews do something no other engineering practice does: they distribute knowledge sideways across a team in real time.
Stand-ups tell you what people are working on. Documentation tells you what was built. Code reviews show you how someone thinks. You see their assumptions, their naming instincts, their blind spots. You see where they over-engineer and where they cut corners. This is irreplaceable signal.
I have learned more about system architecture from reviewing colleagues’ code than from any design document. Design docs describe intent. Code reviews reveal reality.
And it works both ways. When someone reviews my code and asks “why not extract this into a service?”—that question alone forces me to articulate a decision I made unconsciously. Sometimes I realise I had no good reason. The review did not find a bug. It found a missing thought.
The Cost of Skipping
Teams that rubber-stamp reviews pay for it in ways that never show up in metrics. Knowledge silos form. Two engineers build incompatible abstractions because neither read the other’s code. A pattern emerges in one corner of the codebase that the rest of the team never learns about.
The cost is not bugs. The cost is divergence.
I have seen teams where every engineer could only work on “their” part of the system. Not because of access controls, but because nobody else understood it. That is what happens when reviews become a checkbox instead of a conversation.
Do It Slowly
The counterintuitive insight is this: code reviews should slow you down. That is the point. The velocity you lose in review time, you gain back tenfold in shared context, fewer miscommunications, and a team that can work on any part of the codebase without fear.
Speed without shared understanding is not velocity. It is just motion.