Here is a real PR comment I left on a junior engineer's pull request three years ago. I have changed names but kept the rest:
I thought, when I wrote it, that I was being efficient. Direct, specific, no fluff. I had been on-call all week and the review was the fifth one I had done that morning. The author of the PR responded with a thumbs-up emoji and refactored the code. I marked the comment resolved and moved on.
Three weeks later, in a one-on-one with my manager, she told me that the engineer had been quietly distressed by my reviews for the last two months. He had been considering asking to switch teams. The comments I had been leaving were, in his reading, dismissive and judgmental, and he had stopped speaking up in design discussions because he felt his ideas were being graded harshly. My manager had not been telling me this earlier because she had been hoping I would notice on my own. I had not noticed.
This article is what I have learned about giving and receiving feedback in the years since that one-on-one, mostly through making more mistakes and getting more direct feedback than I would have liked. It is mechanical, not motivational. The motivational version of feedback advice ("be kind", "assume good intent") has not done much for me; the mechanical version ("never give feedback before lunch", "the second sentence has to be the why") has changed my actual behavior.
The shape of useful feedback
The failure mode of the PR comment above is that it is critique without context. It states a problem ("this should be inlined") without explaining the underlying principle, and it states a judgment ("naming is confusing") without offering a path forward. The receiver has nothing to do with it except comply, and compliance under unclear authority feels worse than a longer comment with reasoning would.
The shape that I have settled into looks like this:
The rewrite of the original PR comment, in this shape:
The rewrite is six times longer. It is also six times more useful. The receiver knows what was specifically observed, why it matters, what underlying principle was being applied, and what action is being suggested as a discussion starter rather than a verdict. The thumb-up emoji response gets replaced by an actual conversation, which is what code review is supposed to be.
I cannot write the long version on every comment. Most of my reviews still have short comments on minor things. But the pattern I now follow is: any comment that is critical of an architectural choice gets the long version; any comment that is just style or syntax gets the short version. Calibrating the comment length to the weight of the critique avoids the trap I fell into, which was applying short-comment energy to comments that deserved a paragraph.
What "generously" means in section 3
The word "generously" in section 3 above is doing real work. The default human pattern when explaining why someone made a choice is to assume the choice came from inexperience or carelessness. The generous version is to assume the choice came from a real-but-incomplete model of the problem.
The non-generous reasoning sounds like:
Reasoning: it looks like you might not have considered the case where the input is empty.
The generous version sounds like:
Reasoning: my guess is that the empty case did not come up in your testing because the calling code in this file always has a non-empty input. That is reasonable. The catch is that this function will be reused later, and once it is, the empty case will surface.
The generous version preserves the receiver's competence and frames the gap as a contextual one rather than a personal one. The receiver does not have to defend themselves; they can just engage with the substance. That is the difference, in practice, between a code review that sharpens the team and one that drains it.
Receiving feedback well
The receiving side is, in my experience, harder than the giving side. The default reaction to feedback is defense, even when the feedback is fair. Defense is automatic and often invisible to the receiver. I have watched myself, in performance review conversations with my manager, hear feedback I disagreed with and immediately mount a counter-argument before I had actually understood the feedback.
The mechanical habit I have built is to delay any response to negative feedback by a beat. Specifically: when feedback lands that I want to push back on, I say "let me sit with that for a second" and I count to five before responding. The five seconds are not for thinking of a better counter-argument. They are for letting the autonomic defense reflex pass, so that the response I give is from a calmer part of my brain.
The second habit is to repeat the feedback back in my own words before responding. "What I am hearing is that you felt my comments on Marco's PR were sharper than they needed to be, and that he had been finding the cumulative tone hard to read." The repetition does two things. It checks my understanding (sometimes I have heard the feedback wrong, and the speaker can correct me before I respond to the wrong version). It also gives the speaker the experience of being heard, which makes the rest of the conversation more productive even if I end up disagreeing with the substance.
The third habit is to ask one clarifying question before responding. "Can you tell me about a specific moment where this came up? I want to make sure I am picturing the same situation you are." The clarifying question shifts me from response mode to investigation mode. It also surfaces specifics that abstract feedback does not always include, and the specifics are what I need to actually change my behavior.
None of these are dramatic. They are small habits. The aggregate effect is that I receive feedback better than I used to, and the people around me have started giving me feedback more often, which is the actual goal.
A short conversation that taught me a lot
A peer of mine on a previous team gave me feedback once that I have thought about a lot since.
Peer: "In design reviews, you tend to ask questions that sound like challenges. I do not think you mean them that way, but I have heard at least two engineers say afterward that they felt put on the defensive."
Me: (counted to five) "Can you tell me about a specific question I asked recently that came across that way?"
Peer: "Yesterday you asked Aisha why she was using Redis instead of Postgres. The way you asked sounded like you assumed Postgres was better and were waiting for her to justify the deviation. The actual question, I think, was a real one, but the framing was loaded."
Me: "That is fair. I think the question was real but I had not thought about how it would sound to her. What would have been a better framing?"
Peer: "Something like: 'I want to make sure I am following the tradeoff. What was the comparison between Redis and Postgres for this use case?' That treats it as an open question rather than a defense the speaker has to mount."
I did not change overnight, but I noticed the framing pattern in myself many times in the months that followed. The feedback worked because it was specific, generous about my intent, and offered a concrete alternative. It also worked because I had built the habit of asking the clarifying question instead of mounting a defense, which made the rest of the conversation possible.
On the asymmetry of giving and receiving
A practical observation that took me years to internalize: most engineers are willing to give critical feedback to people more junior than them and unwilling to give it to people more senior than them. The asymmetry is understandable but corrosive. Senior engineers who never receive critical feedback from their juniors stop getting better, because the junior engineers are the ones who can see the bad habits the seniors no longer notice in themselves. The team I am on now has a soft norm that any engineer at any level can leave hard feedback on any other engineer's PR, and the senior engineers explicitly thank junior engineers for hard comments. The norm took deliberate work to build but it has changed the team's quality bar visibly.
If you are a senior engineer reading this: the feedback you are not getting from juniors is the most valuable feedback you could be receiving. Make it explicitly safe for them to give it, by responding well the first few times, and by visibly applying the changes they suggest.
The PR comment three years later
The engineer whose PR I commented on at the start of this article is still on the team. I apologized to him, in a one-on-one, about a week after my manager's conversation with me. The apology was awkward; he was kind about it. We agreed on a habit where, if any of my comments on his PRs ever felt off to him, he could respond with a single emoji that meant "can we talk about this in person". He has used the emoji twice in three years. Both times, the conversations that followed were useful. Most of my comments are now closer to the four-part shape above, and his pull requests are some of the cleanest on the team.
The shift was not dramatic. I did not become a different person. I built two or three small habits, and the cumulative effect over years has been the difference between being someone whose reviews engineers dread and someone whose reviews they ask for. That is the version of feedback culture I aim for now. It runs on mechanics, not on intentions.