Code Review Is a Social Skill, Not a Technical One

TL;DR: Identifying problems in code is junior-level work. The senior-level skill is delivering that feedback so the recipient hears it, understands the why, feels motivated to improve, and trusts you more afterward. This post breaks down the three elements every code review comment needs, using audio engineering's concept of gain staging as the framework.

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.

What's the actually hard part of code review?

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.

How does audio engineering relate to code review feedback?

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.

What three elements make code review feedback actually land?

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.

How do I give code review feedback to senior engineers?

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.

Why does code review style matter for my career?

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.

How can I systematically improve my code review skills?

The fastest entry point is the free Developer EQ Sprint workbook. Day 4 has you rewrite one of your own real code review comments three ways — blunt, warm, and teaching — and pick which version fits your team's actual culture. Takes 20 minutes and pays off the next PR you review.

If you want the full playbook, the book is $20. 16 chapters using music-production concepts (compression, EQ, gain staging) to translate engineering soft skills into something you can actually practice instead of vague "communicate better" advice.

FAQ

Should I use code review templates or rubrics?

Yes — but for yourself, not the PR author. Keep a personal checklist of what you check for (security, performance, naming, tests, the "why" behind the change). Run every PR through it. This stops you from leaving comments that are pet peeves vs. actual code quality issues.

How many comments is too many on one PR?

There's no fixed number, but the warning sign is when you're commenting on style more than substance. If you have more nits than blocking issues, the code is probably fine and you're nitpicking. Pull the lens back to the architectural questions: is this the right approach for the problem?

What if the PR author keeps making the same mistakes?

Then code review isn't the right medium for that feedback. Have a one-on-one. Repeating the same comment across PRs is frustrating for both sides and doesn't address the underlying pattern. A 15-minute pairing session beats 15 PR comments.

How do I push back on a senior engineer's feedback without burning the relationship?

Treat it like a code review of their review. "I see you're suggesting we extract this into a helper — my concern is that we'd only have one caller, and the helper would obscure what's happening locally. Can you walk me through the case where you'd reach for the extraction earlier?" Curiosity wins almost every disagreement that ego loses.

Are tools like CodeRabbit or AI reviewers a replacement for human review?

No, complement. Use AI to catch the mechanical stuff (null checks, obvious smells) so humans can focus on the architectural and intent-level feedback. The relationship-building part of code review is irreplaceable; the lint-level stuff is automatable.

This is part of the Developer EQ series on social skills for engineers. Get the free 2-week workbook or the book — $20.