Code Review: Making It Useful Instead of Ceremonial
Key takeaway
Keep changes small — under a few hundred lines — because review quality collapses on large ones. Automate formatting and style entirely so humans spend their attention on correctness, design, and the edge cases a machine can't evaluate.
Code review is either the most valuable hour in a developer's week or a rubber stamp that delays delivery. The difference comes down to change size, what reviewers are asked to look for, and how feedback is written.
Size is the biggest factor
Review effectiveness falls sharply with the size of the change. A focused change of a couple of hundred lines gets genuine scrutiny; a two-thousand-line change gets approved. If a change must be large, split it into a sequence of reviewable commits, or walk the reviewer through it in person and use the written review for the details.
What reviewers should actually look for
- Correctness — does it do what it claims, including the edge cases and error paths?
- Security — input handling, authorisation checks, and anything touching credentials or personal data.
- Design — does it fit the surrounding code, or introduce a second way of doing something that already exists?
- Tests — do they cover the behaviour, and would they fail if the code were wrong?
- Readability for the next person, who will be reading it without any of today's context.
- Not: formatting, import order, or naming conventions a tool can enforce.
Automate the arguments away
- A formatter with a project configuration, applied automatically. Style debates are pure waste.
- Linting and static analysis in the pipeline, blocking merge rather than generating comments.
- Automated tests and coverage reporting, so reviewers aren't checking what a machine can verify.
- Dependency and secret scanning, for the same reason.
Tone and process
- Comment on the code, not the person. "This will fail when the list is empty" rather than "you forgot".
- Distinguish blocking issues from suggestions and from preferences — label them, so the author knows what must change.
- Ask rather than assert when you don't have the context; the author often has a reason.
- Review promptly. A change waiting two days costs far more in context-switching than the review itself takes.
- Approve when it's good enough, not when it's how you would have written it. Perfectionism in review is a delivery problem wearing a quality costume.