Code review isn't a checkbox
I have a problem with how we treat code review. Not the practice itself, but what we've turned it into. Too often it's the last box you tick before merging, a formality squeezed in at the end of the day, a thumbs-up from whoever's online. Somebody clicks approve, the branch goes green, everyone moves on. We treat it like paperwork.
It's the opposite of paperwork. The pull request is the moment a team decides, together, what it's willing to put in production and stand behind. That's not administrative. That's a human act of judgment, and it carries weight.
Reviewing is not hunting for other people's mistakes
Let's kill that idea first. A review isn't a teacher circling errors in red. When I review your code, I'm not looking for what you did wrong so I can feel clever. I'm deciding, with you, what we're both prepared to own once this thing is live and a citizen is tapping a card on a bus at 7am.
That reframing changes everything. The question stops being "did the author make a mistake" and becomes "are we, as a team, ready to assume this in production." Different question. Higher stakes. And it pulls the reviewer off the sidelines and into the result.
Approving is co-signing
Here's the part people dodge. When I approve a pull request, I'm not doing the author a favor. I'm cosigning. If it breaks next week, "the author wrote it" is not a defense, because I read it and I said yes. The author and the reviewer both answer for the outcome. That's what shared responsibility means, and most teams say it out loud without actually living it.
Which brings me to the thing I see constantly: the approval without comprehension. Someone scrolls a diff for ninety seconds, doesn't really follow the logic, and clicks approve because the author is senior, or because they're busy, or because saying "I don't get this" feels embarrassing. That's not a review. That's a rubber stamp.
My rule is simple. If I can't explain what I just approved, I didn't review it. I signed with my eyes closed. And a signature with your eyes closed still has your name on it.
Substance before commas
A good review goes after the intent, not the punctuation. Three things I actually care about:
- Do I understand what problem this is solving, and is this the right way to solve it.
- Are the decisions defensible, or did we paint ourselves into a corner we'll regret.
- Will the next person who touches this code understand it without a séance.
Notice what's not on the list: spaces, naming nitpicks, where the bracket goes. A linter handles all of that, and it does it without bruising anyone's ego. If your review energy is spent on commas, you're optimizing the wrong layer. Challenge the choices. Ask why. The form is cheap and automatable. The judgment is the expensive part, and it's the only part a machine can't fully give you.
The pull request is where you teach judgment
This is the piece most leaders underrate. The review is a transmission channel. It's where an experienced developer shapes the judgment of a newer one, and where the team's standard actually spreads, line by line, decision by decision.
You don't teach engineering judgment in a training course. Nobody ever learned when to cut a corner and when to absolutely not by sitting through a slide deck. They learn it in a pull request, when someone they respect writes "this works, but here's why we don't do it this way" and explains the reasoning. That's mentorship in its most concrete form. That's culture moving from one head to another.
Kill the review, or reduce it to a stamp, and you cut that channel. The recruit never builds the instinct. The standard never propagates. Six months later you're wondering why everyone codes in their own private dialect and nobody agrees on what "good" means. You did that to yourselves.
A giant pull request doesn't get reviewed, it gets surrendered to
Let's be honest about batch size. A 2,000-line pull request does not get reviewed. It gets approved out of exhaustion. Nobody holds two thousand lines of change in their head. Around line four hundred the reviewer's brain quietly checks out, and the rest gets a glance and a prayer.
So the size of the change is not a logistics detail. It's a quality decision. Small, focused pull requests are reviewable. Huge ones are a request to be trusted blindly, dressed up as collaboration. If you want real review, you have to make review possible, and that starts with the author keeping the batch sane.
Optimizing a review is not making it faster
Everyone wants reviews to go faster. Fair. Blocked branches kill momentum and nothing's more demoralizing than good work sitting for two days waiting on an approval. But "faster at all costs" is how you end up with the rubber stamp again.
The goal isn't speed. It's being demanding in the right place. Concretely, that means:
- Reasonable-sized pull requests, so the reviewer can actually hold the change in their head.
- Clear context from the author. Tell me what you're solving and why you chose this path. Don't make me reverse-engineer your intent from the diff.
- Short turnaround, so review doesn't become the bottleneck that blocks the whole team.
- A demanding tone that stays respectful. Push hard on the decisions. Don't make it personal. You can hold a high bar without being a jerk about it.
That's optimization. Friction where it protects quality, none where it's just bureaucracy.
The human stays in the loop
Now the part everyone wants to skip to. Yes, the tooling is changing. AI writes code, AI suggests reviews, AI flags issues, and a lot of that is genuinely useful. Let the machine catch the boring stuff. Let it draft, let it spot the obvious bug, let it save you the commas.
But whatever clever solutions we dream up to go faster, the human in the loop on the pull request stays the key to the whole thing. Not out of nostalgia. For a hard reason: the human keeps responsibility for the final judgment. A model doesn't get paged at 3am. A model doesn't answer to the team or to the public for what shipped. You do.
Approval is an act of accountability, and accountability can't be delegated to something that can't be held accountable. The machine can inform the decision. It can't own it.
So here's where I land. Treat the pull request as what it actually is: the moment your team decides what it's willing to assume in production, and the place where your standard gets taught. Keep the batches small. Demand context. Move fast on turnaround, slow on judgment. And never approve something you can't explain.
If you can't explain it, you didn't review it. You just signed.