Should authors self-review before requesting review?

Yes, always. A pre-flight self-review — reading your own diff as if you were the reviewer — catches roughly half the comments you'd otherwise get. It's the single highest-leverage practice for reducing review cycles.

Pair programming vs. code review?

Not mutually exclusive. Pairing produces higher-context code but doesn't create a written trail for the rest of the team. Many teams pair on complex work and still do a lighter async review for the record and to include team members who weren't in the pair session.

Should we require review for every change?

For production code, yes. For docs, tooling scripts, and truly trivial changes (typo fixes, config updates), some teams allow self-merge with post-hoc notification. The exception list should be short and well-defined; loose 'trivial' rules become the loophole through which real changes slip.

Code Review: How to Run PR Review That Improves Code

Code review is the practice of having engineers read and comment on each other's proposed changes before merge.

Code Review: The Habit That Shapes Every Codebase That Lasts

Code review is the practice of having one or more engineers read a proposed code change, comment on it, and approve (or request changes) before it is merged. The Google Engineering Practices doc and Michael Lynch's writing are widely-cited references. Done well, code review improves code quality, catches bugs, spreads context across the team, and mentors junior engineers. Done poorly, it becomes a bottleneck, a bikeshedding forum, or a rubber stamp that adds process cost without quality gain.

What review is for

Four goals, in priority order: (1) Does this change do what it claims to do and not obviously break anything? (2) Is the design reasonable given the codebase's conventions? (3) Will the next engineer be able to understand and modify this in six months? (4) Does it match style guidelines. Style should be enforced by linters and formatters, not humans; if reviewers spend time on formatting, the tooling is broken. Reviewers should not rewrite the author's code in comments — they should identify problems and let the author solve them.

Review latency is the top metric

The single biggest determinant of code review quality is turnaround time. Reviews that sit for 2+ days lose context on both sides; the author has moved on, the reviewer has to re-orient. Target: initial response within 4 hours during working hours; full round-trip within 24 hours for normal PRs. Teams that meet this bar keep PRs small, focused, and easy to review; teams that don't develop massive PRs, batching, and the whole system degrades.

PR size discipline

Small PRs get better reviews and merge faster. Studies (SmartBear, Google) consistently show reviewer effectiveness drops sharply past ~400 lines of change; past 1000 lines, review is essentially theater. Norms that work: PRs under 400 lines expected; anything larger requires a design doc or breakdown into stacked PRs. Feature branches with 20-file mega-PRs are the primary source of review pain — the fix is upstream discipline, not more reviewers.

Who should review

Single reviewer is fine for most changes; two reviewers only for high-risk areas (security, payments, data migrations, public APIs). Reviewers should include at least one person with domain context; only-adjacent-reviewers produce shallow reviews. Code ownership files (CODEOWNERS) that auto-request the right people scale better than 'ping whoever's around.' Junior engineers should review senior engineers' code too — reviewing above your level is one of the fastest ways to grow.

Feedback tone and mechanics

Distinguish blocking comments (must fix), suggestions (please consider), and nits (optional style). Use explicit prefixes: 'nit:', 'question:', 'blocking:'. Ask questions rather than assert corrections — 'why this approach vs. X?' opens dialogue; 'this is wrong, do X' shuts it down. Praise good code publicly; correct bad code without personal framing. Chesterton's Fence applies: before deleting something, understand why it was there.

Frequently asked questions

Should authors self-review before requesting review?: Yes, always. A pre-flight self-review — reading your own diff as if you were the reviewer — catches roughly half the comments you'd otherwise get. It's the single highest-leverage practice for reducing review cycles.
Pair programming vs. code review?: Not mutually exclusive. Pairing produces higher-context code but doesn't create a written trail for the rest of the team. Many teams pair on complex work and still do a lighter async review for the record and to include team members who weren't in the pair session.
Should we require review for every change?: For production code, yes. For docs, tooling scripts, and truly trivial changes (typo fixes, config updates), some teams allow self-merge with post-hoc notification. The exception list should be short and well-defined; loose 'trivial' rules become the loophole through which real changes slip.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database