The Psychology of Code Reviews: Giving and Receiving Feedback

The Psychology of Code Reviews: Giving and Receiving Feedback

Code reviews are not about code. They are about people.

I know this sounds wrong. Code reviews look at code. They comment on code. They approve or reject code. Everything about them seems to be about code.

But after hundreds of code reviews, on both sides of the conversation, I have learned something important. The technical part is easy. The human part is hard.

A poorly handled code review can damage relationships, kill morale, and make people afraid to contribute. A well handled code review can build trust, spread knowledge, and make everyone better.

Let me share what I have learned about the psychology of giving and receiving feedback through code reviews.

The Vulnerability of Sharing Code

There is something personal about code. Even though we tell ourselves “you are not your code,” the line blurs when someone is pointing out problems with something you created.

Sharing code for review is an act of vulnerability.

You are saying “here is my work. Please find its flaws.” That takes courage. Even experienced developers feel a flutter of anxiety when they see that first comment appear.

I have felt this myself. I have written code I was proud of, submitted it for review, and felt my stomach drop when I saw the notification. Even when I knew the feedback would be constructive. Even when I trusted the reviewer.

Understanding this vulnerability is the first step to being a good reviewer. The person on the other side of the screen is not a machine. They are a human who put effort into something and is now waiting to see if that effort was good enough.

How It Feels to Receive Criticism

Let me describe what happens inside my head when I receive code review feedback. I am not proud of all of it. But I think it is honest.

First reaction: defensive.
My brain looks for reasons why the reviewer is wrong. They did not understand the context. They missed something. Their suggestion is worse than my original.

Second reaction: personal.
The criticism feels like it is about me. My skills. My judgment. My value as a developer.

Third reaction: rational.
If I am lucky, the defensiveness passes. I read the comment again. I consider whether it has merit. Most of the time, it does.

The third reaction is where growth happens. But the first two reactions are real. They happen every time. A good code review process accounts for these reactions. A bad one ignores them and makes everyone miserable.

The Feedback That Helps vs. The Feedback That Hurts

Not all feedback is equal. Some feedback makes me better. Some feedback makes me want to quit.

Feedback that helps:

• Points to a specific problem

• Explains why it is a problem

• Suggests an alternative (or asks a question that leads me to one)

• Is kind without being soft

• Acknowledges what works, not just what is wrong

Feedback that hurts:

• Is vague (“this is bad” with no explanation)

• Is personal (“you should know better”)

• Is sarcastic or mocking

• Makes demands without reasoning

• Focuses only on negatives

I have received both kinds. The helpful feedback made me a better developer. The hurtful feedback just made me resentful. The content was sometimes similar. The delivery made all the difference.

The Rules I Follow When Giving Feedback

After years of being on both sides, I have developed rules for giving feedback. I break them sometimes. But I try to follow them.

Rule 1: Assume good intent.
Assume the person wrote the best code they could with the information they had. Do not assume laziness, ignorance, or carelessness.

Rule 2: Focus on the code, not the person.
Say “this variable name is confusing” not “you named this badly.” Say “this approach might cause problems” not “you did this wrong.”

Rule 3: Explain the why.
Do not just say “change this.” Say “change this because…” The explanation helps the author learn. It also opens the door for discussion if your reasoning is flawed.

Rule 4: Ask questions instead of making demands.
“What do you think about handling this edge case?” is softer than “you missed this edge case.” Questions invite collaboration. Demands invite resistance.

Rule 5: Point out what works.
Code reviews should not only be about problems. Mention things the author did well. It builds trust and makes the criticism easier to hear.

Rule 6: Be humble.
You might be wrong. Your preference might not be better. Your suggestion might have downsides you have not considered. Act like it.

How I Learned to Receive Feedback

Receiving feedback well is a skill. I was not born with it. I had to learn it.

I had to learn to pause before responding.
My first reaction was always defensive. I learned to wait. To take a breath. To read the comment again. To assume good intent. To respond after the defensiveness passed, not during it.

I had to learn to separate my code from myself.
This is still hard. But I remind myself: the reviewer is criticizing the code, not me. The code is something I made. It is not who I am.

I had to learn to say thank you.
Even when the feedback felt harsh. Even when I disagreed. “Thank you for reviewing” changes the dynamic. It acknowledges the effort the reviewer made. It keeps the relationship positive.

I had to learn to ask clarifying questions.
Instead of getting defensive, I learned to ask “can you help me understand why this is better?” or “what problem do you see with my approach?” These questions turn criticism into conversation.

The Role of Trust

Trust changes everything in a code review.

When trust is high, feedback feels helpful. When trust is low, feedback feels like an attack.

I have been on teams with high trust. Reviews were direct but kind. People assumed good intent. Disagreements were discussions, not fights. Everyone got better.

I have been on teams with low trust. Reviews were guarded. People hid their code to avoid criticism. Feedback was seen as political. Everyone got worse.

Building trust takes time. It happens through consistency, through kindness, through admitting when you are wrong, through showing up for each other. Code reviews are not separate from team culture. They are a reflection of it.

The Size Problem

One of the biggest psychological factors in code reviews is size.

Small reviews feel manageable. Large reviews feel overwhelming.

I have received reviews with hundreds of changed lines. My eyes glazed over. I skimmed. I missed things. I felt resentful about the time it took.

I have sent large reviews and wondered why I got shallow feedback. Now I know. I was asking too much of the reviewer.

The research is clear. Small, frequent reviews are better than large, infrequent ones. They are easier to review. They produce better feedback. They cause less stress.

If your review has more than 200-300 lines changed, consider whether it could be broken into smaller pieces.

The Ego Trap for Reviewers

There is an ego trap in being a reviewer. It feels good to find problems. It feels good to be right. It feels good to have your suggestions accepted.

This feeling can corrupt your feedback.

You might start looking for problems to prove your value, not because they matter. You might suggest changes that are matters of taste, not substance. You might insist on your way because it is your way, not because it is better.

I have fallen into this trap. I have left comments that were technically correct but unnecessary. I have argued for my preferences as if they were universal truths. I have made reviews about me, not about the code.

The best reviewers check their ego at the door. They ask: does this comment actually matter? Is this my preference or an objective improvement? Am I helping or just showing off?

The Power of “Nit”

One small word has changed how I give feedback. “Nit.”

Short for “nitpick.” It signals that a comment is minor. That it does not block approval. That it is a suggestion, not a demand.

“Consider renaming this variable for clarity. Nit.”
“This line has extra whitespace. Nit.”
“This comment is outdated. Nit.”

The word gives permission to ignore. It reduces pressure. It separates must-fix from nice-to-fix.

I use “nit” constantly now. It makes my feedback feel less heavy. It lets authors use their judgment about what matters. It keeps reviews moving.

The Thank You That Changes Everything

Here is a small practice that has transformed code reviews for me.

At the end of every review, I say thank you.

“Thanks for this work.”
“Appreciate you tackling this.”
“Nice approach on the error handling. Thanks.”

It takes two seconds. It costs nothing. But it changes the emotional tone completely.

The author just spent time and energy creating something. They put themselves out there. Acknowledging that effort makes the criticism that came before it much easier to hear.

I have received reviews that were nothing but criticism. Even when the criticism was valid, I felt bad at the end. I have received reviews that ended with a simple “thank you.” The same criticism felt completely different.

Try it. Say thank you. It matters.

Closing Thoughts

Code reviews are not about code. They are about people.

People who feel vulnerable. People who want to do good work. People who have egos and fears and hopes. People who will remember how you made them feel long after they forget what you said.

The best technical feedback in the world will fail if it is delivered poorly. The most thorough review will backfire if it ignores the human on the other side.

Give feedback like you are talking to a teammate you respect. Because you are.

Receive feedback like someone is trying to help you get better. Because they probably are.

Say thank you. Assume good intent. Focus on the code, not the person. Be humble. Be kind.

The code will get better. And so will the people writing it.