About
Merging is the middle of the job, not the end.
I work across the stack frontend interfaces, backend architecture, and the infrastructure that puts both into production. Most of what I build is meant to run for years and be maintained by someone who is not me.
That shapes how I work. I reach for clear architecture over clever solutions, because clever code is a debt someone pays later. I write decisions down before they get argued about. And I would rather carry a feature through deployment and stay with it afterwards than hand it over at review.
The part of engineering I find most interesting is the second delivery of the same message retries, replays, duplicate events. Designing for that before the happy path is what separates a system that survives contact with real users from one that needs watching.
How I work
Five rules that decide the arguments before they start.
01
Solve the real problem before adding complexity. Most features are a symptom of a question nobody asked properly.
02
Clear architecture and readable code outlive clever code. The next person to open the file is the actual user.
03
Repetitive work belongs in tooling, not in someone's day. If it happens twice, it gets a script.
04
Systems should be observable, testable and boring in production. Excitement at 2 a.m. is a design failure.
05
Software gets good through feedback, not through planning. A deployed guess beats a perfect document.
Tools
Not everything I have touched what I actually reach for, in the order I reach for it.
Contact
I'm interested in engineering problems worth solving, products that need building properly, and teams where an engineer is trusted to own a feature end to end.
I answer within a day.