4/20/2026 · 1 min read
Epistemology for developers: how to doubt your code well
Popper, Quine and unit testing. A practical guide to doubting your code without going paranoid.
- #philosophy
- #testing
- #architecture
The problem of induction in tests
“All swans are white — until a black one shows up.”
Karl Popper made it plain: theories cannot be verified, only falsified. Every passing test does not prove your code works — only that you haven’t yet found the case that breaks it.
Falsificationism and TDD
TDD formalizes falsificationism: first you write the counterexample (a red test), and only then the code that survives the attack. You’re not proving it works — you’re proving this specific case doesn’t break.
Your code as hypothesis
Every function is a hypothesis about how the system should behave. Tests are attempts to refute it. Code is provisional, like any scientific hypothesis: valid until the black swan shows up.
When to stop doubting
Quine reminds us not all beliefs get revised at once. There’s a core (domain invariants) we protect and a periphery (implementation details) we rewrite when new evidence appears.
Write tests for the core. On the periphery, doubt less and ship.