Code Review Is a Culture, Not a Gate

Most code review, honestly practiced across the industry, is theater. A pull request gets opened, a teammate skims it for fifteen minutes between meetings, leaves two comments about variable naming, and approves it. The check passes, the merge happens, and nothing about the reviewer's understanding of the system or the author's judgment has actually changed. That's not review. That's a formality wearing review's clothes.

We treat code review as the primary mechanism by which a small senior team stays coherent across an engagement that might run six or nine months, touching parts of a system that no single person holds fully in their head. That reframing changes what a review is actually for, and it changes the questions we expect a reviewer to ask.

A review should surface disagreement about design, not just correctness. Correctness bugs matter, but they're the cheap ones to catch — tests and types catch most of them before a human ever looks. What a human reviewer is actually for is judgment: is this the right abstraction, does this pattern match how we've solved this problem elsewhere in the codebase, does this decision quietly commit us to something we'll regret in three months. Those questions require the reviewer to have real context on the system, which is exactly why we don't rotate review duty through whoever's free — the reviewer needs to know the codebase well enough to recognize when something's subtly wrong even though it works.

A review should be a two-way transfer of context, not a one-way audit. When a senior engineer reviews another senior engineer's work, the goal isn't approval — it's making sure two people now understand the tradeoff that got made, so that if the original author is out sick or off the project, the decision doesn't die with them. We write review comments that explain reasoning, not just flag issues, because the comment is documentation as much as it's feedback. "This should use a queue" is a demand. "This should use a queue because the downstream API rate-limits at 10 req/s and we'll hit that limit under normal load within the first release" is a transfer of understanding that survives the reviewer leaving the conversation.

A review should have teeth, and that requires psychological safety, not authority. The reason review theater happens is that disagreeing with a colleague's approach feels socially costly, especially under deadline pressure, so reviewers default to rubber-stamping anything that isn't obviously broken. The fix isn't a stricter review policy — policies don't create the safety to push back. It comes from a team norm, modeled consistently by the most senior people, that having your design decisions questioned is not a referendum on your competence. On our teams, the most senior engineer on an engagement gets their pull requests picked apart just as often as anyone else's, visibly, because that's what makes it safe for everyone else to do the same.

A review should block on architecture, not on style. We don't spend review cycles on formatting or naming conventions — that's a linter's job, and burning a senior engineer's attention on it is waste. Review time is reserved for the questions a machine can't ask: does this hold up under the load pattern we expect in eighteen months, does this integration handle the failure mode the vendor's docs don't mention, does this migration have a rollback path.

The test of whether a review culture is real or theatrical is simple: pull ten recent pull requests and count how many were meaningfully changed by review feedback, versus how many were approved as-is. If the number is close to zero, you don't have review — you have a merge button with an extra click in front of it.