Code review is one of the highest-leverage practices in engineering. It catches bugs, spreads knowledge, and enforces standards. It is also, in most startups we work with, the single largest source of cycle-time drag in the development process.
The default mode at most teams is: an engineer opens a PR, waits 18 hours for someone to look at it, gets a round of nitpicks, addresses them, waits another day for a re-review, finally merges three days later. That is a 30-minute change that took three calendar days.
The fix is not "review less." The fix is reviewing differently.
The principles that matter
Review is for catching what tests do not. If your reviewer is checking that the code runs, you have a test coverage problem, not a review problem. Fix the tests first. Then review can focus on design, security, and intent.
Small PRs review faster. A 50-line PR gets reviewed in 10 minutes. A 500-line PR gets reviewed in 90 minutes and misses more. Cap PR size at around 400 lines of meaningful change. Larger work goes behind a feature flag and ships in chunks.
Review style is local convention, not universal truth. If your team argues about formatting in review, you are wasting human cycles on a problem a linter solves. Auto-format everything. Auto-fix style. Spend human review on things only humans can catch.
What to actually optimize for
The goal is fast PRs (mean time from "ready for review" to "merged" under 4 hours during work hours), high-signal review (catches real bugs and design issues), and low reviewer fatigue (no engineer is the bottleneck for everyone else).
Concrete practices that get you there:
- Round-robin reviewer assignment. Use CODEOWNERS plus a bot like Pull-Bot to distribute load. Stop tagging the same senior engineer on every PR.
- SLA on first response. Two hours during work hours. Faster is better. Slower means the author has lost context and the next round costs more.
- One reviewer for most PRs, two for sensitive ones. Most teams over-require reviewers. One competent review on a normal PR is enough. Auth, payments, infra-as-code, and prod migrations get two.
- Async by default, sync when stuck. If a review thread is on its third round of back-and-forth, jump on a 15-minute call. Type-it-out can lose to talk-it-out fast.
What good reviews focus on
The hierarchy of review priorities, in order:
Correctness first. Does this code do what it claims? Are the edge cases handled?
Security second. Does this introduce a vulnerability? SQL injection, auth bypass, secrets in logs, anything with user input.
Design third. Is this the right abstraction? Will it survive the next two features?
Style last, and only if it actually matters. If a linter could have caught it, do not raise it in review.
What to stop doing
Stop blocking merges on personal taste. "I would have written this differently" is not a review comment, it is an opinion.
Stop requiring senior approval on every PR. It centralizes a bottleneck and trains juniors to wait instead of own.
Stop letting PRs sit. A stale PR is the most expensive piece of code in your codebase, because someone is paying context cost every time they pick it back up.
Engineering throughput stuck?
If your team is reviewing fast but still shipping slow, the bottleneck is probably elsewhere. We diagnose process and tooling issues that compound over time.
Get a diagnostic