How to Separate Your Emotions from Code Review

Red Lines, Request Changes

I submitted a PR and ten minutes later, the Slack notification went off.

The reviewer left a comment. My heart rate picked up slightly. Before I even clicked, I was already in defense mode. What kind of reflex is this? I opened GitHub. Red lines. Request Changes.

The first thought in my head: "What does this person have against my code?"

I know rationally that it's feedback about the code. But my gut reacts first. It was worse when I was junior. "Please rename this variable" sounded like "You're still not good enough." It was a time when my self-worth was tied to every line of code.

It's the Team's Code, Not Mine

After a few years of trial and error, I've picked up a few things.

When I get review comments, I wait 15 minutes before reading them. If I read them immediately, I tend to react defensively. Grabbing a coffee first makes a difference. It's like the emotions get filtered out. (Whether this actually works varies every time, to be honest.)

I also try not to think of it as "my code." Once it's merged, it belongs to the team anyway. I wrote the first draft, and the reviewer is the editor. Kind of like a writer and an editor. Thinking about it this way makes it easier. Slightly.

I also try to consider the reviewer's intent first. "Why did you write it this way?" might not be criticism -- it might be genuine curiosity. Text has no tone. But practicing this consistently is easier said than done.

Reviewing Is Hard Too

On the flip side, being a reviewer comes with its own struggles.

If I'm too direct, it feels cold. If I soften it too much, the point gets lost. Trailing off with "this is kind of..." feels awkward, and adding a smiley face to "how about doing it this way? ^^" feels equally awkward. How exactly are you supposed to write these things?

"This code is complex" and "you wrote this in a complex way" mean the same thing, but they land completely differently. Just changing the subject of the sentence can turn the same feedback into something constructive. I know this, but I forget when I'm in a rush.

The Day I Got 20 Comments

The most memorable review I ever received was from a senior engineer.

20 comments. At first, I couldn't breathe. How long is it going to take to fix all of this? But as I read each one, every comment had a "why" attached. They weren't just pointing things out -- they included context and alternatives.

That single PR taught me what felt like three months' worth of learning. Some people are just genuinely great at reviewing, and it shows.

I've also noticed that review culture varies wildly between teams. Some teams treat reviews as learning opportunities. Others turn them into ego battles. What makes the difference isn't skill -- it's trust. Honest feedback can only be received as good faith when there's a foundation of mutual respect.

That Half-Second Gap

Honestly, even now, my heart skips for about half a second when I see Request Changes.

Completely separating emotions from code is probably impossible. The fact that emotions get attached to code means you care about this work. That's not necessarily a bad thing.

But after that half second, I take a breath and remind myself: this is about the code, not about me. Then I read the review again.

Does this work every time? (I still don't know.)