Code review is not just about finding bugs; it's about knowledge sharing, mentorship, and maintaining code quality. It is one of the most high-leverage activities an engineering team can do.
Be Constructive, Not Critical
The goal of a code review is to improve the code, not to prove how smart you are. Focus on the code, not the person. Use "we" instead of "you."
- Bad: "You broke the build with this change."
- Good: "This change seems to cause a build failure. Let's check the logs."
Ask questions instead of making demands. "Have we considered handling the null case here?" is better than "Fix this null pointer exception."
Look for the "Why"
Don't just check if the code works; check if it solves the right problem. Understand the context and the trade-offs. Sometimes the "cleanest" code isn't the right solution if it introduces unnecessary complexity or performance regressions.
The Reviewer's Responsibility
As a reviewer, your job is to ensure long-term maintainability. Is the code readable? Is it testable? Does it follow the architectural patterns of the codebase?
Don't nitpick. Use automated tools (linters, formatters) for style issues. Don't waste human brain cycles on missing semicolons. Focus on logic, security, and architecture.
The Author's Responsibility
As an author, respect your reviewer's time. Write a clear PR description. Include screenshots or videos for UI changes. Self-review your code before assigning it. A small, focused PR is much easier to review than a massive 50-file change.
Building a Culture of Feedback
Psychological safety is paramount. Junior engineers should feel comfortable reviewing senior engineers' code. Mistakes should be treated as learning opportunities, not failures. When code review becomes a collaborative conversation rather than a gatekeeping exercise, the entire team levels up.