About
I wrote my first production code more than 18 years ago, and I still get a small kick out of watching something I built go live. Since then I have worked across a lot of ground — early-stage startups and enterprise platforms, products started from an empty repository and legacy systems nobody else wanted to touch. Somewhere in there I was a software architect and a technical lead, but the label that fits best is just: engineer who ships.
What I actually enjoy is the untangling. A vague problem, a system that drifts out of sync, a codebase that has grown afraid of change — those are the ones I like. The satisfying part is rarely the clever bit; it is finding the simplest shape that makes the whole thing obvious in hindsight.
The last few years have pulled me toward AI, the production kind. RAG systems that answer from a company's real documents, LLM integrations that survive real users, agents that quietly take over the boring work. I use these tools every day in my own workflow, so I have a good sense of where they shine and exactly where they still need an engineer standing behind them.
I am pragmatic about technology. I have shipped across a lot of stacks and I am fond of none of them in particular — on any given project I reach for the smallest set of tools that solves the problem and stays maintainable after I am gone. I keep learning because the field keeps moving, and because it is genuinely fun.
How I approach the work
Simple over clever
The best solution is usually the one the next person understands without me in the room. I optimize for readability and change, not for showing off.
Decisions, written down
Every non-obvious choice has a reason. I like to make the trade-offs explicit — in code comments, in an ADR, or in a note like the ones on this site.
Ship, then learn
Software teaches you things only once it meets reality. I favour small, reversible steps into production over big-bang launches.
Boring where it counts
Infrastructure and data integrity should be predictable to the point of dull. I save the excitement for the product, not the pipeline.
Understand before changing
The bug is rarely where it first looks. I read the system and reproduce the problem before touching it — a fix you do not understand is a fix that comes back.
Automate the boring, keep the human
Repetitive, certain work goes to tools and AI agents; the judgement calls stay with a person. Knowing which is which is half the skill.