The first time I left a code review comment that genuinely upset someone, I didn’t realise I’d done it until two days later, when a colleague pulled me aside in the kitchen and said, “you know Marco basically rewrote his whole afternoon after your comment, right?”. I remembered the comment. It was three words on a pull request: “this is wrong”. I thought I was being efficient. What I had actually done was take a person who was trying to ship a feature and tell him, in public, that his work was bad, with no information attached.
I think about that comment often. Not because it was uniquely cruel, it wasn’t, but because it was a perfect example of how feedback fails. It was about him, not about the code. It was a verdict, not a conversation. And it landed in a Slack channel where five other people read it before he did.
Most feedback at work fails for the same reasons. The good news is that the patterns that fix it are pretty mechanical, and once you internalise them, they become the default shape of how you talk to people about work. These are the ones that took me roughly ten years of trial and embarrassment to land on.
Praise in public, criticise in private
This sounds like a corporate slogan, and it kind of is, but the underlying mechanics are real. When you praise someone in a public channel, you are giving them social capital they can spend. When you criticise someone in a public channel, you are taking it away, in front of an audience, whether you meant to or not.
The audience part matters more than people admit. A comment like “this PR has a few issues, see inline” reads completely differently in a DM than it does in #engineering with twelve people watching. Same words. Different power dynamic. The version in DM is information. The version in the public channel is, like it or not, a small public shaming, and most humans respond to public shaming by getting defensive, not by getting better.
So the rule I try to follow: praise lands in the place where the most people will see it. Critique lands in a DM, or on the PR itself if it’s substantive engineering feedback that needs to be on the record, but with care for tone. The exception is patterns the whole team needs to learn from, and even then I’ll often go to the person first and say, “I’d like to share this in tomorrow’s review as a teaching moment, are you okay with that?”. They almost always are. The asking is the whole point.
SBI, or how to make feedback about the work
The framework I keep coming back to is called SBI: Situation, Behaviour, Impact. It’s not flashy, but it forces you to do the one thing most feedback skips, which is talk about something concrete that happened, instead of something general about the person.
- Situation: when and where did this happen? “In yesterday’s standup”, “in the PR you opened on Monday”.
- Behaviour: what did the person actually do? Not what kind of person they are. “You merged the change without waiting for review”, not “you’re reckless”.
- Impact: what was the result? “The deploy went out before QA could test it, and we had to roll back”.
Compare these two:
“You’re being sloppy with reviews lately.”
“On the PR yesterday, you merged about ten minutes after opening it, before anyone had reviewed. The deploy went out, we had to roll back, and the on-call engineer lost two hours. What was going on there?”
The first one is a label. The second one is a story with a question at the end. The label invites a defence. The story invites a conversation.
A small but important rephrasing trick that came out of SBI for me: prefer “when X happens, the result is Y” to “you do X”. The second is about a person. The first is about a pattern. People can change patterns. They cannot easily change being-a-person-who-does-X without feeling personally attacked first.
”I noticed… what was the thinking?”
The single highest-leverage opener I’ve learned for code review is some version of “I noticed X, what was the thinking?”.
Years ago I would have written, “this is wrong, you should use a CTE here”. The opener “I noticed you wrote this as a subquery, what was the thinking?” is mechanically the same critique. It does completely different things to the conversation. It assumes there was thinking. It invites the author to explain it. And, crucially, it leaves room for the very real possibility that they had a reason I hadn’t considered.
About one in four times, when I ask “what was the thinking”, I get an answer that changes my mind. The query planner did something weird with the CTE in their version of Postgres. There was a constraint from a downstream consumer I hadn’t seen. They had tried the obvious approach first and it didn’t work. The opener turns out to be a load-bearing question, not just a politeness.
The exact code review I think about most was one where I had typed “this is wrong, the join is on the wrong key”, deleted it, and replaced it with “I read this and got confused at line 42, can you walk me through how the dim_customer join is meant to work here?”. The author replied with a paragraph explaining their model, realised mid-paragraph that the key was wrong, and fixed it themselves. No defensiveness. No back-and-forth. He came out of the review feeling smarter. I came out feeling like a competent reviewer, instead of a guy with a hammer.
Curiosity costs almost nothing. Judgment costs a lot. Most of the time, you want curiosity.
Timeliness, and the case against the annual review
There is a deeply unhelpful pattern in some companies where managers and senior engineers stockpile feedback for the annual or quarterly review. They jot down little notes. They wait. Then in a thirty-minute meeting in December, they hand over a printout of things the person did wrong in March that they should now reflect on.
This is, to put it mildly, useless. The person doesn’t remember March. They can’t course-correct on something they don’t recall. Worse, they now know that for the past nine months, you’ve been collecting evidence on them like a slightly creepy lawyer. The trust you’ve burned by stockpiling will take longer to rebuild than any specific behaviour took to become a problem.
The rule I try to follow: feedback within a week of the event, ideally within forty-eight hours. If something is small, I might mention it casually after a meeting. If something is bigger, I’ll book a fifteen-minute slot the same week. The half-life of useful feedback is short. After a week, the memory has fuzzed; after a month, you are basically writing fiction.
The corollary is that you have to be willing to give the small feedback too. A lot of people stockpile because each individual instance felt too minor to bring up. Then they accumulate, and what you eventually deliver feels like an ambush. The cure is the same as for most professional ailments: do the small reps. A “hey, quick thing about that meeting” in the corridor is so much cheaper than a list of grievances in a one-on-one six months later.
How to receive feedback gracefully
Half of getting good at feedback is being someone people can give feedback to. This is harder than it sounds, because the human reflex when criticised is to defend yourself, explain the context, or preemptively agree just to make the conversation end. All three are bad.
The default response I have trained myself to give is some version of “thanks, let me sit with that”. Not “you’re right”. Not “well actually, the reason I did that is…”. Just acknowledgement plus time. Sometimes I’ll add “can I come back to you tomorrow once I’ve thought about it?”. This buys you space to actually consider the feedback, separates the emotional reaction from the analytical one, and signals that you take their input seriously enough to think about it instead of reflexively rebutting it.
If, after sitting with it, you genuinely disagree, you can come back later and say so, calmly, with reasons. That conversation is completely different from the one where you reactively defended yourself in the moment. You have been thoughtful. They have been heard. Whatever the disagreement turns out to be, it is now about the substance, not about whether you can take it.
There is one extra reason this matters. People watch how you receive feedback and adjust how much they’re willing to give you. If you push back hard every time, you will, over months, simply stop being told things. That is the worst possible outcome for an engineer who wants to grow, and you’ll never know it’s happening, because by definition the information stops reaching you.
Takeaway
Feedback that lands well is almost never about being soft or sugar-coating things. It’s about being precise, being timely, and treating the work and the person as separate. Comment on the code, not the coder. Tell a story with a situation and an impact, not a label. Ask “what was the thinking” before you assume there wasn’t any. Praise where people can see it. Critique where they can hear it without an audience. And when feedback comes back at you, sit with it before you answer. Most of the friction I see between engineers isn’t about the work itself, it’s about the way the work gets talked about. You can’t always fix the work. You can almost always fix the talking.