Code review practices are where engineering culture lives or dies. The mechanics — leave comments, request changes, approve — are easy. The hard part is doing reviews that actually catch bugs, transfer knowledge, and respect your colleagues’ time. Teams with great code review culture ship faster and have fewer production incidents than teams with either rubber-stamp approvals or pedantic blocking. Here is what separates the two.
Table of Contents
Review for Design, Not Style
Code formatting and minor naming conventions should be enforced by tooling — Prettier, Biome, ESLint, gofmt, ruff. If a human is leaving comments about indentation, tabs versus spaces, or “I would name this differently,” the team is wasting time.
Reviews should focus on questions the linter cannot answer: Is this the right abstraction? Does this introduce coupling we will regret? Is the error handling correct? Are there test cases missing? The Google engineering code review practices document is the canonical reference and worth reading top to bottom.
Small PRs Get Better Reviews
A 1500-line PR will not get a careful review. Reviewers either skim and approve or get overwhelmed and procrastinate. Aim for 200-400 lines of meaningful change per PR, broken from larger features into reviewable chunks.
This requires upfront planning — you have to design the change so it can ship in pieces, often hidden behind feature flags. The discipline pays off in reviewer attention and in the number of bugs caught before merge. See our CI/CD pipeline setup guide for feature flag and trunk-based development patterns.
Comments Should Distinguish Severity
Not every review comment is a blocker. Use clear conventions: `nit:` for minor preferences, `question:` for clarification requests, `suggest:` for optional improvements, and unmarked comments for things that need to change. Conventional Comments (conventionalcomments.org) formalizes this.
Authors should fix blockers, address questions, and use judgment on suggestions. Reviewers should not block on style preferences. This convention alone reduces review friction dramatically once a team adopts it.
Reviewers Are Responsible Too
A merged PR with a bug is the reviewer’s problem too, not just the author’s. This shifts the incentive from “find something to comment on” to “convince myself this is correct.” It also means reviewers need to actually run the code, not just read the diff.
For consequential changes, pull the branch, run the test suite, and exercise the feature. The 10 minutes spent catches issues that diff review never will. Combine this with the observability practices that surface production issues early.
Asynchronous First, Sync When Stuck
Asynchronous review respects everyone’s flow time and works across time zones. Most reviews should happen this way. But when a review thread reaches 5+ back-and-forth comments without convergence, switch to a 15-minute call. Text is a bad medium for nuanced disagreement.
Document the outcome of the call back in the PR thread for future readers. The GitHub blog post on humane code reviews covers the social dynamics well.
Wrap Up
Code review practices that work focus on design over style, small PRs over big ones, severity-tagged comments, shared responsibility, and switching to sync conversation when needed. Teams that get this right ship faster and have happier engineers. Pair good code review with API design best practices and a strong test culture, and your engineering velocity compounds in a way that no individual hire can match.
Frequently Asked Questions
How long should a code review take?
For a 200-line PR, 30-60 minutes of focused attention is right. Less and you’re skimming; more usually means the PR is too big or the design needs discussion before more review.
Should you require multiple reviewers?
One reviewer for most changes, two for high-risk areas (security, payments, auth). Three+ reviewers signals a process problem — the PR is either too big or you’re using review as risk theater.
What about pair programming as an alternative?
Excellent for complex problems and onboarding. Doesn’t fully replace async review (no record of decisions, no second pair of eyes from outside the original context). Use both.
How do you handle a reviewer who blocks on style?
Talk to them privately about it. Show them the team’s automated linting setup. If style preferences keep blocking, raise it as a team norm — explicit agreement on what review covers and what tooling covers.
Should AI tools review code?
AI reviewers (CodeRabbit, Greptile, Cursor’s review features) catch obvious bugs and inconsistencies well. They miss design context. Use them as a first pass to free human reviewers for the substantive work.
