Code Review Culture & Practice
Build a code review culture that improves quality, shares knowledge, and preserves team relationships through clear standards and empathetic feedback.
Code review is simultaneously a quality gate, a knowledge-sharing mechanism, and a cultural touchstone. Done well, it catches bugs, spreads expertise, and builds shared ownership. Done poorly, it creates bottlenecks, damages morale, and entrenches silos.
Review code, not the person who wrote it. Be explicit about comment weight. Praise excellent work. Set size limits on PRs. Prioritize correctness over style (automate style). Respond within 24 business hours.
Workflow
- Set team-wide review standardsInconsistent standards lead to inconsistent feedback, which feels arbitrary and unfair.
- Write empathetic, actionable review commentsHarsh or vague feedback triggers defensiveness and degrades collaboration.
- Focus on high-value review areasReviewers have limited time; focusing on correctness over formatting produces better ROI.
- Respond to reviews constructively as an authorHow authors respond to feedback shapes the culture as much as how reviewers give it.
- Prevent review bottlenecks and LGTM cultureRubberstamp reviews provide false safety; bottlenecked reviews destroy velocity.
Output Format
Published review standards, comment taxonomy in team docs, PR size limit policy, cycle time metrics tracked, review load balanced across team.
Examples
"NIT: `userData` could be named `user` since it's already in a users module-no action needed.""Blocking: This endpoint doesn't check if the `userId` in the request matches the authenticated user-any user could access any other user's data.""Q: Why is this using a raw SQL query here instead of the ORM? Is there a performance reason? Happy to keep it if so, just want to understand."Edge Cases & Gotchas
- Async cultures across time zones: set explicit SLA for reviews (24h) and use async-first tools (Linear, Notion) for discussion threads outside PR comments
- Junior engineers over-reviewed: more frequent, smaller PRs help build confidence; avoid "great but..." patterns that negate praise
- Draft PRs: agree on whether to review drafts-they provide early signal but can waste reviewer time if the design will change significantly
When to Break These Rules
- Hotfixes under active incident: pair review asynchronously or post-merge; velocity takes priority, but always close the loop with a proper review afterwards.
Reference Files
Google Engineering Practices – Code Review: https://google.github.io/eng-practices/review/Conventional Comments: https://conventionalcomments.org/Thoughtbot code review guide: https://github.com/thoughtbot/guides/tree/main/code-review