# Code Reviews Without the Ego

- Link: https://dev.ejohnny.ro/code-reviews-without-ego/
- Published: 2026-10-19T11:37:30+03:00
- Author: eJohnny

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.

![Man sitting facing laptop](https://images.unsplash.com/photo-1562813733-b31f71025d54?
fm=jpg&q=60&w=1200&auto=format&fit=crop)

Man sitting facing laptop. Photo by Clint Patterson on Unsplash.

## 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 `x` does 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.

### Share this:

 * [  X ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=twitter)
 * [  Facebook ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=facebook)
 * [More](https://dev.ejohnny.ro/code-reviews-without-ego/#)

 * [  LinkedIn ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=linkedin)
 * [  Reddit ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=reddit)
 * [  Tumblr ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=tumblr)
 * [  Pinterest ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=pinterest)
 * [  Telegram ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=telegram)
 * [  WhatsApp ](https://dev.ejohnny.ro/code-reviews-without-ego/?share=jetpack-whatsapp)