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 for that distinction in full.

Attacks on the person, not the point

Ad hominem

Attacking the person instead of their argument.

"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.

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.

"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.

"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.

"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.

"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."

"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.

"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.

"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.

"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 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.

"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.

"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

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.

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?"

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.

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:

[
  {
    "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.