Misconception Elimination Project

Overview

This collection targets forty-four widely repeated claims that survive interviews, code reviews, and design documents because each one contains a kernel of truth. The format is deliberately adversarial but fair: each page states the claim in its strongest common form, renders a verdict (false, incomplete, or context-dependent), explains why the claim is believable, gives the correct formulation, and then breaks the claim with a concrete scenario whose numbers actually work out.

The goal is not to mock the claims. Most of them are true in a specific, well-defined regime, and engineers who repeat them are usually quoting a real experience. The failure is in the missing quantifiers: “always”, “guarantees”, “completely”, “average case” — words that quietly delete the preconditions under which the statement holds. Removing those deletions is what this project does. Read the inventory below, pick the claim you have caught yourself repeating, and audit it against the counterexample.

A Taxonomy of Misconception Types

Not all wrong claims are wrong in the same way, and the verdict category changes what you should do about it.

The distinction matters in interviews. Saying “that is false” when the honest answer is “that is incomplete — here are the three missing preconditions” signals precision, and interviewers probe exactly this. A false claim has a counterexample that inverts the outcome; an incomplete claim usually has a counterexample that only fails to deliver the promised benefit. When you are unsure which verdict applies, try to construct a scenario where the claim’s outcome is worse than the baseline. If you can, the claim is false; if the outcome merely fails to improve, the claim is incomplete; if the outcome depends on workload shape, it is context-dependent.

Why These Claims Persist

Every claim in this collection survives because it encodes a kernel of truth so reliable that most encounters with the claim never expose the boundary.

• The common regime dominates experience. Hash lookups are O(1) almost every time you measure them; most tables are indexed usefully; most caches improve latency. A rule that holds in 99% of observed cases is indistinguishable from an unconditional rule unless you go looking for the 1%.
• Teaching simplifications harden into axioms. Courses say “hash tables are constant time” to defer the fine print about expected versus worst-case cost. Students remember the slogan and lose the quantifier “expected, under simple uniform hashing”.
• Guarantees get smuggled across abstraction layers. TCP really does guarantee reliable, ordered byte delivery — to the kernel socket buffer, not to the receiving application. The guarantee is real at one layer and fictional one layer up.
• Survivorship bias. The projects where “more threads fixed it” ship; the projects where more threads caused a contention collapse get rewritten before anyone writes the postmortem.
• The fine print is documented but unread. Java’s HashMap javadoc and PostgreSQL’s planner documentation both state their limits plainly. The misconception persists because nobody reads the documentation of things they believe they already understand.

How to Audit Your Own Beliefs

Use this checklist on any performance or correctness claim you are about to repeat in a design review or an interview.

1. State the claim with quantifiers. Rewrite it as “for all X, doing Y yields Z”. Vague claims cannot be audited.
2. Name the regime where it holds. Every surviving claim has one. If you cannot name it, you do not understand the claim yet.
3. Hunt for one valid counterexample. Not a plausible story — a concrete scenario with numbers you have actually computed. If your counterexample does not survive arithmetic, the claim survives.
4. Identify the missing precondition. Classify the verdict: false, incomplete, or context-dependent, using the table above.
5. Check what the primary source actually promises. Read the RFC, the javadoc, the database planner documentation, or the language specification. Most misconceptions are directly contradicted by the official documentation of the very technology involved.
6. Separate transport from delivery, average from worst case, isolation from autonomy. Many claims fail because two adjacent concepts were merged into one word.

Repeat the audit periodically. Beliefs decay as tools change: a claim that was true for Python 2 dictionaries (pre-hash-randomization) becomes false for an adversarial workload on Python 3 unless the sentence names the version and the protections.

Inventory

Coverage Ledger

The collection stands at forty-four claims after six expansion rounds. The Round 15 candidates tracked in the hub backlog (“HTTPS means safe”, “GC eliminates leaks”, “container == VM”) have since been incorporated as full audits in Round 16, Round 17 added seven more whose thread runs through runtime execution models (async/await, the GIL, immutability), transport and cipher guarantees (UDP, encryption, checksums), and measurement discipline (latency averages), and Round 18 added seven whose thread runs through evidence and verification (green suites, coverage, dashboards, backups), measured versus experienced performance (throughput versus latency), and the boundary between encoding and protection (silent corruption, JWT structure). Round 19 added five whose thread runs through the boundary between a control and the property it is sold as — encryption versus access control, rollback versus reversibility, statelessness versus scale, a load test versus safety, and the network versus reliability. Round 20 added seven whose thread runs through the gap between a mechanism and the guarantee borrowed from it — transaction boundaries versus service atomicity, encoding versus encryption, identifier format versus entropy, ORM parameterization versus injection coverage, a name versus the address it resolves to, broker scope order versus end-to-end order, and regular expressions versus nested structure. The remaining backlog candidate (advisory locks prevent all race conditions) stays tracked at the hub, to keep every entry fully argued rather than enumerated.

Cross-References

• Follow-up Tree: Hash Tables — interview escalation chains that start from the same O(1) belief and go deeper
• Assumptions Hunt: Complexity Claims — the hidden assumptions behind big-O statements in interviews
• Why-Not Handbook: Binary Search vs Hashing — the decision that the O(1) slogan hides
• Failure Casebook: Therac-25 — a race condition that no amount of average-case reasoning would have excused
• DSA: Hashing — the mechanics this collection assumes
• OS Overview — where process isolation actually comes from
• Distributed Systems Overview — the CAP material in its native habitat