Code review is one of the most impactful practices a team can adopt. Done well, it catches bugs, spreads knowledge, and elevates the entire team's skills. Done poorly, it becomes a bottleneck that breeds frustration.
After leading development teams for over five years, here's what I've learned about making code review work.
The Reviewer's Mindset
Start with Why
Before diving into the code, understand the context. Read the PR description, check the linked ticket, and understand what problem is being solved. You can't evaluate a solution without understanding the problem.
Prioritize Your Feedback
Not all feedback is equal. I use a simple system:
- 🔴 Blocker: Must be fixed. Security issues, bugs, data loss risks.
- 🟡 Suggestion: Should be considered. Better patterns, performance improvements.
- 🟢 Nit: Nice to have. Style preferences, naming suggestions.
Always label your comments so the author knows what's required versus optional.
Ask Questions, Don't Command
Instead of:
> "This is wrong. Use a Map instead."
Try:
> "Have you considered using a Map here? It would give O(1) lookups instead of O(n)."
Questions invite discussion. Commands create defensiveness.
The Author's Responsibility
Small, Focused PRs
The single most important thing you can do as a PR author is keep your changes small and focused. A PR that touches 20 files across 5 features is nearly impossible to review well.
Guidelines:
- Aim for under 400 lines of changes
- One concern per PR
- Split refactoring from feature work
Write a Good Description
Your PR description should answer:
- What does this change do?
- Why is this change needed?
- How does it work? (for complex changes)
- Testing — how was it tested?
Self-Review First
Before requesting review, review your own code. I catch 30-40% of issues during self-review. Look for:
- Leftover debug logging
- Missing error handling
- TODO comments that should be addressed
- Test coverage gaps
Team Culture
Speed Matters
Slow reviews kill momentum. Set a team expectation for review turnaround time. My teams aim for:
- First review within 4 hours
- Follow-up reviews within 2 hours
Celebrate Good Code
Don't only leave comments when something is wrong. Call out clever solutions, clean code, and good test coverage. A simple "Nice approach!" goes a long way.
Pair Review for Complex Changes
For large or architecturally significant changes, sit together (or screen share) and walk through the code. Written reviews can miss nuance that a conversation catches.
Automation
Let machines handle what machines do best:
- Linting and formatting: ESLint, Prettier — autofix on save
- Type checking: TypeScript strict mode in CI
- Test coverage: Fail CI if coverage drops
- Bundle size: Alert on significant bundle increases
This frees reviewers to focus on logic, architecture, and design.
Conclusion
Great code review is a skill that takes practice. Focus on understanding context, prioritizing feedback, and maintaining a culture of respect and speed. Your codebase — and your team — will be better for it.