Developer Experience5 min read

Code Review

Give and receive code reviews that improve quality without creating friction - focusing on correctness, maintainability, and learning rather than style preferences.

Code ReviewPull RequestsEngineering CultureQualityCollaboration

skill: Code Review category: Developer Experience tags: [Code Review, Pull Requests, Engineering Culture, Quality, Collaboration] readingTime: 5

Code review is a quality gate, a knowledge-sharing tool, and a culture signal - all at once. Bad code reviews block velocity and damage team morale; good ones compound knowledge and catch real bugs. The goal is neither rubber-stamping nor nitpicking - it's making the system better while respecting the author's work.

Workflow

Author: write a great PRA well-prepared PR is reviewed faster, gets better feedback, and is less likely to cause friction. The author controls the review experience.
Reviewer: follow a consistent checklistWithout a checklist, reviews are inconsistent - catching style issues while missing security bugs. A systematic review covers the right layers in the right order.
Give constructive, specific feedbackVague or harsh feedback creates defensiveness rather than improvement. Specific, kind feedback with a rationale is more likely to be implemented and learned from.
Automate the automatableHuman reviewers should spend time on logic, security, and design - not on tabs vs. spaces or import ordering. Automate style with linters.
Build a healthy review cultureA team where reviews are feared, avoided, or superficial produces worse code and lower morale than a team with thoughtful, frequent reviews.

Output Format

Code review system: PR template, reviewer checklist, automated CI gates, and team review norms.

.github/pull_request_template.md:
  ## Summary
  ## Changes
  ## Testing
  ## Screenshots (if UI)

Review SLA: < 24h first review
PR size limit: < 400 lines
Automated: lint + type check + tests + security scan

Examples

Input

Output

Edge Cases & Gotchas

PRs that grow during review - Author adds more changes while review is in progress, invalidating previous review comments. Agree: during review, only fix issues raised - new features go in a separate PR.
Review cycles without progress - Reviewer requests changes, author changes something, reviewer requests more changes - indefinitely. Time-box: 2 review cycles max, then sync via video call.
Design disagreements in review - Architecture disagreements shouldn't block a PR that's otherwise correct. Raise a separate design discussion; don't block shipping on contested design opinions.
External contributor reviews - External contributors need extra context (why the codebase works the way it does) and extra patience. Thank them specifically for their contribution before requesting changes.

When to Break These Rules

Use pair programming instead of async PR review for complex, high-risk changes - real-time collaboration catches subtleties that async review misses.
Skip review for emergency hotfixes (production down) - ship first, review as a post-mortem step to learn from the fix.

Reference Files

https://google.github.io/eng-practices/review/
https://www.conventionalcomments.org/