# How do I take blunt code review feedback without getting defensive?

> Fix the easy 90% of the comments silently, batch the genuine disagreements into one short call, and never reply the same day you read them.

- Asked: 2026-10-17
- Answered: 2026-10-20
- Asked by: İpek
- Tags: kariyer, liderlik
- Source: https://muhammetsafak.com/just-ask/take-blunt-code-review-feedback-without-getting-defensive/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** A staff engineer left forty-odd comments on a PR I opened. My first instinct was to argue every single one and defend myself; it felt like my entire body of work was on trial.

I know that reaction hurts me, but I don't know how to suppress it. How do I take feedback this blunt—even harsh—without getting defensive and without damaging the relationship? I'm looking for concrete behavioral advice.


Short answer: forty comments on a PR usually means someone takes you seriously and is investing in your growth — not that you're under attack.

## Short answer

The urge to argue every one is completely normal; but acting on that urge will cost you. Separate the emotional reaction from the technical response.

## Why

1. **Don't reply the same day.** Read all forty, close the tab, come back after a few hours. The defensive reflex peaks in the first minutes and then fades. The replies people regret are the first drafts written in that first flush of anger.
2. **Separate the ego from the code.** The review is about the code, not about you. "This is wrong" means the code has a problem; it does not mean you're a bad engineer. Staff engineers [nitpick precisely because they take your work seriously](/just-ask/mentor-junior-without-doing-their-work/).

## What to do

1. **Triage the comments into buckets.** Objective bugs (just fix), style/convention (fix, it's cheap), genuine disagreements (discuss), and questions (answer). Thirty-five of forty usually fall into "just fix"; you're left with a handful you actually need to discuss.
2. **On the ones you disagree with, ask instead of defend.** "What's the exact failure mode you're worried about here?" turns a standoff into a conversation. Often you learn context you were missing; sometimes they learn yours. Either way it's cheaper than a comment war.
3. **Pick your battles — and have them out loud.** If there are three or four real disagreements, a 10-minute call resolves what forty comment threads won't. Text amplifies defensiveness on both sides.
4. **Assume good intent, but verify over time.** Most blunt reviewers aren't malicious, they're just terse. But if the feedback is genuinely disrespectful (mocking rather than technical), that's a separate matter — take it up with them or your manager. Bluntness is fine; contempt isn't.
5. **Say thank you, and mean it.** A short "thanks, this caught a real bug and I learned something about X" costs you nothing but changes the relationship. That person spent an hour on your code for free.

**Bottom line:** personally I'd fix the easy 90% silently, batch the real disagreements into one short call, and treat that reviewer as the most valuable free teacher I have that week. Early in my career the reviews that stung the most taught me the most; the engineers who stopped reviewing me hard were the ones who'd given up on me.

## Related Reading

- [How do I mentor a junior without just doing the work for them?](https://muhammetsafak.com/just-ask/mentor-junior-without-doing-their-work/) — Just Ask
- [How does the nature of the work change on the jump from senior to staff?](https://muhammetsafak.com/just-ask/how-does-the-nature-of-the-work-change-on-the-jump/) — Just Ask
- [How do I demonstrate the broader impact expected when moving from mid-level to senior?](https://muhammetsafak.com/just-ask/how-do-i-demonstrate-the-broader-impact-expected-when-moving-from/) — Just Ask