Simple Ways We Check Code Before It Goes Live

Most pull request comments we write are about naming, formatting, or style — things a linter should catch. The reviews that actually stop a bug from reaching production ask a narrower set of questions: what happens when this input is empty, what happens if this call times out, and who else calls this function.

We ask reviewers to spend the first pass reading for intent, not syntax — does the diff do what the description says it does. The second pass is where we hunt for the edge cases: concurrent writes, partial failures, and anything that only breaks under load.

The habit that's paid off the most: never approve a diff you didn't run. Reading code catches typos. Running it catches the bugs that matter.

Most review checklists fail for a predictable reason: they optimize for coverage instead of attention. A twenty-item template gets rubber-stamped by the third use, because no reviewer can hold twenty questions in their head on every diff. We've found three or four sharp questions, asked consistently, catch more than a long list skimmed once.

So instead of a checklist, we teach a sequence. First, does this diff match its description — not the code quality, just whether it does what it claims. Second, what's the blast radius if this is wrong — one user, one team, or everyone. Third, is there a test that would have caught this bug if it existed six months ago. That third question is the one that turns a review from opinion into evidence.

The empty-input and timeout questions matter because they're the failures that don't show up in a demo. A function works perfectly against the happy-path data every demo uses, and then meets a null value or a slow network in production three weeks later. Asking 'what happens when this is empty' during review is cheaper than debugging it at 2am.

We also separate blocking comments from suggestions explicitly, in the comment itself. A reviewer who mixes 'this will break in production' with 'you could rename this variable' in the same tone trains authors to skim past both. Marking severity isn't bureaucracy — it's what lets an author triage a review in the two minutes they have between meetings instead of re-reading every line.

The rule about running the diff yourself sounds obvious until you watch how often it gets skipped under deadline pressure. A reviewer who trusts the CI badge and reads the diff top to bottom will approve code that's logically clean and functionally broken — the kind of bug that only appears when you actually exercise the path. We've stopped treating 'LGTM' as acceptable without at least one local run for anything touching a critical path.

None of this makes review faster in the short term. It makes the bugs that do slip through rarer and cheaper, which is the only measure of a review process that actually matters six months after a feature ships.