How to Do a Good Code Review: Small Diffs, Fast Reviews

Most code reviews are theater. A thousand-line pull request lands on Friday, sits untouched for four days, and merges on Monday with two approvals from people who skimmed it. Nobody found a bug, nobody learned anything — the diff was too big to understand, so the approval was a ritual, not a review. Google's engineering docs and the peer-review research agree on the uncomfortable point: reviews only work when the diff is small and the feedback is fast. Everything else is technique.

I've spent the week reading Google's published review docs, SmartBear's peer-review benchmarks, and the best practitioner write-ups I could find. The advice below is what survived.

1. Know what the review is actually for

A good review does three things: it catches the mistakes the author missed, it builds a shared understanding of what changed and why, and it keeps the codebase's abstractions consistent — pointing out that a helper already exists elsewhere so the author doesn't reinvent it. That's it. One practitioner puts it even more bluntly: the goal should be creating understanding, never forcing your colleague to justify themselves.

Notice what's not on the list: perfection. Google's standard — approve once a change definitely improves code health, even if it isn't perfect. Perfect code doesn't exist; "better" is enough. If more feedback would make significant improvements, ask. Otherwise, approve and move on.

2. Keep the diff small — the only rule with numbers

This is the most quantified piece of the whole discipline, and almost nobody follows it. SmartBear's peer-review guidance recommends reviewing fewer than 400 lines of code at a time, inspecting under 500 lines per hour, and limiting concentrated review sessions to 60 minutes. Their reported benchmark: a 200–400 line review conducted over 60–90 minutes can yield 70–90% defect discovery. That's not a guarantee for every codebase — it's a directional benchmark — but the shape of it is the point: small reviews find things; huge ones don't.

The reviewer can't fix a 1,000-line diff — the author owns reviewability. Google splits work into small change lists: ten 100-line CLs beat one 1,000-line CL, every time. If a change is too big to understand in one pass, split it by independently testable behavior before asking for review.

3. Review fast — slow reviews rot everything

Google's maximum for a review is one business day. Why the urgency? Three compounding costs. First, the review becomes a blocker: the author moves on, new work piles up, and days become weeks. Second, developers get frustrated — and frustrated developers submit worse code and do less of the unglamorous cleanup work ("if my reviewer won't reply for four days, what's the point?"). Third, code quality degrades precisely where you thought reviews were protecting it.

The real performance metric isn't comment count — it's time-to-first-response. If your team measures one review metric, make it that one. And if you spot an architectural problem early, say so immediately, before finishing the rest: Google tells reviewers to send severe findings the moment they land. The author may already be building on top of what you're about to reject.

4. Ask questions, don't deliver verdicts

Write questions, not pronouncements. "Is there a reason this migration isn't reversible?" lands differently than "make this reversible" — and the question often wins, because suboptimal solutions are usually carefully chosen compromises the reviewer can't see. Don't understand a section? Ask what it does. Disagree? Ask why, instead of criticizing. See a likely mistake? Ask whether section X might lead to problem Y.

The one test that tells you whether you're doing this honestly: if the question you're about to write has only one possible answer, it's not a question — it's a demand in disguise. Say what you mean instead. Reserve the direct version for the rare case where you're certain a solution must not be merged as written.

This is also the answer to the question every junior dev asks: am I even allowed to review senior engineers' code? Yes — because asking comprehension questions is reviewing. A less experienced reviewer finds fewer subtle defects but more than makes up for it by forcing the author to explain and re-examine their own decisions. If you're new and lost, ask the author to walk you through the change — that's not a weak review, it's the review working as designed.

5. Label your comments so the author knows what's blocking

The biggest cause of review friction isn't disagreement — it's ambiguity. Fix it with labels. Four is enough: Blocking (concrete defect, security issue, broken requirement — nothing merges until fixed), Suggestion (a better approach exists; the author picks the fix), Question (you need context before judging), and Nit (optional polish that must not delay the merge).

Google's version is simpler — prefix non-essential polish with "Nit:" — and the rule behind it is absolute: never block a PR on personal style preference, and never mix style changes into a real change. Formatters exist; your taste is not a standard. Critique the code and its consequences, not the person: "this condition permits duplicate writes" is reviewable evidence; "you forgot idempotency" is needlessly personal. And when a comment gets addressed — or you spot something genuinely clever — say so. Reviews skew toward problems; one acknowledgment costs nothing.

6. Read in the right order: intent first, lines last

Don't start with line-level style. Google's sequence: get an overview of the change, examine the main parts, then go file by file in a sensible order. In practice: read the PR description first (state the expected behavior in one sentence), trace the changed behavior — the main path plus at least one failure path — then design, then tests, and only then the diff.

At each level, per Google's checklist: design (does this belong here?), functionality (does it behave as intended?), complexity (could it be simpler?), tests (would they fail if the code broke?), naming, comments (explaining why, not what), consistency. And read the context around changed lines, not just the diff — two new if blocks look harmless until you notice they join an if-else chain that already had fifteen.

Know when to stop

The thoughtful reviewer's failure mode is the endless review. Google's advice — find an end — is kind: dragging a review through round after round is soul-deadening. "LGTM" doesn't mean "this will never fail"; it means "looks good to me." If it looks good, move on; big refactorings you spot belong in a new change.

The one exception that proves the rule: never accept "I'll fix it in a follow-up." Follow-ups rarely happen — not from malice, but because priorities shift and queues swallow them. There's no benefit in merging code you immediately have to fix; you're just adding technical debt that might be forgotten. Insist the work happens now. (Emergencies are the exception: when production is down, quality standards relax and the review becomes the reviewer's first priority.)

What to do this week

Pick one pull request this week and review it within a day. Ask one genuine "why" instead of issuing one correction. And when you open a 900-line diff, send it back with one sentence: split this by independently testable behavior. Small, fast, and questioned — that's the whole game.

References

• How Google Does Code Reviews – freeCodeCamp (summary of Google's engineering practices)
• Code Review: Process, Checklist & Examples – AnyGen (SmartBear benchmarks, Google review taxonomy)
• How to write good code reviews – farbenmeer.de (the questions-only method)
• What makes a good code review – Graphite (clarity, timeliness, knowledge sharing)

Related: How to Write an AGENTS.md File Your Coding Agent Will Actually Follow · Git Stash Not Working? The Four Fixes Nobody Teaches You