Engineering Principles
How I think about product and engineering decisions.
Not values I claim to have. Positions I've ended up at after building things at different stages. Some I got right the first time. Most I didn't.
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. I refactor when it starts slowing people down, not because the code bothers me aesthetically, but when the gain is real.
How I decide
Go simple or write down why.
The code outlasts the reasoning behind it. Without context, whoever comes next fills in the gaps with assumptions. 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. It's what the user actually needs to accomplish. Once that's clear, the architecture follows. Without it, you're just building fast in the wrong direction.
How I ship
I move at a speed the next person can build on.
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
A team that moves well is worth more than any individual output.
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.