Start with the customer problem
The fastest path to good software is understanding the customer's workflow, the real friction in it, and what a solved problem looks like in practice.
02 / About
Good teams make good systems. I build both.
I am a senior software engineer. Half the job is building dependable systems; the other half is building the team that runs them.
The story so far
I have spent more than fifteen years building software across ecommerce, aviation, broadcast technology, and internal business systems. The domains changed. The useful habits did not: learn the workflow, find the real constraint, make the architecture legible, and stay involved through delivery.
My work spans React interfaces, APIs, data-heavy services, cloud infrastructure, and the operational tooling around them. I am happiest when I can connect those layers instead of treating each one as somebody else's problem.
As a senior engineer, I also spend a lot of time making other engineers more effective. That can mean turning an uncertain project into a plan, reviewing a design, debugging a difficult production issue, or explaining why one tradeoff matters more than another.
Working principles
What I optimize for
Build for the next change
I favor clear boundaries, boring interfaces, and structure that reduces how much context a team has to hold — so systems can evolve without a rewrite.
Own the outcome
Implementation is only one part of delivery. I care about rollout, observability, communication, and whether the result works in practice.
Raise the whole team
Good engineering includes mentorship and teaching the reasoning, so decisions can be understood, challenged, and carried forward without their original author.
Beyond the product