subtraction-firstlisted

# Subtraction-First ## Overview **Core principle:** Before adding anything, try to remove something. The best improvement is usually a deletion. Reach for subtraction *first* and adoption only when subtraction fails. Humans — and models — have a documented bias toward solving problems by adding rather than removing, even when removing is simpler and better. The bias is invisible from the inside, which is exactly why it needs a rule: **make deletion the default hypothesis, not the last resort.** ## The Question to Ask First Not "what should I add to make this better?" but: > **What could I remove and have this be *just as good or better*?** Run down the list before you write a single new line: - **Dead code** — unreachable branches, unused functions, commented-out graveyards. - **Unused parameters and options** — arguments nobody passes, flags nobody flips. - **Speculative generality** — abstraction built for a second caller that never arrived. - **Forwarding layers** — a wrapper whose whole job is to call one other thing. - **Defensive checks that can't fire** — guards against states the type system or callers already forbid. - **Comments that restate the code** — delete the comment or fix the name it's apologizing for. - **Whole features** — the option nobody uses is a cost everyone pays. Removing it is a feature. ## The Discipline ``` NO ADDITION UNTIL SUBTRACTION HAS BEEN TRIED AND FAILED ``` When you catch yourself about to add: 1. **State what you're about to