Engineering Principles
Beliefs that guide how I build software and lead teams.
1. ship first, polish later
Working software beats perfect plans. Get something in front of users fast. Iterate based on real feedback, not assumptions. A shipped feature with rough edges teaches more than a polished feature in staging.
2. choose boring technology
New frameworks are exciting. Proven tools are reliable. Use technologies your team knows well. Innovation should happen in the product, not the stack. PostgreSQL, Redis, and a simple REST API solve most problems.
3. simplicity is a feature
Complex systems fail in complex ways. Simple systems are easier to debug, scale, and hand off. Delete code aggressively. Resist adding features "just in case." The best code is code you didn't have to write.
4. minimize dependencies
Every dependency is a liability — a potential security issue, breaking change, or abandoned project. Before adding a library, ask: can I solve this in 50 lines? Own your critical paths.
5. document decisions, not just code
Code explains what. Documentation explains why. Future you (and your team) will thank present you for that ADR. Write docs while context is fresh, not when you're onboarding someone new.
6. own the outcome
Your job isn't to write code — it's to solve problems. Understand the business context. Talk to users. Question requirements. A feature that solves the wrong problem is worse than no feature.
7. sustainable pace wins
Sprints should be sustainable. Crunch leads to bugs, burnout, and bad decisions. Consistent velocity beats heroic efforts. Build systems that don't need heroes. Take care of yourself and your team.