Why Code Review Culture Matters More Than Any Tool

We introduced mandatory code reviews at Motorola in 1997. The tooling was primitive — CVS had no review workflow, so we printed the diff, sat in a meeting room, and read it together. GitHub would not exist for another decade. But the discipline of having every change read by a second set of eyes before it shipped had a measurable effect on quality and on how the team communicated about code.

Here is what I learnt about making code review work.

What Reviews Are Actually For

Reviews catch bugs — but that is not their primary value. The primary values are:

Knowledge transfer. When a reviewer has to understand a change well enough to comment on it, knowledge about the system spreads. Single points of knowledge are a risk; reviews distribute it.

Raising the floor. A developer who knows their code will be read writes it differently. Not to impress — to be understood. Variable names improve. Comments appear where they are needed. Dead code is removed.

Architectural consistency. Individual developers make different choices about abstractions, naming, and structure. Reviews surface inconsistency before it accumulates into a codebase where every file looks like it was written by a different person (because it was).

Finding assumptions. The author of a change understands its context. A reviewer does not. Reviewers reliably find the places where context that exists only in the author's head is needed to understand the code.

What Made Reviews Fail

In the first two months we had three common failure modes:

Reviews that were too large. A developer would accumulate a week of changes and submit them all at once for review. 800 lines of diff is not reviewable — reviewers rubber-stamp it or spend four hours on it and block the developer for a day. We set a norm: no review larger than 300 lines.

Reviews as gatekeeping. One developer used reviews as an opportunity to rewrite every change in his preferred style. Reviews became confrontational. The developer being reviewed started submitting less frequently.

Reviews as formality. Two developers would approve each other's changes with two-word comments ("looks good") because they valued shipping over correctness. The review existed in the process but not in practice.

The Norms That Worked

Review the code, not the person. Comments should be about the code. "This method does two things" is useful. "You always over-complicate this" is not. We called this out explicitly when it happened.

Ask questions, don't make demands. "Why is this a separate class rather than a method?" is more useful than "this should be a method." The author might have a good reason you do not know about. Questions surface information; demands create defensiveness.

Distinguish blockers from suggestions. Not everything a reviewer notices needs to block the change. "Must fix: this has a race condition" vs. "Suggestion: this would be clearer as a named constant." Authors respect blockers more when they are not mixed with style preferences.

Reviews have a time limit. A change waiting for review for more than 24 hours is a blocked developer. We committed to reviewing within one working day. This forced prioritisation — you did not defer reviews until you felt like it.

The author is responsible for the change. A reviewer who approves a change does not take on responsibility for it. The author chose to make the change; the author owns it. This prevented developers from hiding behind review approval when things went wrong.

What the Tools Could Not Fix

When GitHub launched pull requests in 2008 they transformed the mechanics of code review. Inline comments, approval workflows, CI integration — all genuinely useful.

But teams that had bad review culture before the tools had bad review culture after them. Tools make the mechanics easier; they do not fix the underlying behaviours. Rubber-stamp approvals still happen. Reviews of 2000-line diffs still happen. Reviewers who use comments to criticise the person rather than the code still happen.

The culture — the shared norms about what review is for and how it should be conducted — is the thing that matters. Tools support culture. They do not create it.