Why write down engineering principles?
Engineering teams make hundreds of small decisions every day. Principles don’t make those decisions — people do. But shared principles mean those decisions accumulate in a coherent direction rather than random walks.
These are principles I’ve found durable across different team sizes and technology contexts. Not rules — principles that help you reason about hard cases.
Ship working software over maintaining perfect code
Perfect is the enemy of shipped. This is not a license to write bad code — it’s a prioritization principle. When you’re deciding whether to refactor before shipping or ship and refactor later, the default is ship.
Exception: When technical debt is actively blocking the current sprint, not theoretical future sprints. Fix it now only if it’s blocking you now.
Make systems observable before you optimize them
You cannot improve what you cannot measure. Before optimizing a system, you need to know: what is it actually doing, how fast, and where is it spending its time?
Premature optimization is still the root of much evil. But lack of observability is worse.
Prefer boring technology
Choose the technology you have the most confidence in, not the most interesting option. Technology choices have maintenance costs. The team that chose a cutting-edge database framework three years ago is now debugging arcane issues while their competitors ship features.
New technology is appropriate when you have a genuine need it addresses and the team has the time to absorb its learning curve.
Small teams, clear ownership
A team that owns a service should be able to understand it, change it, and be on-call for it. If that requires more than 8–10 engineers, the service is too large.
“Fuzzy ownership” — where multiple teams have partial responsibility — is the source of most reliability and velocity problems. It’s always someone else’s problem.
Automate the second time
The first time you do something manually, you’re learning. The second time, you’re establishing a process. The third time, you’re creating technical debt. Automate the second time.
Be explicit about tradeoffs
Engineering decisions involve tradeoffs. The failure mode is to pretend the tradeoff doesn’t exist, or to make it implicitly without acknowledging it.
When you make a decision that trades one thing for another, say so explicitly. Write it down. Future engineers (including future you) will thank you.