Good code reviews improve code quality and build team trust. Bad code reviews create resentment and slow teams down. The difference comes down to etiquette: how you frame feedback, what you prioritize, and whether you treat the review as a collaboration or a judgment.
Early in my career, I got a code review that simply said: 'This is wrong. Redo it.' No explanation, no suggestion, no context. I spent two hours trying to figure out what was wrong, only to discover the reviewer disagreed with a naming convention. That experience shaped how I approach code reviews today.
Lead with Questions, Not Commands
Instead of 'This should be a `map`', try 'Have you considered using `map` here? It might make the intent clearer.' The difference is subtle but significant. Questions invite dialogue. Commands invite defensiveness.
Explain the Why Behind Every Suggestion
If you suggest a change, explain why. 'This could cause a memory leak because the event listener is not cleaned up in the effect's return function' is infinitely more useful than 'Add a cleanup function.' Context turns feedback into a learning opportunity.
Distinguish Preferences from Problems
Not every comment is a blocker. I use a simple prefix system: - **[nit]**: Style preference, take it or leave it - **[suggestion]**: I think this would be better, but your call - **[issue]**: This is a bug or will cause problems - **[question]**: I am genuinely asking, not hinting
This system removes ambiguity and helps the author prioritize feedback efficiently.
Praise Good Work
Code reviews are not just for criticism. When someone writes an elegant solution, say so. 'Nice use of discriminated unions here, really clean' costs you three seconds and might make someone's day. Positive feedback reinforces good patterns across the team.
Review the Code, Not the Person
Say 'This function could be simplified' instead of 'You overcomplicated this.' It is a tiny shift in language that makes a big difference in how feedback lands.
Good code reviews are an act of generosity. You are spending your time to make someone else's code - and someone else - better. Treat it that way.
Key Takeaways
- Frame feedback as questions to invite dialogue instead of defensiveness - Always explain the reasoning behind suggestions to create learning opportunities - Use a prefix system ([nit], [suggestion], [issue], [question]) to clarify intent - Praise good work to reinforce positive patterns across the team - Review the code, not the person - use 'this function' instead of 'you' - Good code reviews are collaborative, not adversarial - The goal is shared improvement, not catching mistakes