A code review is not a judgment of your intelligence. It is a judgment of the code. The sooner you and your team believe that, the faster you ship better software.
In practice, code reviews often feel personal. A comment like “why did you do it this way?” can sound like “you are stupid.” That feeling makes people defensive, and defensive people write worse code.
Here is how to review code without making it about the person.
Review the code, not the author
Talk about the code, never about the developer.
- Bad: “You should have used a library for this.”
- Good: “This logic duplicates functionality already in the standard library. Using it would reduce maintenance.”
- Bad: “This is confusing.”
- Good: “The variable name
xdoes not describe what it holds. Renaming it would make the flow clearer.”
Ask questions instead of making demands
A demand shuts down conversation. A question opens it.
- Bad: “Change this to use async/await.”
- Good: “Would async/await make this error handling easier to follow?”
The author may have a reason you do not know about. Asking first gives them room to explain.
Focus on what matters
Not every comment needs to be addressed. Separate blocking issues from preferences.
| Blocking | Preference |
|---|---|
| Security vulnerability | Indentation style |
| Data loss risk | Variable naming |
| Broken tests | Comment placement |
| Production outage potential | Function length (within reason) |
Let the small things go. Your time is better spent on issues that actually affect users.
Receiving review comments
When someone comments on your code, remember:
- They are reviewing the code, not you.
- They probably want the project to succeed, not to embarrass you.
- You do not have to agree with every comment, but you should respond to every comment.
If you disagree, explain why. If you agree, make the change and say thank you.
For solo developers
If you work alone, you still need code reviews. Ask a friend, a former colleague, or an online community to look at a pull request. The act of explaining your code to someone else often reveals problems before they even comment.
The goal
The goal of a code review is not perfect code. It is code that is clear enough for the next person to maintain safely — including you, six months from now.
Leave a Reply