Skip to main content

Receiving Feedback: Disagreement, Defense, and Growth

What This Concept Is​

The other half of code review is being the author under review. The skill is separating three things that get tangled inside you within half a second of reading a harsh comment:

  • what the reviewer said (the text)
  • what the reviewer probably meant (the intent)
  • what you feel about being reviewed

You cannot make reviews productive without keeping these apart. Most painful review threads are about #3 disguised as #1.

Why It Matters Here​

Senior engineers are not the ones who never get pushback. They are the ones whose replies keep the conversation moving toward the best code. That is a learnable habit, not a personality trait. It will also heavily shape how your work is perceived: an engineer who responds well to reviews gets the important PRs.

Concrete Example​

Reviewer's comment:

[design, substantive] Why is PricingEngine doing its own retry logic? We agreed to use RetryingClient everywhere after the 2025-Q3 incident. Route through that and delete the local retry loop.

Bad response (defensive):

"I already wrote this. RetryingClient doesn't support our case because of X. This is fine."

Why it fails: it does not engage with the reviewer's evidence (the Q3 incident), and it treats "I already wrote this" as a cost the reviewer owes. It ends the conversation instead of moving it.

Good response:

"Good catch -- you're right that we standardized on RetryingClient. My blocker is that our gateway returns 202 Accepted with a deferred webhook, and RetryingClient treats 202 as terminal. Options I see:

  1. Add a 202-aware policy to RetryingClient (one day, benefits everyone).
  2. Keep local retry but add a TODO and a link to this comment.

I lean toward (1) but it scopes up this PR. Preference?"

This version acknowledges the evidence, names the real constraint, offers two options with costs, and asks for input.

Common Confusion / Misconception​

"Disagreement = fight." A disagreement handled well is the most valuable part of review. It surfaces assumptions that neither person had written down. If you never disagree, either your work is unusually boring or one party is swallowing their concerns.

"Defense = weakness." Explaining why you did something is not weak; it is the evidence the reviewer asked for. Stonewalling is weak ("I did it, it works, move on"). Explanation is strong.

"Reviewer is always right." Senior reviewers are wrong often enough that a policy of auto-agree damages the codebase. You are accountable for the change. If you are right and can show evidence, stand by the decision.

"Reviewer is always wrong." The mirror failure: treating every comment as noise to be worn down. Teams notice this pattern within three PRs.

Tone escalation. Once a thread gets heated, take it off the PR. A five-minute voice call ends what six rounds of comments cannot.

How To Use It​

Reply pattern that rarely fails:

  1. Acknowledge what the reviewer said correctly.
  2. Address the concern with evidence (test, bug, spec, incident).
  3. Agree, modify, or push back, with specific reasoning.
  4. Ask for their preference if two options exist.
  5. Move the conversation toward resolution (by the end, one option is chosen).

Habits:

  • Read every comment twice before typing.
  • If you feel defensive, wait fifteen minutes. It is rarely urgent.
  • Separate "this comment is factually wrong" from "this comment stings." Only respond to the first.
  • Say "good catch" when it is one. Crediting reviewers cheapens nothing.
  • When you push back, put the evidence first, the conclusion second.
  • When you change your mind, say so plainly: "You're right, changed to X."

Google's guide on "handling pushback" is worth reading from both sides; the framing there is that the reviewer should not surrender either, which implies the author does not need to.

Check Yourself​

  1. What does a good reply look like when you believe the reviewer is wrong?
  2. Why is "I'll make the change" not always the best response?
  3. Give one sentence that de-escalates a heated thread.

Mini Drill or Application​

For each comment, write a one-paragraph response in the 5-step pattern above. Pick at least one where you disagree and one where you agree and change:

  1. "Why didn't you use the existing UserRepository?" (you used a new query for a real reason)
  2. "This isn't the way we do things." (no link, no evidence)
  3. "The tests don't cover the null case." (true; you missed it)
  4. "Strategy is overkill here." (you think it is correct; there are three credible algorithms)

Read This Only If Stuck​