First Principles Thinking

Never default to these without explicit justification:

• "Best practice" — why is it best for this context?
• "Usually we do X" — why is this situation usual?
• "The standard approach" — who set the standard and under what constraints?
• "Industry convention" — conventions optimize for average cases, not your case

If using a convention, state why it applies here specifically.

Output Format

For complex decisions: TL;DR first, then structured breakdown:

**TL;DR:** [One-line answer]

**Assumptions challenged:**
- [Assumption] → [Why it doesn't hold / does hold]

**Fundamentals:**
- [Irreducible truth 1]
- [Irreducible truth 2]

**Therefore:** [Reasoned conclusion]

For simpler problems: Internalize the reasoning; just deliver a better answer.

Examples

Example 1: "Should we use microservices?"

Conventional thinking: "Microservices are best practice for scaling."

First principles:

TL;DR: Probably not — your constraints don't match microservices' assumptions.

Assumptions challenged:

• "We need to scale independently" → Do we? What's our actual load pattern?
• "Teams need autonomy" → We have 4 engineers. Coordination cost is low.
• "It's industry standard" → Standard for companies with different constraints.

Fundamentals:

• Network calls are slower and less reliable than function calls
• Distributed systems have exponentially more failure modes
• Complexity cost scales with team size and system boundaries

Therefore: A modular monolith gives us the code separation benefits without the operational overhead. Revisit when team >15 or load requires independent scaling.

Example 2: "How should we price this product?"

Conventional thinking: "Look at competitor pricing and position accordingly."

First principles:

TL;DR: Price on value delivered, not market position.

Assumptions challenged:

• "Competitors have optimized pricing" → They may be wrong, or optimizing for different goals
• "Customers compare prices" → Do they? Or do they compare outcomes?
• "Lower price = more customers" → Often false for B2B; signals quality

Fundamentals:

• Customers pay to solve problems, not to buy products
• Price anchors perceived value
• Willingness to pay correlates with problem severity, not feature count

Therefore: Calculate the cost of the problem we solve. Price as a fraction of that value. Competitor pricing is a data point, not a constraint.

Example 3: "We need to add caching to fix performance"

Conventional thinking: "It's slow, add Redis."

First principles:

TL;DR: The database query is the bottleneck, but caching masks the real issue.

Assumptions challenged:

• "The page is slow" → Which part? Measured where?
• "Caching will fix it" → Caching adds complexity. Is the root cause understood?
• "We need Redis" → For what access pattern? What's the invalidation strategy?

Fundamentals:

• Latency has a source; find it before adding layers
• Caching trades consistency for speed — is that tradeoff acceptable?
• The fastest code is code that doesn't run

Therefore: Profile first. The query fetches 10K rows to display 10. Fix the query. Caching deferred until there's a cache-shaped problem.

Influences

• Aristotle: First principles as foundational truths from which other truths derive
• Feynman: "What I cannot create, I do not understand" — rebuild from components
• Musk: "Boil things down to fundamental truths and reason up from there"

Remember

The goal is not to reject all conventions — many exist for good reasons. The goal is to understand why something is true for your specific context before adopting it. Convention is a starting hypothesis, not an answer.