Your engineers get more written feedback from code review than from you.
Think about it. A one-to-one happens every week or two, if it happens at all. A performance review happens once or twice a year. A pull request gets comments every single day. For most developers, the review queue is the main place anyone tells them how their work lands.
So here's my question. What does your review queue sound like?
When Debra and I had Claude Silver, Chief Heart Officer at VaynerMedia, on the Corey-osity Unleashed podcast, she described the manager everyone wants to work for. Their feedback is "never too critical," and it lands "as a gift."
The idea I took away from her is simpler. The best feedback doesn't sting. It glows.
Most engineering teams I've worked with get this backwards. They treat a sharp review comment as a sign of rigour. It isn't. It's a sign nobody taught the reviewer how to write one.
Your Review Queue Is a Feedback System
Code review exists to catch bugs. Ask any developer and they'll tell you so.
Bacchelli and Bird studied code review at Microsoft, surveying 165 managers and 873 programmers. Developers ranked "finding defects" as their top motivation. Then the researchers read 570 real review comments. The most common topic wasn't defects. It was code improvements: readability, comments, consistency, dead code. The outcomes they found included knowledge transfer and team awareness.
Read it again. Developers think review is a bug filter. In practice it's a teaching channel. Every comment teaches the author something about the code, and something about how this team treats people.
If your comments read like a prosecutor's notes, you're teaching both lessons at once.
The Sting Has a Measurable Cost
Google took this seriously enough to study it. In Predicting Developers' Negative Feelings about Code Review, Carolyn Egelman and her colleagues surveyed 1,317 Google developers and matched their answers against review logs. They called the bad experiences "pushback."
The good news first. 87% of Google developers said they were at least moderately satisfied with code review. 96% said it improved their code.
Now the rest. 57% reported a negative experience with code review at least once a quarter. 26% reported one at least once a month.
Across ordinary reviews, 11% left the author with at least one feeling of pushback. Then the researchers looked at reviews running long on all three of their measures: shepherding time, reviewing time and rounds of review. On those, 49% of authors reported pushback and 22% reported interpersonal conflict.
When the team dug into what caused it, four factors stood out:
- Comments on code style
- The tone of the feedback
- Low familiarity with the codebase
- No rationale given for the request
Two of those four are about how the reviewer writes, not what the code does. The consequences people described: wasted time, negative emotions, offline conversations to patch things up. Interviewees talked about shock, frustration and shame.
Shame. From a pull request.
The researchers also asked whether authors felt positive about submitting similar changes in the future. 4% of authors on ordinary reviews said no. On the long, grinding reviews, 8% said no. Think about what this means on your team. A junior developer gets three harsh rounds on a refactor. Next time they spot a messy module, they leave it alone. Nobody sees the fix they didn't make.
I'm not sure about this part: the Google numbers come from one large company with a mature review culture. I couldn't find comparable data for small teams or startups, where one harsh senior reviewer might shape the whole tone.
Smart Doesn't Excuse Sharp
Every team has one. The brilliant reviewer whose comments read like insults with line numbers. People tolerate it because the reviewer is right about the code.
Claude Silver had a great answer for leaders who think being the smartest person in the room is the job. She told us she'd ask them how they know. She'd point out the room is smarter than any one person in it. And she'd tell them their teammates receive them differently from how they think they come across.
The open source world learned this in public. In September 2018, Linus Torvalds apologised for his behaviour on the Linux kernel mailing list, calling his personal attacks "unprofessional and uncalled for." He took time off to "get some assistance on how to understand people's emotions and respond appropriately." This is the person who wrote the kernel. Being right about the code never made the attacks okay, and he said so himself.
If Linus rethought his review style, your senior engineer has no excuse.
What Glowing Feedback Looks Like
Glowing doesn't mean soft. It doesn't mean approving bad code to keep the peace. Silver's point is about how the message lands, not whether you send it.
Google's own guide to writing code review comments opens with a short summary: "Be kind. Explain your reasoning." Then it gets specific. Comment on the code, never the developer. Their example is worth stealing.
Sting: "Why did you use threads here when there's obviously no benefit to be gained from concurrency?"
Glow: "The concurrency model here is adding complexity to the system without any actual performance benefit that I can see. Because there's no performance benefit, it's best for this code to be single-threaded instead of using multiple threads."
Same fix. Same standard. One version makes the author feel stupid. The other teaches them why.
The guide also tells reviewers to point out what's good: "people learn from reinforcement of what they are doing well and not just what they could do better." A developer cleaned up a messy algorithm? Say so. You learned something from their change? Say so, and say why.
Label your comments
The cheapest fix I know is labelling. Google's guide suggests marking comments as "Nit," "Optional," or "FYI." Conventional Comments goes further, with labels like praise, suggestion, issue, question and nitpick, plus a (blocking) or (non-blocking) tag.
Labels fix two of Google's four pushback causes at once. A "nitpick (non-blocking)" tag tells the author a style preference won't hold up their merge. A "question" label turns an accusation into curiosity. And Conventional Comments says this about praise: "Try to leave at least one of these comments per review." It also warns against false praise. Look for something real.
Give a reason with every request
No rationale was one of the four pushback causes. If you want something changed, say why. "Rename this" stings. "Rename this to retryCount so the next reader knows it's a counter, not a flag" teaches.
Take long threads offline
Long review times and many rounds marked the reviews where pushback spiked. If a thread hits its third round, stop typing. Walk over or jump on a call. Ten minutes of talking beats two days of comment ping-pong.
This Is a Leadership Problem, Not a Tooling Problem
Here's where I'll get opinionated. Review tone isn't the reviewer's private business. It's culture, written down, with timestamps.
Our research at Step It Up HR found 99.5% of people say they've had one or more types of bad boss. A lot of those bad experiences don't come from formal reviews. They come from the daily drip of small interactions. On an engineering team, the review queue is where most of the drip happens.
I wrote before about how AI now audits your code while nobody audits your feedback. Code review comments are the easiest feedback in your company to audit. They're already written down. You don't need a survey. You need to read them.
So do this tomorrow:
- Read the last 20 review threads on your team. Count the praise comments. Count the comments with no reason attached.
- Agree on labels. Pick Google's three or the Conventional Comments set. Put it in your contributing guide.
- Model it yourself. Leave one specific, sincere praise comment on every review you do this week. Not "nice." Tell them what they did well and why it matters. I've argued before "great job, team" is not recognition. The same goes for "LGTM."
- Coach the sharp reviewer privately. Show them the Torvalds apology. Show them the Google numbers. Ask how they want their comments to land.
Your engineers will read more of your team's feedback in the pull request queue than anywhere else.
What would they say about how it makes them feel?