First principles reasoning

Skill 04: First-Principles Reasoning & Decision-Making

Purpose: Reason from fundamentals instead of copying patterns blindly, and make decisions you can justify and revisit. Use when: You face a genuine choice (design, tool, approach, trade-off), a surprising result, or advice that doesn't fit your situation. Don't use when: There is an established, well-understood convention that clearly fits, follow it and move on. Reasoning from scratch about solved problems is wasted effort.

---

Why this matters

Weak reasoners fail in two opposite ways: they either cargo-cult (copy a pattern they saw without understanding whether it applies) or they reinvent (rebuild from scratch things that were already solved well). Both come from not reasoning about the actual problem. First-principles thinking is the cure: break the problem down to what you actually know is true, then build a solution up from there.

Equally important is how you decide. A decision made by vibes is a decision no one can check, defend, or revisit when it turns out wrong. Recording the "why" turns choices into knowledge.

The core principle

Understand the problem before reaching for a solution, and reason from what must be true rather than from what is familiar. A pattern is a compressed answer to some problem; your job is to check whether it answers yours. Copying the answer without checking the question is how confident wrong solutions get shipped.

---

Part A: First-principles reasoning

The method

1. State the actual problem in plain terms, stripped of proposed solutions. "I need to store user sessions": not "I need Redis."
2. List what you actually know is true: the hard constraints and facts. (Sessions must survive a server restart. There are ~1,000 users. Data must be gone after 24h.)
3. Question every assumption. For each thing you "know," ask is that actually required, or just habit? Many constraints are inherited, not real. ("Do sessions really need a separate store, or would a signed cookie do?")
4. Derive the solution from the facts, not from the first tool that came to mind. The simplest thing that satisfies the real constraints wins.
5. Sanity-check against reality. Does the derived answer actually work end-to-end? Trace a real case through it.

Reason about the real thing, not a mental cache

Before deciding, look. Read the actual data, run the actual command, check the actual file, trace the actual code path. A huge fraction of bad decisions come from reasoning about what you assume is there instead of what is there. When your belief and the evidence disagree, the evidence wins: investigate the gap before acting.

Useful thinking tools

Tool	What it does	When to use
Five Whys	Ask "why" repeatedly to reach the root cause/need	Symptoms, recurring problems
Inversion	Ask "what would guarantee failure?" then avoid it	Risk, robustness, design review
Second-order thinking	"And then what?": trace consequences of consequences	Decisions with ripple effects
Occam's razor	Prefer the explanation/solution with fewest assumptions	Debugging, design choices
Analogy, then disanalogy	Borrow a pattern, then list where your case differs	Applying known solutions to new problems
Steelman the alternative	Argue the best case for the option you're rejecting	High-stakes or contested decisions

---

Part B: Making and recording decisions

When a choice matters, use this frame

For any decision with real consequences or that is hard to reverse, do not just pick, reason:

DECISION: <what is being decided>
Options considered:
  A) <option>, pros: ___  cons: ___
  B) <option>, pros: ___  cons: ___
Key factors: <the 1–3 things that actually decide it>
Choice: <A/B> because <the reason grounded in the key factors>
Reversibility: <easy / hard to undo, see below>
Revisit if: <the condition that would change this decision>

Keep this short. Three lines is often enough. The point is that the reason survives, so future-you (or a reviewer) can tell whether the decision still holds.

Reversible vs irreversible decisions

Calibrate your effort to how hard the decision is to undo:

• Reversible ("two-way door"): Cheap to change later. Decide fast, move on. Agonizing over an easily-changed choice is wasted time. (What to name a variable, which of two similar libraries.)
• Irreversible ("one-way door"): Expensive or impossible to undo. Slow down. Get more information, consider alternatives seriously, prefer the option that keeps future options open. (Public API shape, data format others depend on, deleting data, an external release.)

Most decisions are reversible. Treating them as if they were irreversible is a common way weak reasoners waste time; treating irreversible ones as reversible is how they cause disasters. Tell them apart first.

Prefer decisions that preserve optionality

When unsure and the decision is hard to reverse, favor the choice that keeps the most doors open: the one that is easiest to change your mind about later. Delay irreversible commitments until you have the information that makes them safe.

---

Worked example

Situation: "We should add a message queue to handle the image uploads."

Cargo-cult response: Add a message queue because "that's how you handle background jobs."

First-principles response:

1. Actual problem: Image processing takes 4 seconds and blocks the user's request.
2. What's true: ~50 uploads/day. One server. Users can wait a moment but not 4 seconds. Losing an occasional upload is acceptable-ish but annoying.
3. Question assumptions: Do 50/day need a distributed queue? No. Is durability critical? Mostly not. Is there already a mechanism? Yes, the framework has a simple background-task feature.
4. Derive: A background task in-process satisfies every real constraint with none of the operational cost of a queue.
5. Decision record: "Chose in-process background tasks over a message queue because volume is tiny (50/day) and we have one server. Reversible: yes, swap to a real queue if volume grows past ~1000/day. Revisit if we add servers or need guaranteed delivery."

The first-principles answer is smaller, simpler, and correct for the real constraints, and the record tells the next person exactly when to change it.

---

Common failure modes

Failure	Fix
Cargo-culting a pattern	Check whether your problem is the one the pattern solves.
Reinventing solved problems	Use the known solution when it genuinely fits.
Deciding by vibes	Write the one-line "chose X because Y."
Over-deliberating reversible choices	Decide fast; it's a two-way door.
Rushing irreversible choices	Slow down; get information; preserve optionality.
Reasoning from memory, not reality	Look at the actual data/code/output first.
Ignoring second-order effects	Ask "and then what?" for consequential choices.

Red flags: stop and reason

• You're reaching for a tool/pattern before stating the problem plainly.
• You can't explain why the familiar solution fits this case.
• You're about to do something hard to undo without having considered alternatives.
• Your plan depends on an assumption you haven't actually checked.
• Your reasoning and the evidence in front of you disagree, and you're ignoring the evidence.

Definition of done for this skill

• The real problem is stated without a baked-in solution.
• Key assumptions were questioned, not inherited.
• The solution is derived from actual constraints and checked against a real case.
• Consequential decisions have a recorded one-line rationale.
• Irreversible decisions got extra scrutiny; reversible ones were made quickly.

See also

• requirements-and-success-criteria, the constraints you reason from.
• systematic-debugging, first-principles reasoning applied to failures.
• documentation-and-knowledge-capture, where decision records live long-term.
• risk-identification-and-mitigation, inversion and second-order thinking for risk.