Code Review: The Ritual That Forgot Its Purpose

From clutter to clarity

I’ve watched developers spend hours crafting pull requests — structuring commits, writing descriptions, adding tests. They hit “Create PR” hoping for feedback that might actually improve their work.

What they get instead: a comment about spacing, a nitpick about naming, maybe a “looks good” from someone who skimmed it in thirty seconds. Then the “LGTM” and a merge.

Nobody learned anything. Nobody’s thinking changed. We call it code review, but it’s mostly theater — a ritual we perform because that’s what professional teams do.

Here’s what’s strange: code review was never supposed to be a quality gate. It was meant to be a conversation between people trying to understand the same problem together.

In my experience, most teams check all the boxes without learning a thing.

The Illusion of Code Review

Walk into most engineering teams and you’ll find code review happening. Pull requests are created, notifications ping, comments appear, approvals are granted. The machinery is running.

But ask yourself: when was the last time a code review changed how someone thinks about a problem?

When did review threads stop being teaching moments and turn into mere compliance checks?

For most teams, code review has become theater. We install the process, set up the tools, add it to workflow diagrams — and mistake the presence of code review for the practice of it.

The result? Thousands of pull requests where people scan for obvious errors, check if tests pass, comment on variable names, and hit approve. The code merges. Nobody’s understanding deepens. The team doesn’t get smarter.

We’re simulating code review, not doing it.

What Code Review Was Supposed to Be

Before code review became a checkbox in project management software, it was something simpler and more profound: two programmers looking at the same problem together.

The goal wasn’t primarily to catch bugs — though that happened. It wasn’t to enforce style guides — though consistency mattered. The real purpose was alignment.

Code review was where individual understanding became collective understanding. Where the mental model in your head met the mental model in mine, and we worked to reconcile the differences.

Code review was the place where minds merged before code did.

It was a moment of shared context. A chance to ask: why this approach and not another? What assumptions are baked into this design? What will future-me need to know when debugging this at 2am?

The best code reviews made both people smarter. The author learned by explaining their choices. The reviewer learned by seeing a different way to solve a problem. Knowledge flowed in both directions.

This wasn’t about gatekeeping. It was about building a shared language, a common understanding of what the system does and why it matters.

What It Became Instead

Somewhere along the way, we industrialized code review and forgot its soul.

It became a gate. A hurdle. A required step in the pipeline between “I’m done” and “It ships.”

The emphasis shifted from learning to approval, from dialogue to compliance.

Teams developed pathologies. The Nitpicker fixates on spacing and semicolons while missing architectural problems. The Rubber Stamper approves everything in thirty seconds. The Blocker treats every review as an opportunity to demonstrate superiority.

Pull requests grew larger because we batched up work to avoid “review overhead.” Reviews took longer because nobody had time. Developers learned to game the system — keeping PRs boring enough to slip through, avoiding changes that might spark debate.

Comment threads became battlegrounds over style preferences. Tabs or spaces? Map or for-loop? Bike-shedding ran rampant.

The feedback that mattered — deep questions about design and tradeoffs — rarely appeared. They took too much time. Required too much context. Risked conflict.

Thousands of PRs pass through without meaningful discussion. We optimized for throughput and lost the plot entirely.

Bringing Code Review Back to Life

Here’s how to make review feel human again.

Start with size. Keep pull requests small — genuinely small, not “small for us” small. A change that touches three files and adds fifty lines invites engagement. One that touches thirty files and adds five hundred lines invites approval fatigue.

Small PRs create space for questions. They make it safe to say “I don’t get it” without feeling like you’re blocking a week of someone’s work.

Change how you give feedback. Replace “This is wrong” with “Help me understand why you chose this.” Replace “You should do X” with “What would happen if we did X instead?”

The shift from telling to asking transforms review from judgment into collaboration. It makes the author a teacher, not a defendant. Exploration becomes safe. And safety is where learning happens.

Focus on what matters. Let tools catch the formatting issues, the missing semicolons, the unused variables. Your human brain should focus on things machines can’t evaluate: is this solving the right problem? Does the design make sense? Will this be maintainable six months from now?

If you find yourself arguing about style, you’re wasting everyone’s time. Automate it or let it go.

Code Review as Mentorship

The most powerful code reviews aren’t between peers — they’re between someone who knows and someone who’s learning.

When a senior engineer reviews a junior’s code, it’s not about finding mistakes. It’s about transmitting culture. Showing what matters in this codebase, on this team, in this kind of system.

This is where practices get passed down. Where implicit knowledge becomes explicit. Where a junior learns not just what works, but why it works and when it doesn’t.

But mentorship flows both ways. The junior brings fresh eyes. They ask questions that expose assumptions. They don’t yet know which shortcuts are acceptable and which are technical debt in disguise.

A single question from a junior once revealed a hidden assumption that reshaped an entire system design.

Their confusion is data. If someone new can’t understand your change, that’s feedback about clarity — not a failure of the reviewer.

Mentorship is not one-way. Juniors teach as much as they learn.

Automate the Boring Parts

If your process involves humans commenting on formatting, indentation, or import ordering, you’re doing it wrong.

Set up linters and formatters. Let them run automatically. Let the computer reject code that violates style before any human sees it.

This isn’t laziness — it’s respect. Respect for the reviewer’s time and mental energy. Respect for the author who shouldn’t have to defend their bracket placement.

When you remove the trivial concerns, what remains are the interesting ones: architectural questions, performance considerations, readability issues that a linter can’t detect. Human review should feel like design critique, not proofreading.

Respect humans for what they can think, not what they can check.

Beyond the Ritual

Once you fix the basics, the real question emerges: should code review even be a gate?

Some teams experiment with trust-based models. Code goes in, reviews happen asynchronously, problems get fixed in follow-up commits. The focus shifts from preventing bad code to collectively maintaining good code over time.

Some teams ditched the gate and embraced trust.

Others rethink who reviews what. The database expert reviews database changes. The frontend specialist reviews UI code. Live pairing sessions replace async threads. Conversations are richer. Misunderstandings surface faster. Understanding deepens.

The approach matters less than the question: what are we optimizing for?

If you optimize for control, you build gates. If you optimize for learning, you build conversations and transparency.

Most teams inherit review processes without asking if they serve the actual goal.

The Real Merge Happens in People’s Heads

The git merge is easy. The hard merge is conceptual.

When you review code, you’re not just evaluating correctness — you’re integrating someone else’s thinking into your own understanding. Updating your mental model.

Rushed reviews are worse than none. Approvals without understanding create the illusion of shared knowledge. You think the team knows what this code does. They don’t. They just clicked a button.

Real code review is slow in the moment but fast in the long run. It creates a team that moves together, shares assumptions, and can maintain each other’s code without constant handoffs.

When it works, code review feels invisible. It doesn’t feel like a process. It feels like smart people naturally collaborating.

The question isn’t whether your team does code review. The question is whether your code review does anything.

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter.

And before you go, don’t forget to clap and follow the writer️!