There’s a moment in every engineer’s career — maybe in a sprint planning, maybe in a code review thread, maybe in a 1:1 where your manager is explaining why this “quick fix” should take an afternoon — where you know the argument being made is wrong, but you can’t articulate why it’s wrong fast enough.
The conversation moves on. You agree to something unreasonable. You spend the next two hours annoyed at yourself for not pushing back.
If you’re ESL, multiply that by three. The argument is happening in your second language, your brain is doing real-time translation AND logical analysis simultaneously, and by the time you’ve composed the perfect rebuttal the meeting is over and everyone’s already in the next Zoom.
This post is the cheat sheet I wish I’d had three years ago. Six logical fallacies that show up constantly in engineering work, realistic examples of each, and exact response templates you can pre-load before your next meeting.
Why engineers specifically need this
Engineers are trained to respect expertise. That’s the whole job — you learn from people who know more than you, you trust documentation, you defer to the person who’s been in the codebase longest. This is usually a good instinct.
It’s also the exact instinct that makes you vulnerable to bad arguments from people with authority. When your tech lead says “this should be a two-hour task,” your engineer brain wants to trust that assessment because they have more context than you. But having context and being right are two different things.
The other problem: engineers optimize for being correct, not for being persuasive. You can have the right position and still lose the argument because the other person framed it better. Knowing fallacy patterns flips this — you stop engaging with the framing and start engaging with the logic.
The six fallacies
1. Strawman: “So you’re saying you don’t want to contribute?”
What it is: Someone restates your position as something more extreme or easier to attack. You said “this estimate is too aggressive.” They heard “I refuse to do the work.”
Workplace examples:
- You raise a concern about test coverage in a PR. Reviewer responds: “So you think we should never ship anything until we have 100% coverage?”
- You suggest the deadline needs more buffer. PM responds: “So you’re saying the feature isn’t important?”
- You flag that a proposed architecture has scaling issues. Lead responds: “You just don’t want to build anything new.”
None of these are what you said. They’re exaggerated versions designed to make your position sound unreasonable.
What to say:
“That’s not what I’m saying. My point is [restate your actual position clearly].”
“Let me clarify — I’m not against shipping. I’m saying these three modules have zero test coverage and that’s a risk we should discuss.”
“I think we’re talking past each other. Let me restate what I mean.”
Why it works: The strawman only survives if you accept the reframing. The moment you reject it and restate your actual position, the attack has nothing to attach to.
2. Ad Hominem: “You’re just not experienced enough to understand”
What it is: Instead of addressing your argument, they address you. Your seniority, your track record, your motivation.
Workplace examples:
- “You’ve only been on the team for six months — you don’t have enough context for that opinion.”
- “You’re just being lazy if you don’t want to take this on.”
- “Easy for you to say, you don’t have to deal with the on-call rotation.”
Notice the pattern: the argument disappears entirely. It’s no longer about whether the task estimate is realistic or the architecture is sound. It’s about whether you have the right to say it.
What to say:
“Whether I’m junior or not doesn’t change the fact that this API has no error handling. Can we focus on the technical issue?”
“My experience level isn’t really the point here. The question is whether [restate the actual question].”
“I hear you, but my motivation doesn’t change the complexity of the task. Let’s look at the specifics.”
Why it works: You’re not defending yourself (that’s the trap). You’re redirecting to the substance. Let them attack you all they want — the technical argument is still standing there, unaddressed.
3. False Dichotomy: “Either we ship Friday or the project is dead”
What it is: Presenting only two options when the actual space of solutions is much wider. This is the favorite tool of anyone trying to create urgency.
Workplace examples:
- “Either you finish this by end of day or we’ll have to pull someone else onto it.”
- “We either rewrite the whole service or we live with the tech debt forever.”
- “You can either take the on-call shift or we cancel the release.”
The hidden assumption is always that there’s no middle ground. There almost always is.
What to say:
“I don’t think those are the only two options. What about [third option]?”
“Can we take a step back? I’d like to explore alternatives before we commit to either of those.”
“There’s a middle ground here — we could [specific alternative] which gets us most of the way without [the cost of the extreme option].”
Why it works: False dichotomies collapse the moment you introduce a third option. You don’t even have to argue against either choice — you just expand the solution space.
4. Appeal to Authority: “The VP said it should be straightforward”
What it is: Using someone’s position or title to settle a technical question instead of actual evidence. This is the one engineers fall for the hardest, because respecting expertise is baked into the culture.
Workplace examples:
- “The architect says this design is fine.” (But the architect hasn’t looked at the data access patterns.)
- “The manager estimated two hours for this.” (But the manager hasn’t opened the codebase.)
- “The senior engineer on the other team said we should use Kafka.” (But they said that in a hallway conversation without seeing our requirements.)
The authority might be right! That’s what makes this tricky. The fallacy isn’t “authority figures are always wrong.” The fallacy is “authority figures being confident is not a substitute for evidence.”
What to say:
“I respect [person]’s judgment, but their estimate doesn’t account for the complexity I’ve found. Let me walk through the specifics.”
“That’s good context, but I’d like to evaluate it against our actual requirements before committing.”
“I’m sure they know their stuff, but have they seen [specific technical detail that changes the picture]?”
Why it works: You’re not attacking the authority (that would be your ad hominem). You’re separating the person’s status from the technical question. “They may be right, but let’s verify” is almost impossible to argue against without sounding unreasonable.
5. The “Quick Task” Bluff: “This should only take a couple hours”
What it is: Someone who hasn’t done the work claims it’s simple. This is technically an inconsistency — they’re asserting knowledge about effort without evidence — but it shows up so often in engineering that it deserves its own section.
Workplace examples:
- PM in sprint planning: “It’s just a config change, right?” (It’s a config change that touches three services, requires a migration, and has no rollback story.)
- Tech lead in standup: “That bug should be a quick fix.” (They haven’t read the stack trace.)
- Stakeholder in a review: “Can’t you just add a button for that?” (The button requires a new API endpoint, auth changes, and a database schema update.)
What to say:
“It might be — but I’d like to spike it first before committing to that estimate. I’ve seen a few things that could make it more complex.”
“If it’s that straightforward, would you mind walking me through your approach? That’ll help me make sure I’m not overthinking it.”
“I’d be happy to take it on, but I want to set expectations — here’s what’s actually involved: [list the real steps].”
Why it works: The second one is my favorite. It’s polite. It’s collaborative. And it puts the burden of proof back where it belongs — on the person making the claim. Nine times out of ten they’ll say “well, I haven’t looked at it in detail” and suddenly the estimate is negotiable again.
6. Emotional Appeal: “Everyone else is fine with the timeline”
What it is: Using social pressure instead of logic. “Everyone agrees” is not an argument — it’s a headcount. And even then, it’s usually not true.
Workplace examples:
- “The rest of the team is on board with this approach.”
- “Nobody else had concerns about the deadline.”
- “I’m surprised you’re pushing back — this was already decided.”
There’s a specific variant of this that targets ESL engineers: the implication that your pushback is a cultural misunderstanding rather than a valid technical concern. “Maybe you’re not familiar with how we do things here.” That’s ad hominem in a trench coat.
What to say:
“I’d prefer to discuss the technical merits rather than what everyone else thinks. My concern is specifically [concrete issue].”
“That’s possible — but I’d still like to raise [issue] because I think it’s worth considering regardless.”
“I respect the team’s position, but I’m seeing [specific risk] that I want to make sure we’ve discussed.”
Why it works: Emotional appeals rely on you caring more about consensus than correctness. By pivoting to a specific, concrete concern, you’re showing that your pushback is substantive, not social.
The meta-skill: staying calm under pressure
Spotting the fallacy is the easy part. You can learn that from a blog post. (This blog post, specifically. You’re welcome.)
The hard part is staying composed when someone uses one on you in real time. Especially when it’s someone senior, especially when other people are watching, and especially when your brain is simultaneously processing the argument in a language it didn’t grow up speaking.
Three things that help:
The two-second pause. Before you respond to anything that triggers a defensive reaction, breathe. Two seconds. That’s it. Not to calm down — to switch from reactive mode to analytical mode. “What fallacy is this?” is a better first thought than “how dare they.”
Pre-loaded phrases. This is the same technique as meeting prep for ESL speakers. You don’t need to improvise a perfect response. You need three or four phrases so internalized that they come out automatically:
- “Can you clarify what you mean by that?”
- “What specific evidence supports that?”
- “I think we’re conflating two different things here.”
- “Let’s look at the specifics.”
These buy you time and redirect the conversation to substance. They work for literally every fallacy in this post.
Name the dynamic, not the fallacy. Never say “that’s a strawman argument” in a meeting. You’ll sound like a debate club kid, and the other person will get defensive. Instead, describe what happened without the jargon: “I think we’re talking about two different things” (strawman). “Let’s focus on the technical question” (ad hominem). “Are there other options we haven’t considered?” (false dichotomy). Same effect, zero condescension.
Disagreeing without burning bridges
Here’s the thing nobody tells you about pushing back at work: the goal isn’t to win the argument. The goal is to reach a better outcome while preserving the relationship.
Every response template in this post is designed to do both. Notice what they don’t do:
- They don’t attack the other person
- They don’t claim to be right — they ask to examine the evidence
- They don’t escalate — they redirect
“Let me walk through the specifics” is doing a lot of work in that sentence. It’s saying “I disagree” without saying “you’re wrong.” It’s offering information instead of opposition. Most people will accept an invitation to look at evidence, even if they wouldn’t accept being told they’re wrong.
The “yes, but” technique lives here too:
Them: “This should take no time at all.”
You: “Yeah, it might be simpler than I think — but based on what I’ve seen so far, there’s [specific complexity]. Let me walk you through it.”
You’re not fighting. You’re collaborating. You just happen to be collaborating toward a more accurate understanding of the problem. Which is, you know, the entire job.
The cheat sheet
Print this. Tape it next to your monitor. Open it on your phone before sprint planning.
| Fallacy | What They Say | What’s Actually Happening | What You Say Back |
|---|---|---|---|
| Strawman | “So you’re saying we should never ship?” | Restating your position as something extreme | “That’s not what I’m saying. My point is [actual position].” |
| Ad Hominem | “You’re too junior to understand this.” | Attacking you instead of your argument | “My experience isn’t the point. The question is [technical issue].” |
| False Dichotomy | “Either we ship Friday or we cancel.” | Hiding the middle-ground options | “Those aren’t the only options. What about [alternative]?” |
| Appeal to Authority | “The VP said it’s straightforward.” | Using title instead of evidence | “I respect that — but let me walk through what I’ve actually found.” |
| Quick Task Bluff | “It’s just a config change.” | Claiming effort without doing the work | “Would you walk me through your approach? I want to make sure I’m not missing something.” |
| Emotional Appeal | “Everyone else is fine with this.” | Using social pressure instead of logic | “I’d like to discuss the technical merits. My concern is [specific issue].” |
Universal fallback phrases (work for everything):
- “Can you clarify what you mean by that?”
- “What specific evidence supports that?”
- “Let’s look at the specifics.”
- “I think we’re conflating two different things here.”
These notes started as a personal study file in November 2024 — the kind of thing you make when you’re tired of losing arguments you should have won. If any of this resonated, the best thing you can do is practice saying the responses out loud. Not reading them. Saying them. The bottleneck is never knowing the right answer — it’s producing it fast enough to use it.