Chapter 14: Worked Example: Handling a Contentious Review Disagreement

Why this matters

Chapter 8 covered the principles for handling disagreement; this chapter walks through one realistic, escalating disagreement from start to resolution, showing exactly how those principles apply turn by turn — the kind of scenario a "tell me about a time you disagreed with a reviewer" interview question is directly probing for, and a genuinely common real-world situation.

The scenario

An author submits a PR introducing a new caching layer for a frequently-queried endpoint. A senior reviewer objects to the specific caching library chosen.

Turn 1: initial disagreement, stated as a command

Reviewer: "Don't use this library — we should use Redis instead, like
everywhere else in the codebase."

What's happening: a command (Chapter 7) with a design-fit rationale hinted at ("like everywhere else") but not fully stated. The author now has to guess how strongly this is meant and whether there's more reasoning behind it.

Turn 2: the author pushes back, also without full context yet

Author: "I used this library because it has built-in TTL and LRU eviction
that Redis would require extra setup for. Seemed simpler for this specific
case."

What's happening: the author has now surfaced their own reasoning — this is exactly the "understand before persuading" move from Chapter 8, even though it happened somewhat reactively here rather than as a deliberate first step.

Turn 3: the reviewer surfaces the fuller context behind their initial command

Reviewer: "That's a fair point for this specific case in isolation. My
concern is more about consistency — we already run and operationally
monitor Redis for three other caching use cases, and adding a second
caching technology means our on-call team now needs to understand and
monitor two different systems instead of one. Is the TTL/LRU convenience
worth that operational cost, in your view?"

What's happening: the reviewer has moved from an unexplained command to a fully-articulated, concrete concern (Chapter 8's "matter of correctness/risk" — operational burden is a real, substantive cost, not pure stylistic preference) — and closed with a genuine question rather than a repeated command, inviting the author's perspective on the actual trade-off now that both sides understand each other's reasoning.

Turn 4: genuine engagement with the now-fully-understood trade-off

Author: "I hadn't considered the on-call/monitoring burden — that's a
real cost I wasn't weighing. I still think the built-in eviction saves
some implementation time, but I agree operational consistency probably
matters more here. I'll switch to Redis."

What's happening: once the actual trade-off was fully surfaced (not just asserted), the author updated their view based on genuinely new information — this is the disagreement resolving through mutual understanding, not through one party simply overriding the other.

An alternate branch: what if the author still disagreed after full understanding?

Author: "I understand the operational concern, but I think for THIS
specific service, we're planning to decommission it within two quarters
per the migration plan in TICKET-991 — the operational cost is real but
time-limited. Given that, I'd lean toward keeping the simpler library
for this short-lived case. What do you think?"

Reviewer: "I wasn't aware of the decommission timeline — that does change
the calculus somewhat. Let me think about it... actually, I think that's
reasonable given the short lifespan. Let's document the reasoning in the
PR so it's clear why this one service is an intentional exception to our
usual Redis-only convention."

What's happening: this shows genuine, good-faith disagreement resolving through new information (the decommission timeline), not through either party simply deferring to the other's authority — and the resolution includes documenting the reasoning (directly the companion Coding Standards book's Chapter 12 exception-handling discipline: explicit, visible, justified deviations rather than silent ones).

If neither new information nor persuasion had resolved it

Reviewer: "I still think consistency matters more here even given the
timeline, but I recognize this is genuinely a judgment call rather than
a clear-cut correctness issue. Want to get a quick second opinion from
the platform team, since they own our Redis infrastructure and monitoring?"

Author: "Sounds good, that seems like a fair way to settle it."

What's happening: exactly the healthy escalation from Chapter 8 — invoked only after genuine understanding was reached on both sides, framed as seeking a specific, answerable input from someone with relevant context (not "who's right"), and both parties visibly treating it as a legitimate, non-embarrassing next step rather than a loss for either side.

Common mistakes

1. Stopping at the initial, unexplained command/pushback exchange (Turns 1-2) without either side taking the "understand before persuading" step that actually resolves most apparent disagreements.
2. Treating the reviewer's seniority as the deciding factor rather than the substance of the concern — the scenario resolves well specifically because the actual trade-off (operational consistency vs. implementation convenience) gets debated on its merits.
3. Not documenting the reasoning when a legitimate exception is agreed upon (the decommission-timeline branch) — an undocumented exception looks, to a future reader, like an unexplained inconsistency rather than a deliberate, justified decision.
4. Escalating immediately at the first sign of disagreement (Turn 1), rather than first working through mutual understanding — premature escalation wastes a third party's time on a disagreement that direct conversation could likely have resolved.

Discussion / interview questions

1. "Tell me about a time you disagreed with a code reviewer (or an author, if you were the reviewer). How did you handle it?" Strong answer: Describes surfacing both sides' underlying reasoning first (not just repeating positions), classifying whether the disagreement was about taste or substantive risk, and either reaching resolution through new information/persuasion or escalating constructively when genuinely needed — mirroring this chapter's worked example structure.

2. "In the scenario where the author cites a decommission timeline the reviewer didn't know about, what made that disagreement resolve well?" Strong answer: Genuinely new information (the timeline) changed the actual trade-off calculation for both parties — the resolution came from updated understanding, not from either party simply asserting authority or giving up, and the outcome was documented explicitly as an intentional exception.

3. "When would you decide to escalate a disagreement to a third party, in a scenario like this one?" Strong answer: After both sides have genuinely stated and understood each other's reasoning, and the remaining disagreement is a genuine judgment call rather than an obvious right-or-wrong answer — framed as seeking input from someone with directly relevant context, not as a way to "win" the disagreement.

4. "What would you have done differently if you were the reviewer in Turn 1, applying what this book covers about phrasing feedback?" Strong answer: Lead with the fuller reasoning (operational consistency, monitoring burden) and a question, rather than an unexplained command — Chapter 7's guidance on questions vs. commands, applied to avoid the extra back-and-forth needed to eventually surface that reasoning in Turn 3.

Chapter summary / cheat sheet

• A disagreement often resolves the moment both sides' full reasoning is actually surfaced — Turns 1-2's unexplained command-and-pushback exchange only starts genuinely resolving once Turn 3 states the real underlying concern.
• Genuinely new information (like an undisclosed decommission timeline) can legitimately shift a resolution — this is the disagreement working as intended, not a failure of either party's original position.
• A resolved, justified exception should be documented explicitly, not left as a silent, unexplained deviation from the team's usual convention.
• Healthy escalation happens after mutual understanding is reached and the remaining disagreement is a genuine judgment call — framed as seeking specific input, not seeking a verdict on who's right.

---