Start With First Principles

Engineering excellence through rigorous thinking, systematic processes, and relentless focus on what actually matters.

The Foundation of Good Engineering

Why this guide exists: Most engineering failures don't come from lack of technical skill—they come from skipping fundamentals, accepting unexamined assumptions, and confusing activity with progress. This is your north star: a systematic approach to building things that work, on time, and within constraints.

Engineering is problem-solving under constraints. The best engineers don't memorize solutions—they understand principles deeply enough to derive solutions from scratch. This guide teaches you to think like that.

Whether you're a student learning the ropes or a veteran engineer who's seen projects fail from preventable mistakes, these principles apply. The technology changes, but the fundamentals don't.

What is First-Principles Thinking?

First-principles thinking means breaking down complex problems to their fundamental truths and rebuilding solutions from the ground up—rather than relying on analogies, trends, or "how it's always been done."

The problem with analogies: When you copy solutions from other contexts, you import their constraints and assumptions. "It's like Uber, but for X" or "We'll use Docker because everyone else does" leads to force-fitting inappropriate solutions. Start with physics, economics, and actual requirements instead.

1. Question Assumptions

Challenge every "we must use X" or "everyone does Y." Ask why at least three times until you hit fundamental constraints.

  • Why does this requirement exist?
  • What problem does this actually solve?
  • Is this a real constraint or inherited dogma?
  • What would happen if we didn't do it this way?

2. Break Down to Fundamentals

Strip away conventions to reveal core constraints: physics, economics, actual requirements. Ignore trends and focus on truth.

  • What are the immutable laws (physics, regulations)?
  • What are the actual constraints (power, mass, cost)?
  • What problem are we really solving?
  • What's the minimum viable solution?

3. Rebuild From Truth

Construct solutions based on what must be true, not what's convenient, familiar, or currently popular in the industry.

  • Design for constraints, not trends
  • Choose tools that fit the problem
  • Accept complexity only when necessary
  • Simple solutions are usually better
Example: Docker for Space Missions
Popular approach: "Let's use Docker/Kubernetes—it's modern and everyone uses it."

First-principles analysis: What's actually needed?
→ Isolated execution environments
→ Deterministic timing for real-time control
→ Minimal resource overhead (power/memory are precious)
→ Radiation tolerance and reliability

Conclusion: Docker adds Linux overhead, non-deterministic scheduling, and unnecessary complexity. A partitioned RTOS (VxWorks-653, PikeOS) provides isolation and determinism with far less overhead. Don't force-fit trendy tech—solve the actual problem.

The Engineering Mindset

Think Outside the Box, But Use Your Head

Innovation doesn't mean being different for its own sake. It means finding better solutions to real problems.

Example: Need a gigabit data pipe?

Conventional thinking: "Use Gigabit Ethernet—it's standard."

First-principles thinking: What are we really solving?
→ Need: 1 Gbps throughput, low latency, simple integration
→ Constraint: Limited processing power, need low protocol overhead

Alternative approach: What if we isolate CPU cores and pipeline multiple USB 2.0 interfaces (480 Mbps each)? Three USB interfaces = 1.44 Gbps raw bandwidth. USB has simpler framing than TCP/IP, lower CPU overhead, well-supported drivers.

Is this always right? No. But it's an innovative thought worth evaluating against requirements. The question isn't "what's conventional?" but "what makes testing, building, and maintenance easier while meeting requirements?"

Balance Innovation with Pragmatism

When to Innovate

  • Conventional solutions don't meet constraints
  • Performance/cost/size gains justify risk
  • You can prototype and test quickly
  • Team has expertise or can acquire it
  • Failure mode is acceptable

When to Use Standard Approaches

  • Proven solution exists and fits requirements
  • Time/budget doesn't allow for custom
  • Support and maintenance matter long-term
  • Risk tolerance is low
  • It's not core differentiation

Essential Engineering Skills

Beyond technical knowledge, these skills separate mediocre engineers from excellent ones:

Common Sense & Logic

Ask basic sanity checks before diving deep:

  • Does this make physical sense?
  • Are the units correct?
  • Is this order of magnitude reasonable?
  • What's the simplest explanation?
  • Am I overthinking this?

Physics & Math Foundation

You can't engineer around physics:

  • Conservation laws (energy, momentum, mass)
  • Signal theory (bandwidth, noise, SNR)
  • Thermodynamics (heat dissipation)
  • Statistics (probability, confidence intervals)
  • Back-of-envelope calculations

Economic Thinking

Engineering exists to create value:

  • ROI on design decisions
  • NRE vs recurring costs
  • Time-to-market vs perfection
  • Build vs buy analysis
  • Total cost of ownership

Systems Thinking

Everything connects to everything:

  • How do subsystems interact?
  • What are second-order effects?
  • Where are the bottlenecks?
  • What fails and how does it propagate?
  • Optimize the system, not individual parts

How to Use This Guide

This site is organized around the engineering lifecycle, from early concept through delivery and support:

Fundamentals

The non-negotiables: power, mass, link budgets, timing. If you can't quantify these, you don't have a design.

Requirements & Traceability

Writing testable requirements, decomposing them, and tracing through design to verification.

Design & Trade Studies

Making defensible decisions through weighted trade studies, COTS vs custom, innovation strategies.

Integration & Testing

Building without hardware, test strategies (virtual/EM/flight), designing for testability.

Verification & Validation

Testing approaches, MTBF analysis, reliability engineering, proving it works.

Project Lifecycle

Deliverables, code freezes, hotfixes, anticipating customer needs, ROI thinking.

Reference

Quick lookups: red flags, decision frameworks, templates, checklists.

Start Where You Need

This isn't a book—you don't need to read sequentially. Jump to the section that solves your current problem. Bookmark what's useful. Adapt to your needs. The goal is practical wisdom, not dogma.