First Principles Thinking: Why Most Technical Problems Aren't Technical at All

What Are First Principles?

First principles thinking means discarding all experience, conventions, and "obvious" assumptions, then returning to the most basic facts and logic to re-derive a solution. Imagine an alien seeing humans use wheels: it wouldn't assume "wheels must be round" but would ask "why transport?" and "what shape minimizes effort?" Physics then shows a circle is optimal.

In technology we're flooded with "best practices," "industry standards," and "big-company solutions." When those fail, we must return to the problem's essence.

Why We Need First Principles

Many "technical difficulties" aren't technical at all. Example: a slow system prompts code optimization, caching, scaling — but asking "what does the user really need?" may reveal an unused feature that can simply be removed. Another: frequent production incidents lead to more testing and monitoring, yet 80% stem from one legacy module; rewriting it solves the root cause. Over-engineering happens because we think inside existing frameworks and forget the problem may be simple.

Three Thinking Traps

1. Experience Trap

"Last time we fixed it this way." Experience is wealth but can become a shackle. Technology, business, and users change; yesterday's fix may not fit today. Case: an e-commerce order system timed out. Engineers assumed database slowness, spent weeks optimizing SQL, adding indexes, sharding — errors decreased but persisted. Root-cause analysis from basics — "how long does order creation take? where is time spent?" — revealed an external verification service responding extremely slowly.

2. Authority-Worship Trap

"Google does it, so it's right." Big-company solutions are built for their scale, stack, and team. A startup with <10 people and ~10k DAU copied microservices architecture; ops costs exploded, dev velocity crashed, they eventually merged services back.

3. Tool-Dependency Trap

"Using the latest framework will fix it." Tools are just tools; the key is the problem they solve. A project migrated jQuery → Angular → React, each time claiming "better dev efficiency" and "better UX." Yet the user's core complaint — "page loads too slow" — was never addressed. First-principles view: users want fast load. Why slow? Images too large, too many requests. Fix: compress images, combine requests — largely independent of framework choice.

First Principles in Practice

Case 1: Mysterious Database Connection Pool Exhaustion

Errors: pool exhausted. Conventional fix: increase pool, optimize slow queries, add DB instances. First-principles steps:

Step 1: Establish facts — Pool size: 100. Normal active connections: 20–30. At failure: 100. Each request: 2–3 DB ops.

Step 2: Decompose — Why does usage jump from 30 to 100?

Step 3: Trace essence — Monitoring showed a daily 3 PM spike. A cron job ran then, processing large batches concurrently. Its transaction wasn't closed properly, leaking connections.

Step 4: Simple fix — Repair transaction management. Pool size 50 became sufficient. Blindly expanding the pool would have masked the bug and added DB load.

Case 2: Never-Ending Homepage Optimization

Team had done: CDN for static assets ✓, lazy-load images ✓, API merging ✓, server caching ✓, DB index tuning ✓. Users still said "slow." First-principles question: what does the user mean by "slow"? User interviews revealed "slow" meant "hard to find the product I want." Homepage was cluttered; users scrolled endlessly. Real fix: simplify homepage, improve search/category, add personalized recommendations. Technical perfection lost to a small product-design change.

Case 3: Microservices or Monolith?

Common arguments for microservices: everyone uses them, they're advanced, enable team scaling, easy to scale. First-principles asks:

Core problem : build a system that meets business needs.

Constraints : team size (5 vs 50), business complexity (simple CRUD vs complex logic), scale (millions DAU vs thousands), velocity vs stability.

From-zero architecture : 5-person team, simple logic → monolith wins: simple deploy, easy debug, no network overhead, simple transactions. Split only when monolith becomes a genuine bottleneck; then you'll know exactly which modules need independence. Microservices aren't the goal; solving business problems is.

Cultivating First-Principles Thinking

Habitually ask "why" — Why this problem? Why not before? Why now? Why these users? Each "why" nears the essence.

Distinguish symptom from cause — "System is laggy" is a symptom; causes: network latency, high CPU, DB deadlock, slow frontend render, even user's old hardware (seen in industrial IoT). Don't be fooled by symptoms.

Build measurement & verification — Performance: measure first, locate bottleneck. Stability: collect data, analyze failure patterns. UX: user research, understand real needs. Data tells truth, not intuition.

Practice "from-zero" thinking — Regularly ask: "If I designed this system/solved this problem from scratch, how would I do it?" Breaks existing-framework limits.

Stay humble & curious — Tech moves fast; yesterday's truth may be obsolete. Admitting "I don't know" forces return to facts, not faulty assumptions.

When to Use First Principles

Suitable : conventional methods exhausted, novel problems with no precedent, need 10× breakthrough not 10% tweak, extreme resource constraints, major team disagreements needing fact-based consensus.

Unsuitable : routine problems with mature solutions (e.g., login feature), urgent firefighting (apply known fix first, optimize later), cost-sensitive contexts where from-zero cost exceeds off-the-shelf.

First Principles & Engineering Practice

First principles doesn't reject best practices or design patterns. Correct approach:

Understand the principle — Know why a best practice works.

Judge applicability — Does the principle still hold in current context?

Apply flexibly — Adapt to reality, don't cargo-cult.

Example: "DB indexes improve query performance" is a best practice. Principle: index trades space for time, extra storage accelerates lookup. When might it not apply? Tiny table (full scan faster), heavy writes (index maintenance cost), complex query patterns (single index can't cover). Understanding the principle enables correct judgment.

A Thinking Framework

Define the problem — Symptom? Scope? When started?

Gather facts — Measurable data? Verified facts? Assumptions?

Decompose structure — System components? Interactions? Where could the issue lie?

Trace principles — Fundamental principle of that component? Still valid here? Hidden assumptions?

Reconstruct solution — Simplest fix based on principles? Risks & costs? How to verify?

Iterate & optimize — Result? Room for improvement? New insights learned?

Closing Thoughts

"No silver bullet" — no single technology or method solves everything. First principles isn't a silver bullet either, but a powerful thinking tool. In an era of rapid tech churn and endless frameworks, it keeps you clear-headed, finds the essence, and drives right decisions. Next time you face a thorny technical problem, pause and ask: "If I were the first person to encounter this, with no prior experience to borrow, how would I think?" The answer may surprise you. True experts don't just master many technologies; they master the principles behind them. When you can reason from first principles, you truly understand technology's nature. The path demands constant questioning, thinking, verifying — but it's the necessary road to becoming a technical expert. Be not merely a skilled technical worker, but a thinking problem solver.

CDN Error Logs (from article)

> Connection broken: IncompleteRead(49292 bytes read, 2611057 more expected)', 
> IncompleteRead(49292 bytes read, 2611057 more expected