# The Fallacies You'll Meet Most

Phase 1 covered what a fallacy is and why a broken argument can still feel convincing. Now the
field guide: the moves you'll run into again and again, in comment threads, meetings, headlines,
and your own head at 2 a.m. You don't need the Latin names memorized - the goal is recognition.
For each one: the name, a one-line definition, and a concrete example. Read for the pattern.

One thing up front: spotting a fallacy means the argument failed to *prove* its point, not that
the conclusion is false. A person can defend a true claim with a terrible argument. So "that's a
fallacy" is a reason to ask for a better argument, not a victory dance - see
[What Logic Actually Is](/guides/what-logic-actually-is) for that distinction in full.

## Attacks on the person, not the point

### Ad hominem
**Attacking the person instead of their argument.**

```text
"You think we should rewrite the billing service? You've only been
here three months. Sit down."
```

Notice what's missing: any response to whether the billing service should be rewritten. Maybe the
newcomer is wrong - but their tenure isn't the reason. Watch for this when an argument turns into
a referendum on the speaker's credentials, motives, or character.

### Straw man
**Distorting someone's position into a weaker one, then knocking that down.**

```text
Alex: "I think we should add more tests before the next release."
Sam:  "So you want us to stop shipping features forever? Great plan."
```

Alex never said "forever." Sam built a scarecrow and toppled it. The tell is a phrase like "so
what you're really saying is…" followed by something the person would never agree to. The straight
move is the opposite: restate their view in a form *they'd* accept, then respond to that.

## Forcing the shape of the choice

### False dilemma (false dichotomy)
**Presenting only two options when more exist.**

```text
"Either we ship tonight or the whole quarter is a failure."
```

Ship tonight, ship tomorrow, ship a smaller version, cut one feature - the real menu has more than
two items. False dilemmas thrive under pressure, because a fake either/or feels decisive. The
counter is one quiet question: "Are those really the only options?"

### Slippery slope
**Claiming one small step inevitably leads to disaster, with no justification for the chain.**

```text
"If we let one person work from home, soon nobody comes to the
office, and the company collapses."
```

Each arrow in that chain is a separate claim that needs support, and none is given. Slippery
slopes aren't always wrong - sometimes a step really does set off a chain - but the burden is on
whoever's claiming it to show *why* each link follows.

## Borrowed weight: authority, emotion, the crowd

### Appeal to authority
**"X said so" - when X is not a relevant authority, or is wrong.**

```text
"A famous physicist tweeted that this diet works, so it must."
```

Brilliant physics says nothing about nutrition. Even a relevant expert can be mistaken - authority
is a reason to take a claim seriously, not a substitute for the evidence behind it.

### Appeal to emotion
**Using fear, pity, or anger in place of reasons.**

```text
"Think of how stressed the team is. We can't possibly do a code
review on this one."
```

Stress is worth caring about, but it isn't an argument that this particular change is safe to
merge without review. When a claim makes you feel something strongly and gives you nothing to
check, slow down and ask: what's the actual reason here?

### Bandwagon
**"Everyone believes it, so it's true."**

```text
"Every startup is rewriting in this framework, so it must be the
right choice for us."
```

Popularity gets smuggled in as proof, but lots of people can be wrong together. What everyone's
doing tells you about trends - it doesn't tell you whether the thing is correct *for your
situation*.

## Conclusions that outrun the evidence

### Hasty generalization
**A sweeping conclusion drawn from too few cases.**

```text
"Two users complained about the new layout, so everybody hates it."
```

Two complaints are data, but they're not "everybody." Maybe the loudest two percent are unhappy
while the quiet majority is fine - ask whether the sample is big and representative enough to
carry the conclusion.

### Circular reasoning / begging the question
**The conclusion is assumed in the premises.**

```text
"This API is the most reliable because it never fails - and it
never fails because it's so reliable."
```

Strip it down and "reliable" is being proved by "reliable." Nothing outside the claim was ever
brought in - the tell is a vague feeling that you went around in a loop and ended where you
started.

### Post hoc / correlation isn't causation
**A happened, then B happened, therefore A caused B.** This is the big one - it costs people the most.

```text
"Ice cream sales and drowning both rise in summer, so ice cream
causes drowning."
```

Both are driven by a third thing: hot weather. The pattern is real; the causal story is invented.
Coincidence, reverse causation, or a hidden common cause are always on the table - before
accepting "A caused B," ask what *else* could produce the same pattern.

This has a formal cousin worth knowing: "If the deploy was bad, the site would be slow; the site
is slow, therefore the deploy was bad" is **affirming the consequent** - the site could be slow
for a dozen other reasons. [Implication & Conditionals](/guides/implication-and-conditionals)
walks through why that direction doesn't hold.

## A couple more you'll recognize

### Whataboutism
**Deflecting criticism by pointing at someone else's fault instead of answering.**

```text
"Our deploy process is a mess." - "Yeah? What about *their* deploy
process, it's way worse."
```

Their mess, even if real, says nothing about whether yours needs fixing. The original point still
stands, unanswered.

### No true Scotsman
**Redefining a term mid-argument to dodge a counterexample.**

```text
"A real engineer would never push to main." - "I push to main and
I'm an engineer." - "Well, no *real* engineer would."
```

The definition keeps shifting to protect the claim from any evidence against it - and a claim
that can never be wrong isn't telling you anything.

## The catalog at a glance

| Fallacy | The move | Example |
|---|---|---|
| Ad hominem | Attack the person, not the point | "You're too junior to have an opinion on this." |
| Straw man | Distort the view, then defeat the distortion | "So you want to ship nothing ever?" |
| False dilemma | Only two options when more exist | "Ship tonight or the quarter is ruined." |
| Slippery slope | One step → disaster, no chain shown | "Remote one day, company collapses." |
| Appeal to authority | "X said so" (irrelevant or wrong X) | "A physicist endorsed this diet." |
| Appeal to emotion | Feeling offered as a reason | "The team's stressed, so skip review." |
| Bandwagon | Popular, therefore true | "Everyone uses it, so it's right." |
| Hasty generalization | Big conclusion, tiny sample | "Two complaints, so everyone hates it." |
| Circular reasoning | Conclusion hidden in the premise | "Reliable because it never fails." |
| Post hoc | After, therefore because of | "Ice cream sales rise with drownings." |

## For builders

You'll meet post hoc more than any other fallacy in your work, wearing a specific costume:
**"it broke right after my deploy, so my deploy caused it."** Sometimes that's true; often it
isn't - a deploy is one event in a noisy system, and a dependency, a config flag, a traffic spike,
or a slow-burning bug crossing a threshold could all produce the same timing. "After" is a hint
about where to look, not a verdict. Before you write "deploy caused outage" in the incident
channel, check the evidence: timestamps, what *else* changed in that window, whether the symptom
matches your diff, whether reverting actually fixes it. Treat the deploy as a suspect to
investigate, not a confession to record - the same goes for "latency dropped after we added the
cache, so the cache fixed it." Correlation points your flashlight; it doesn't close the case.

## Practice: find the fallacy

Read each short argument and name the move. The goal is to feel the shape before you
reach for the label.

```text
1. "We shouldn't listen to her proposal - she's from a competing team."
2. "If we add this feature, users will ask for more, and soon we'll have no
   deadlines left. It's a slippery slope to chaos."
3. "Every engineer I know uses Vim, so it must be the best editor."
4. "The new deploy went out at 2pm and the site went down at 2:05pm. The deploy
   caused the outage."
5. "You want more tests? So you want us to miss every deadline from now on?"
```

<details>
<summary>Answers</summary>

1. **Ad hominem** - attacks the person's affiliation instead of engaging with the
   proposal.
2. **Slippery slope** - asserts an unstoppable cascade without showing why each link
   follows.
3. **Bandwagon** - popularity is offered as proof of quality.
4. **Post hoc** - temporal overlap is treated as causation without checking other
   explanations.
5. **Straw man** - distorts "more tests" into "miss every deadline" and defeats the
   distortion.

</details>

## Recap

- A fallacy means the argument failed, not that the conclusion is false - ask for a better argument, don't celebrate.
- **Ad hominem** and **straw man** dodge the real point: one attacks the person, the other attacks a distorted version of their view.
- **False dilemma** and **slippery slope** rig the shape of the choice - too few options, or an unjustified chain to disaster.
- **Appeal to authority/emotion** and **bandwagon** borrow weight from a source, a feeling, or the crowd instead of giving reasons.
- **Hasty generalization** stretches a tiny sample; **circular reasoning** hides the conclusion in its own premises.
- **Post hoc** is the one that'll bite you most: "after" doesn't mean "because." Always ask what else could explain the pattern.

Quick check before you move on:

```quiz
[
  {
    "q": "In a debate about a proposed budget cut, someone responds: 'She only supports the cut - she's never managed a team in her life.' What fallacy is this?",
    "choices": ["Straw man", "Ad hominem", "False dilemma", "Post hoc"],
    "answer": 1,
    "explain": "The reply ignores the argument for the budget cut and attacks the person's experience instead. Attacking the speaker rather than their reasoning is ad hominem."
  },
  {
    "q": "Your manager says: 'We either adopt this tool company-wide today or we fall hopelessly behind our competitors.' What's the flaw?",
    "choices": ["False dilemma - there are more than two options", "Appeal to emotion", "Circular reasoning", "Bandwagon"],
    "answer": 0,
    "explain": "Only two outcomes are offered - adopt now, or fall behind - when a pilot, partial rollout, or waiting are all real options. Presenting two choices as the whole menu is a false dilemma."
  },
  {
    "q": "A teammate notes: 'Sign-ups went up the same week we changed the logo, so the new logo is driving growth.' What's the problem?",
    "choices": ["The conclusion is assumed in the premise", "Two events overlapping in time doesn't prove one caused the other", "It attacks the logo designer", "It relies on what's popular"],
    "answer": 1,
    "explain": "Sign-ups rising after the logo change is correlation, not proof of causation. A marketing push, seasonality, or coincidence could explain it - that's the post hoc fallacy."
  }
]
```

Next we'll turn defense into offense: a practical toolkit for thinking clearly and pressure-testing arguments before they fool you.