How I work
I usually start by asking questions, not opening the editor. Who is this for? What are they trying to do? What would make the work useful? Once the answers are clear enough, I turn them into requirements, technical boundaries, and a release plan.
Then I build. I move between the application, APIs, data, tests, and release work as the problem requires. I don't like throwing a ticket over a wall and calling my part done.
Production is part of the job. I want to know what happens when the network drops, a field is empty, or someone taps the same button twice. The product should handle those moments without making the user carry the complexity.
I care about design for the same reason. When I start with a rough feature outline, I work out the flows, states, and details that turn it into a product someone can actually use. The shape of an API affects the next engineer. The wording of an error affects the person who is already stuck. Small details are often where a product earns trust.
I use AI every day to explore approaches, get through repetitive work, and review more surface area. I still verify the code and own every decision that reaches production. The speed only helps if I understand and trust the result.
What I write about
I write about the parts of engineering that tutorials usually skip. Most of it comes back to finding the real problem, keeping mature systems understandable, and using AI without quietly lowering the bar.
Let's talk
If you're hiring for a senior engineering role, have a product that needs an owner, or want to automate work your team is tired of doing by hand, send me a note. I read my own email.