Arguing well: evidence, fallacies, and changing minds

Chapter 5 taught the manners of disagreement and Chapter 6 the sentences; this chapter is the logic layer: what makes an argument actually strong, the fallacies that infest technical debate and the polite counters to each, and the discipline of updating your position in public without losing face, because in the long run the engineers people trust are not the ones who never lose arguments but the ones who lose them honestly.

The anatomy of a strong claim

Every argument worth having reduces to: claim, evidence, reasoning, and what would change your mind.

Claim:      We should cap retries at 3.
Evidence:   INC-214: uncapped retries turned a 2-minute blip into a
            40-minute brownout. Replay confirms the amplification.
Reasoning:  The cap trades a small recovery delay in rare cases for
            removing the amplification in all cases.
Updater:    If the replay showed capped retries failing legitimate
            traffic at >0.1%, I'd want a smarter backoff instead.

The fourth line is the one most engineers omit and the one that does the most work. Stating your updater in advance converts a position into a hypothesis, invites opponents to attack the crux instead of the periphery, and makes eventual concession cheap because you pre-announced its price. "What would change your mind?" and its twin "here's what would change mine" (Chapter 6) are the load-bearing sentences of honest debate; an argument with no possible updater is not a position, it is an identity, and identities do not belong in design reviews.

Evidence has ranks

Not all support is equal, and naming the rank of your own evidence buys enormous credibility:

1. Measured, in production, recently ("last Tuesday's traffic")
2. Measured, in a proxy (staging, benchmark, replay), with the gap to production named
3. Documented elsewhere (the paper, the vendor's numbers, another team's postmortem), with the transfer risk named
4. Experienced ("we tried this in 2024 and X happened"), decaying with age and org change
5. Reasoned (first principles, back-of-envelope)
6. Felt ("this makes me nervous"), admissible if labeled (Chapter 7's "thought:" comment)

The vivid anecdote versus the boring dataset is the classic collision: one memorable outage argues against a change that metrics say is safe. The resolution is not "data beats anecdote"; it is that an anecdote is a claim about the tail, and the question is base rates: "The March incident is real; how often does that condition occur, and does the fix cost more than the recurrence?" Respect the anecdote, then size it.

The fallacy field guide

The recurring bad moves of technical debate, each with its polite counter. The counters share one design: they name the pattern, never the person, and they hand back a legitimate move.

Two cautions about wielding this table. Naming fallacies in Latin at people ("that's ad hominem!") is itself a status move that hardens rooms; the counters above work because they redirect without labeling. And the fallacy-shaped argument is sometimes right anyway: Google's way may fit, the slope may really slip. The table earns you the right question, not the win.

Don't be confused: valid and sound are different properties, and engineers (who live in type systems) take to the distinction instantly. An argument is valid if the conclusion follows from the premises; it is sound if it is valid and the premises are true. "If migrations are risky we should batch them; migrations are risky; so batch them" is valid, and unsound the moment your migrations are actually cheap. Most bad technical arguments are perfectly valid reasoning from a stale premise, which is why "which premise does this rest on, and is it still true?" dismantles more designs than any logic-chopping ever will.

Probabilistic disagreement

Binary positions ("it'll work" / "it won't") make debates winner-take-all. Numbers make them tractable (Chapter 14's calibration, applied to conflict):

• "I'm at maybe 70% the migration finishes clean. Where are you?" Two engineers at 70 and 40 have a conversation about the 30-point gap; two engineers at "yes" and "no" have a fight.
• The friendly bet as a calibration device: "Coffee says the p99 moves less than 10ms." Trivial stakes, real effect: people state honest numbers when something, however small, rides on them.
• The cheapest-experiment reflex: "We're arguing about a testable claim. What's the smallest experiment that settles it, and is it cheaper than this meeting?" It usually is.

Changing your mind in public

The highest-status move in engineering debate, done correctly, is the visible update:

• Name the evidence, credit the source, restate your new position: "Sam's replay data changes my view. I was against the cap; the amplification is worse than I modeled, and I'm now for it. My remaining concern is only the config default."
• Update at the moment of persuasion, not three meetings later as a quiet drift. Rooms notice both, and only one of them builds the reputation that makes your unchanged positions carry weight.
• The corollary when you win: let people update without a toll. No "as I said all along", no recap of their previous position (Chapter 6's saboteur list). The cheaper you make surrender, the more of it you get, and "glad we landed together" costs nothing.

And the failure mode at the boundary: the last-word trap, where a settled argument continues because neither side can let a final restatement stand. The senior exit is to hand the last word away deliberately: "Fair. I think we've converged; you close it out and I'll write it up." Whoever writes the summary controls more than whoever spoke last anyway (Chapter 9's closing ritual, weaponized gently).

👉 Argument wins decisions; warmth wins the next hundred decisions, because people pre-decide how hard to listen to you long before you speak. The next chapter is the one engineers skip at the highest cost: rapport, humor, and being a human being at work without sacrificing professionalism. On to Chapter 27.