First Principles ≠ "Not Invented Here" Syndrome
A dangerous misapplication of first-principles thinking is using it to justify rebuilding everything from scratch. "We derived from first principles that we need a distributed key-value store, so let's build one!" No. First principles tells you what properties you need. It doesn't tell you to ignore existing implementations that provide those properties.
The correct application is:
- Derive the properties you need (first principles)
- Evaluate existing solutions against those properties (informed analogy)
- Build custom only when no existing solution satisfies your specific constraints
Analogy ≠ Laziness
Using analogy is not intellectual laziness when done deliberately. If you've verified that your context matches the reference case, adopting a proven pattern is the smart choice. Spending three weeks deriving your CI/CD pipeline from first principles when GitHub Actions would work fine is not engineering rigor—it's waste.
The "Best Practices" Trap
The phrase "best practice" is the most dangerous phrase in engineering because it implies universal applicability. There are no best practices—only practices that are best for a specific context. When someone says "best practice," mentally append "...for companies like [reference case] operating at [reference scale] with [reference constraints]."
Examples of "best practices" that are context-dependent:
- "Always use HTTPS." Best practice for web-facing services. But for service-to-service communication inside a private VPC (Virtual Private Cloud) with no external access, the TLS (Transport Layer Security) handshake overhead might not be justified (though it often still is for defense-in-depth).
- "Never store state on disk; use a managed database." Best practice for horizontally scaled web services. But for a single-instance CLI tool or embedded system, SQLite on disk is simpler and eliminates a network dependency.
- "Use infrastructure as code for everything." Best practice for teams managing dozens of resources. But for a single developer with one EC2 instance, clicking through the AWS console and documenting the setup might be faster and equally maintainable.
If an interviewer asks "What are the best practices for X?", don't just list practices. Start with: "It depends on the context. For a team of [size] operating at [scale] with [constraints], I'd recommend... But if the context were different—say [alternative scenario]—I'd change my approach because..." This immediately signals senior-level thinking.
The Sunk Cost Trap
A subtler pitfall occurs when first-principles analysis reveals that a past decision was wrong, but the team has already invested heavily in it. The correct response is to update the decision based on new understanding. The incorrect response—which is extremely common—is to double down on the original decision to avoid admitting the sunk cost.
If your first-principles analysis reveals that your Kafka cluster is solving a problem you don't have, the right move is to plan a migration to a simpler solution, not to find new use cases for Kafka to justify its existence. Sunk costs are irrelevant to future decisions. The question is always: "Given where we are now, what is the best path forward?"
Key Point: The most sophisticated engineers hold both modes simultaneously. They know the recipes and understand the chemistry. They can follow a pattern at speed when appropriate and break from it with confidence when necessary. This dual fluency—not rigid adherence to either mode—is what defines engineering maturity.