Kelly Mears

Code Review

A second person reading a change before it lands, and the practices that make it worth the time.

Version Control & Delivery2 min read210 words10 out · 15 in
also calledReview

Code review is the practice of having someone other than the author read a change before it is merged. Its documented benefits are defect detection and knowledge distribution, and the second is often the larger one — review is how a team stays able to work on each other's code.

What review is uniquely good at is precisely what automation cannot do: judging whether the approach is right, whether the naming will make sense to someone later, whether the change belongs where it was put, and whether the claims in the description are true. Nothing mechanical can check prose, so an unverified causal statement or a false exhaustive claim reaches production unless a reader catches it. See Plausible Mechanism and Exhaustive Claim.

What makes review effective is mostly logistical. Small changes get read; large ones get skimmed. Reviewers need the evidence where the review happens, not in a place only the author can see. And a reviewer should be cold — fresh perspective is the whole mechanism, which is why self-review reliably declares work satisfactory. See Adversarial Review.

A reviewer's own reasoning deserves the same scepticism they apply to the change. A configuration set to strict plus a clean run feels like execution, and is configuration plus an untested inference.

See also6

Hand-picked in the note itself — the neighbours worth reading next.

Related2

Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.

Linked from15

Notes elsewhere in the wiki that reach for this one.