The Code Review Habits That Actually Prevent the 2 A.M. Production Bug

Open any pull request and most comments will be about naming, formatting, or minor style preferences. Most production incidents trace back to something else entirely. There's a mismatch between where review attention goes and where it should go.

What actually causes incidents

In practice, the recurring causes are boring: an unhandled edge case in input validation, a race condition under concurrent access, an assumption about data shape that held in testing but not in production, or a missing rollback path when an external call fails partway through. None of these show up by reading code top to bottom looking for typos.

Where to actually spend review time

Boundary conditions. What happens with an empty list, a null value, a duplicate ID, a request that arrives twice? If the PR doesn't mention these, ask about them directly.

Failure paths, not just happy paths. For every external call (API, database, queue), ask: what does this function do if that call fails halfway through? Is there a partial state left behind?

Assumptions baked into the diff. "This assumes the list is never empty" is the kind of comment that should appear in the code as a guard clause, not just survive as an assumption in someone's head.

Blast radius. If this change is wrong, what does it affect — one user, all users, or data integrity? Changes with a large blast radius deserve disproportionate scrutiny relative to their line count.

A small process change that helps

Ask the PR author to write one sentence in the description: "this could break if ___." It forces the author to think about failure modes before a reviewer has to find them, and it gives the reviewer a starting point instead of a blank diff.

Style nits aren't worthless, but they're cheap to catch with a linter. Reserve human review attention for the things a linter can't see.