Engineering Principles
How I think about product and engineering decisions.
Not just values I claim to have. These are insights I've come to after building projects at very different stages. Some I got right the first time, but most came with experience.
How I think
The code is not the product. The solution is.
Messy code is not always a sign of bad decisions. Sometimes it was the right call at the time. Refactoring comes when you start working as people, not because the code is aesthetically displeasing, but when the gain is real.
How I decide
Start it simple or write down why.
The code outlasts the reasoning behind it. Without context, all that's left is speculation for those who come after. Documented tradeoffs are the only thing that closes that gap.
How I start
Direction before momentum.
The first question is never which framework or stack to use. It's what the user actually needs to solve. With that clear, the architecture follows. Without that, you'll just arrive at the wrong place sooner.
How I ship
Optimize for the next person, not the next deploy.
Fast delivery and clean systems aren't opposites. Naming, structure, and interfaces compound over time, for better or worse. Team speed is to write for the person who comes next.
How I collaborate
To work as a team, not as an individual contributor.
Unblocking someone beats shipping alone. Well-scoped PRs, readable code, clear decisions. None of it goes on a roadmap, but it's what keeps a team actually moving.