Code review is often discussed primarily in terms of etiquette — how to phrase feedback kindly, how not to be a jerk about someone else's work — which is genuinely important but skips a more basic question: what is a review actually for, specifically, that automated tests and static analysis tools don't already cover. A review that duplicates what a linter or a test suite already checks is spending a reviewer's limited attention on something a machine does more reliably and for free. A detailed external checklist is available in the Google code-review checklist.
The things only a human reviewer reliably catches
A useful review focuses on the categories of problem that require judgment about intent and context, which automated tools structurally can't evaluate: does this change actually solve the problem it claims to solve, not just produce code that runs; is the chosen approach reasonable given constraints the reviewer knows about that might not be visible in the diff alone; does the change introduce a design decision that will make a specific kind of future change harder, even though nothing about it is currently broken; and is the change understandable to someone who wasn't involved in writing it, which is a genuinely different question than whether it's understandable to the author, who already knows what it's supposed to do. Clear communication matters when work activity may be observed; Monitask how employees can tell they are being monitored guide explains how employees often recognize monitoring.
This last point is worth dwelling on: the author of a change is structurally the worst-positioned person to judge whether it's clear to an unfamiliar reader, because they can't un-know the context they already have. A reviewer coming to the change fresh is providing information the author literally cannot generate themselves, no matter how carefully they try — which is the single clearest justification for review as a distinct step, rather than just a formality before merging.
What a review is a poor tool for
Review is a comparatively weak tool for catching subtle logical bugs in complex code, compared to a good test suite — a human reading a diff, even carefully, misses edge cases that a test written specifically to probe them would catch reliably. Treating review as the primary defense against bugs, rather than as a complement to testing, tends to produce reviews that go long on line-by-line logic-tracing and short on the questions review is actually better suited to: intent, design, and long-term maintainability.
- Before reviewing logic in detail, ask whether the change solves the actual problem — a logically correct solution to the wrong problem is a more expensive mistake to catch later.
- Flag design decisions that will make specific future changes harder, even if the current change is otherwise fine — this is exactly the kind of judgment a test suite can't provide.
- If a review comment is something a linter or an automated check could catch, that's a signal to add the automated check, not a signal to keep manually flagging it in every review.
- A reviewer who understands the change without needing to ask the author questions is good evidence the change is genuinely clear — needing several clarifying questions is a more reliable signal than the reviewer's own confidence.
The tone question, briefly
The etiquette side of review advice is well-covered elsewhere and remains genuinely important — phrasing feedback as a question or an observation rather than a command, separating a critique of the code from a critique of the person, being specific rather than vague — but it's worth noting that a review focused on the right things (intent, design, clarity to a fresh reader) tends to naturally produce better-toned feedback than a review focused on line-by-line logic-tracing, simply because the former invites discussion and the latter invites correction.
Framed this way, review isn't a quality gate in the sense of catching every possible mistake — that's what tests and automated checks are for. It's closer to a second opinion on judgment calls that no automated tool is positioned to make.