Code Review Is a Social Skill, Not a Technical One

Let me paint a picture you've definitely seen before.

Senior engineer opens a PR. Leaves 47 comments on a junior's code. Every comment is technically correct. Suggestions are valid. The code would genuinely be better if every piece of feedback were applied.

The junior closes their laptop, considers switching careers, and doesn't open another PR for three days.

The senior engineer has no idea anything went wrong. They were helping.

The Diff Is the Easy Part

Here's my hot take: identifying what's wrong with code is a junior-level skill. Any decent engineer can spot a missing null check, a poorly named variable, or an N+1 query.

The senior-level skill is delivering that feedback in a way that:

1. The person actually hears it
2. They understand the why, not just the what
3. They feel motivated to improve, not demoralized
4. The relationship is stronger afterward, not weaker

That's four objectives, and none of them are about code.

The Audio Engineering Parallel

In music production, there's a concept called gain staging. It's about making sure the signal level is right at every point in the chain. Too hot and you get distortion. Too quiet and you get noise.

Code review feedback has the same problem.

Too hot (gain too high):

"This is wrong. Why would you do it this way? Have you read the style guide?"

Distortion. The message is destroyed by the delivery. The reviewer might be 100% correct, but the recipient hears "you're incompetent" and shuts down.

Too quiet (gain too low):

"Looks good! Maybe consider changing this one thing if you want, no big deal either way."

Noise. The signal is so buried in hedging that the recipient has no idea anything actually needs to change. The problem ships to production.

Proper gain staging:

"This works, but there's a pattern we use for this scenario that'll save you headaches when we scale this table. Here's an example from the payments service — same situation, and we learned the hard way. Want me to walk through it?"

Clear signal. No distortion. No noise.

The Three Things Every Code Review Comment Needs

After years of getting this wrong (and having it done wrong to me), I've landed on three elements that make feedback actually land:

1. Acknowledge the Intent

Before you tell someone what to change, acknowledge what they were trying to do. This isn't about being nice — it's about showing you actually read and understood their approach before dismissing it.

Bad: "Don't use a for loop here."

Better: "I see you're iterating to build the lookup — a Map would give you O(1) access here instead of O(n) on each check."

The second version shows you understood their goal. That changes the entire emotional context of the feedback.

2. Explain the Why, Not Just the What

"Use dependency injection here" is a command. "We use dependency injection for services like this because it lets us swap the email provider in tests without hitting the real API — saves about 30 seconds per test run" is a lesson.

Commands create compliance. Lessons create understanding.

If you can't explain why something should change, maybe question whether it actually needs to.

3. Distinguish Between Blocking and Non-Blocking

Not every comment is a blocker. And when you leave 30 comments without indicating priority, the author has no idea what actually needs to change before merging.

I use a simple system:

• blocking: "This will cause a bug / break the build / violate a security constraint. Must fix."
• suggestion: "This would be better but won't break anything. Your call."
• nit: "Style preference. Ignore if you want."

Label them explicitly. It's one word of effort that saves hours of confusion.

The Hardest Part: Reviewing Up

Everything above gets 10x harder when you're reviewing a senior engineer's code. Or your manager's. Or the person who designed the system you're modifying.

Most people just approve and move on. That's a missed opportunity.

The trick is framing. Instead of "this is wrong," try genuine curiosity: "I might be missing context here — is there a reason we're not using the cached value? I would've expected that to be faster, but maybe there's a freshness requirement I don't know about."

That's not weakness. That's intelligence. You're giving them an out while still raising the concern. If there IS a reason, you'll learn something. If there isn't, they'll fix it without losing face.

Your Code Review Is Your Reputation

Here's what most engineers don't realize: your code review comments are read by more people than your actual code. Managers skim PRs. Teammates watch how you interact. Future interviewers at your next job will look at your public GitHub activity.

Every review is a tiny billboard for how you think, how you communicate, and how you treat people.

Make it a good ad.

Go Deeper

Code review dynamics are just one chapter in the broader challenge of developer communication. If this resonated, the Developer EQ book covers the full spectrum — from reading a room to navigating conflict to building genuine influence on your team.

The live cohort takes it further with real practice sessions. We actually role-play code review scenarios (and yes, it's uncomfortable, and yes, that's the point).

This is part of the Developer EQ series on social skills for engineers.