Theengineeringbeliefsthatshapeeverydecision
Not frameworks. Not rules. Beliefs — forged from building systems, breaking systems, and rebuilding them better.
Core Beliefs
Categories
Years Refined
Philosophy
Belief System
Core beliefs
Infrastructure over features
Features have shelf lives. Infrastructure compounds. I'd rather build the engine that generates 100 features than hand-craft any one of them. The leverage is in the layer below.
Constraints are creative fuel
Unlimited options produce mediocre work. The best systems emerge from tight constraints — limited time, strict performance budgets, narrow APIs. Constraints force clarity.
Taste is a technical skill
Knowing what to build matters as much as knowing how. Taste — the ability to judge quality, spot over-engineering, and feel when something is right — is earned through iteration, not intuition.
Speed is a compound advantage
Fast iteration beats perfect planning. Shipping early gives you data. Data sharpens direction. Direction reduces waste. The team that ships fastest learns fastest, and learning is the real output.
Code is a liability, not an asset
Every line of code is something that can break, needs testing, and must be understood by the next person. The best engineering deletes code. The goal isn't more — it's enough.
Interfaces outlast implementations
The contract matters more than the code behind it. Good interfaces survive rewrites, team changes, and paradigm shifts. A well-designed API is the most durable thing you can ship.
Readability is a scaling strategy
Clever code doesn't scale past the person who wrote it. Readable code scales to any team size. I optimize for the engineer reading this at 2am, six months from now, with no context.
Always question the abstraction
Abstractions are hypotheses about what will change. Wrong abstractions are worse than no abstraction. Before reaching for a pattern, ask: what variation am I actually protecting against?
Design is decision architecture
Good design isn't about aesthetics. It's about reducing the number of decisions a user has to make. Every pixel, every interaction, every state should guide — not question.
Depth beats breadth
I'd rather understand one system at the kernel level than ten at the tutorial level. Deep knowledge compounds across domains — the patterns you see at depth are invisible from the surface.
Values
What I value vs. don't
Optimize for
Avoid
“The best code I've ever written is the code I didn't have to.”