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

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.

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.