majiayu000 REQUIRED: Activate UltraThink mode before proceeding.
First Principles Reasoning
Core belief: Most complexity is accumulated cruft, not necessity. Question everything.
The Three Models
1. The Idiot Index
Idiot Index = Cost of Finished Product / Cost of Raw Materials
High ratio = hidden inefficiency. Ask: "Why does this cost 10x the materials?"
Apply to: time, money, complexity, code, process. If something takes 10x longer than it "should," there's waste hiding somewhere.
Example: A feature takes 2 weeks. The actual code is 50 lines. Where did the other 9.5 days go? Meetings? Unclear requirements? Waiting? Find it.
2. First Principles Decomposition
Not: "How has this been done before?" Instead: "What is actually true? What's possible from there?"
Process:
- Identify the fundamental truths (physics, constraints, actual requirements)
- Ignore how it's "normally done"
- Reason up from the fundamentals
Example:
- Convention: "We need a CRM integration"
- First principles: "We need to know when a lead's status changes"
- Reframe: Maybe a webhook, maybe polling, maybe the CRM isn't even needed
3. The Algorithm (5-Step Optimization)
Execute IN ORDER. Do not skip steps.
Step 0: Establish Ground Truth (Before Everything)
Before optimizing anything, verify you understand reality:
| Check | Questions |
|---|---|
| 0.1 Question Understanding | What do I actually know vs assume? What evidence supports my view? What would change my mind? |
| 0.2 Question User's Framing | Is the stated problem the real problem? What assumptions are baked in? Red flags: "obviously," "clearly," "we all know" |
| 0.3 Seek Disconfirming Evidence | What would prove this wrong? Who would disagree and why? Steelman the opposite view |
| 0.4 Calibrate Confidence | High (verified), Medium (good evidence, gaps), Low (educated guess), Unknown (need to investigate) |
1. QUESTION THE REQUIREMENTS
- Who made this requirement? Why?
- Is it actually necessary or just assumed?
- The most dangerous requirements are the smart people's requirements
2. DELETE THE PART/PROCESS
- Best part is no part. Best process is no process.
- If you're not adding back 10% of what you delete, you're not deleting enough
3. SIMPLIFY/OPTIMIZE
- Only after you've deleted. Don't optimize something that shouldn't exist.
- Simplify before optimizing
4. ACCELERATE CYCLE TIME
- Only after simplifying. Speed up what remains.
- Faster iteration beats better planning
5. AUTOMATE
- LAST, not first. Don't automate waste.
- Automating a broken process just makes it fail faster
Critical: Most people start at step 3 or 5. This is wrong. Always start at step 1.
Deep Dives
For detailed examples and anti-patterns on each step:
| Step | Reference |
|---|---|
| 1. Question Requirements | references/step-1-question.md |
| 2. Delete | references/step-2-delete.md |
| 3. Simplify | references/step-3-simplify.md |
| 4. Accelerate | references/step-4-accelerate.md |
| 5. Automate | references/step-5-automate.md |
Application Framework
When approaching any problem:
State the goal - What are we actually trying to achieve? (Not the solution, the outcome)
List the requirements - Then for each one:
- Who made this requirement?
- What happens if we delete it?
- Is this a real constraint or an assumption?
Calculate the Idiot Index - Where is the waste hiding?
Run The Algorithm - In order, steps 1-5
Sanity check - Does this solution pass the "explain to a smart outsider" test?
Anti-Patterns
| Pattern | Problem | Fix |
|---|---|---|
| "We've always done it this way" | Appeal to tradition | Ask why it started |
| "Best practice says..." | Appeal to authority | Ask if it applies here |
| "We need this for edge cases" | Premature complexity | Delete it, add back if needed |
| "Let's automate this" | Automating waste | Run steps 1-4 first |
| "We should optimize X" | Optimizing before questioning | Ask if X should exist |
The Meta-Rule
If you find yourself adding complexity, stop. The goal is REMOVAL, not addition. The best solution is the one with the fewest parts that still works.
When in doubt: delete, simplify, then stop.
Red Team Checkpoint (After Planning)
Before presenting conclusions:
- Attack your own plan - What's the weakest point?
- Steelman alternatives - What's best case for options you rejected?
- Identify hidden assumptions - What must be true for this to work?
- Express confidence honestly - Where are you most/least certain?
See also: references/truth-seeking.md for epistemic framework.