Catch it
early.

The foundational fact of software quality is that the cost to fix a defect escalates the later it's found. A bug spotted during review costs almost nothing — the author changes a line before the code ever merges. The same bug caught in testing costs more: a failed build, a re-run, a context switch back to code you'd mentally closed. And caught in production it can be catastrophic — a paging incident, a rushed hotfix, corrupted data, angry customers, a postmortem. The rough industry shorthand is an order of magnitude per stage: 1× in review, 10× in test, 100× (or far more) in production.

That escalation is the entire economic argument for review, and it's the logic behind "shift left" — move defect detection as early in the pipeline as possible, because early is cheap. Code review is the earliest human checkpoint after the author, sitting right before merge, so it catches bugs at nearly the cheapest stage that exists. You're not spending reviewer time as a tax; you're buying down a cost that would otherwise balloon by 100× downstream. Frame review as insurance against the production cost curve and its value stops being a matter of taste and becomes a matter of arithmetic — which the next sections make exact.

Turn the cost curve into a return. Each bug that review catches is a bug that didn't reach production, so the value of catching it is the difference between what it would have cost in production and what it costs in review. With a 100×-vs-1× gap, every caught bug saves roughly 99 units of "fix cost." Subtract the cost of doing the review (the reviewer's time), and the net value is almost always strongly positive.

This is why review survives every "it's slowing us down" complaint: the complaint measures the visible cost (minutes waiting) and ignores the invisible savings (incidents that never happened). A review that catches even a handful of real bugs returns many times the time it took, because the production stage it prevented is so expensive. And the defect economics undersell it — review also spreads knowledge across the team, keeps the codebase consistent, and mentors junior engineers, none of which is in the cost model. But even on bug-cost alone, review pays for itself. The catch, which the second half of this handbook addresses, is that the ROI is only realized when review actually catches bugs — which depends entirely on the culture around it.

A high-ROI review focuses human attention on what only humans can judge and automates the rest. The reviewer should be reading for correctness (bugs, edge cases, error handling), design (is this the right approach?), security, readability, and test coverage — and should not be spending a single second on formatting or style, which linters and CI must handle automatically. Humans arguing about spaces is pure waste; the machine settles it.

Two structural habits multiply review's value. First, small pull requests. Reviewer effectiveness collapses as a change grows: a 50-line diff gets a careful line-by-line read that finds real bugs; a 2,000-line diff gets a skim and a reflexive "LGTM," which catches nothing and wastes everyone's time. One logical change per PR, big features split into reviewable increments. Second, timeliness: a pending review blocks the author, so fast turnaround keeps the whole team moving — a review that's thorough but three days late has its own large cost. And the reviewer should mark comments clearly as blocking vs. nit (optional), so the author knows what must change versus what's a suggestion. Get these right and review reliably catches bugs at the cheap stage — which is the only way the ROI in the math actually materializes.

Fix cost escalates by stage, so catching a batch of bugs in review is far cheaper than letting them reach production:

5 bugs fixed in review = 5; the same 5 in production = 500. The whole point of review is to move defects left onto the cheap end of this curve.

Review's net value is the cost it saves (bugs caught × the review-vs-prod gap) minus its own time cost — positive whenever it catches enough:

10 bugs caught, review cost 20 → 10×99 − 20 = 970 net, an ROI of ~49×. Catch nothing and it's just cost. The runnable version below computes the cost curve, net value, and ROI.

The math says review is valuable; whether your team gets that value depends entirely on the human dynamics, because review is one of the most emotionally charged interactions in engineering — someone is critiquing another person's work, in writing, often publicly. Do it badly and people avoid review, rush it, or dread it; do it well and it becomes the team's favorite way to learn.

The golden rule is review the code, not the coder. "This function is confusing" lands as an attack; "I found this hard to follow — could a comment or a rename help?" lands as collaboration, and gets the same fix without the sting. Phrasing suggestions as questions invites dialogue instead of defensiveness. And on the author's side, the discipline is to separate your identity from your code: feedback on a diff is not feedback on your worth, and the reviewer spending time on your change is doing you a favor. A team that internalizes both sides turns review from a bottleneck people resent into the mechanism by which the codebase stays healthy and everyone levels up — which is the moment the ROI in the math actually shows up in reality.

The first is the rubber-stamp on a giant PR. A 2,000-line change gets a glance and an "LGTM," which is negative value — you pay the review cost and catch none of the bugs, so the whole ROI collapses. This is the single most common way review fails: not too strict, but too big to actually review. The fix is entirely on the author's side — keep PRs small — which is why "small changes" is a cultural rule, not a nicety.

Two more. Nitpicking and gatekeeping: a reviewer who blocks on personal style preferences, relitigates settled decisions, or is condescending makes people dread review and route around it — automate style, distinguish blocking from optional, and remember the goal is shipping solid code, not winning. And slow reviews: a PR sitting for days blocks the author, breeds giant rebases, and quietly pushes the team toward skipping review under deadline pressure — treat timely review as a first-class responsibility, not something you get to when convenient. The through-line is that code review is a place where economics and empathy meet: the defect-cost curve makes it obviously worth doing, and the human norms are what let that worth be realized. Get both halves right — catch bugs at the cheap stage, and do it with small PRs and kindness — and review becomes the highest-leverage, best-loved quality practice a team has, instead of the bottleneck people quietly wish would go away.