4.1 KiB
First Principles
Aristotle's protai archai. Decompose a problem to assumptions you trust, then rebuild without inheriting anything by default. Often paired with "5 Whys" excavation of why each assumption is in place.
When to use
- A domain has accreted practice that may no longer be load-bearing
- You're in an unfamiliar domain and bootstrapping understanding
- You suspect the standard framing is wrong
- Trying to reduce cost or complexity (accumulated overhead is often the main cost)
- Teaching the domain (first-principles reconstruction surfaces what beginners actually need)
Don't use when
- You don't know the domain well enough — first principles applied by an outsider produces confidently wrong answers
- Transaction costs of replacement exceed the gains
- Problem is irreducible (aesthetic, social, gestalt — decomposition destroys what makes it coherent)
- You're trying to seem original — performance of first-principles thinking is slop
Procedure
- State the problem precisely.
- List assumptions in the conventional solution. What does the standard approach take for granted? List 5–10, including ones that "go without saying."
- Categorize each:
- Physical — law of nature; can't be relaxed.
- Informational — logical / mathematical / information-theoretic; can't be relaxed without contradiction.
- Conventional — could be different; matters for compatibility.
- Historical — was necessary at some point; may not be now.
- Pedagogical — simplification used for teaching; may not be how experts actually do it.
- For each non-physical / non-informational assumption: still load-bearing? Conventional and historical assumptions are where the gains live.
- Rebuild. Construct a candidate respecting only physical and informational constraints, plus your specific context.
- Apply Chesterton's fence. For each element you've removed, find the original reason it was added. If you can't find a reason, don't conclude there isn't one — assume you haven't looked hard enough.
- Decide whether to switch. Even when the rebuild is technically better, consider transaction cost, ecosystem compatibility, team familiarity.
Worked example
Problem: typical CRUD web app — login, dashboard, few CRUD entities. Conventional stack: React + Node/Express + PostgreSQL + REST API + managed platform. ~12,000 LOC, monthly hosting ~$100.
Assumptions:
- React: conventional, was historical (SPA promise ~2014), pedagogical (taught everywhere).
- Backend separate from frontend: conventional; informational if multi-client, otherwise historical.
- PostgreSQL: physical if concurrency/ACID required; otherwise conventional.
- REST API between frontend and backend: was informational (network boundary), now historical for single-client apps.
- Managed platform: conventional; was historical (datacenter complexity); pedagogical.
Context: 100 users, ~10 MB data, no real-time, single client (web), no HA constraint.
Rebuild:
- Server-rendered HTML + small JS islands. (No SPA. No build pipeline. No API layer.)
- SQLite single file. (No PG server. Backup = copy a file.)
- Single small VM. (No managed platform. Deploy =
rsync+systemctl restart.) - Single Go/Python/Ruby binary.
Result: ~1,500 LOC vs 12,000. ~$5/month vs $100. Tradeoffs: less impressive on resume, fewer contractors familiar with this style, no immediate path to 1M users.
Chesterton's fence: the conventional choices are load-bearing for some applications. The rebuild is correct only for this app's constraints. A different app — high concurrency, multiple clients, large data — needs different choices.
Anti-slop notes
- The biggest slop is the performance of first-principles thinking. "I'm going to think from first principles" followed by a slightly-rearranged conventional answer is slop. Output should look measurably different.
- Don't claim first principles when you're applying common sense.
- Avoid the engineer-hero archetype. Real first principles often reveals what the field already knows.
- Don't recommend removing structure you don't understand. Chesterton's fence applies hard.