About me

What I like most is figuring out what should exist before anything gets built. Where the boundaries between systems sit, which seams will hold once the product changes shape, what a migration path actually looks like when you cannot afford to stop the world for it.

I have a soft spot for legacy systems. They tend to get treated as obstacles, but they usually encode years of decisions that mattered to someone, and a lot of the interesting work is in understanding those decisions before you replace them. Pre-ES5 JavaScript, half-documented internal services, integrations stitched together over five different acquisitions — all of it deserves to be read before it is judged.

Once you are connecting multiple systems, you stop being able to think about one application at a time. What is right for one part is often wrong for the whole, and the work becomes about making those trade-offs visible — to the team, to product, to leadership — rather than pretending one of the options is obviously correct.

I started programming at twelve because I was bored with the games I was playing. I spent two years learning C++ to build my own — a Dwarf Fortress with far fewer features and a lot more crashes. It barely worked, and I loved trying to make it work. That impulse — pick something I do not understand, refuse to stop until I do — has not really gone away.

The professional version of that started at Albelli. The Solution Architect on my team showed me how much there was to learn and how little I knew, and somehow made that exciting rather than demoralising. He taught me that thinking you already know everything is the moment you stop being a good engineer. Five years there shaped how I work more than any single project since.

After Albelli I spent two years at Rangle, consulting across very different clients and getting a much wider sample of how organisations actually function under pressure — what survives contact with production and what only ever existed in the slide deck.

At Storyteq I have moved into the architecture role: less code written by me directly, more time spent with the people writing it, and more decisions about where the platform as a whole is going. It is a different kind of work, but the underlying job — understanding the system well enough to make a defensible call — is the same one I have been doing since I was twelve.

I am at my best when the problem is messy, ambiguous, and important enough that a clean answer does not exist yet. Give me a tidy ticket with one right answer and someone else will do it faster; give me something tangled that nobody quite owns and I will be useful for a long time.

When a problem grips me, I go deep. I like understanding not just the symptom, but the structure underneath it. That usually means I will ask more questions than feels strictly necessary before I commit to a direction — and then move quickly once the direction is clear.

I try to be direct in conversations and explicit about trade-offs. If I think a plan has a real risk, I will say so plainly; if I am the one who got something wrong, I would rather name it than route around it. The teams I have worked best with are the ones where that is just how everyone talks.

Outside work I am usually with my fiancé and our small zoo — three dogs and two cats who have firm opinions about whose chair is whose. They keep the house loud and the days structured.

I read a lot of fiction. Fantasy mostly — Hobb, Pratchett, GRRM, currently working through Sanderson's Mistborn — and a lot of Arthur Conan Doyle, whose detective stories I keep coming back to for the same reason I like the work I do: the pleasure of the structure underneath the symptom.

On the side I have been spending time in low-level programming — Rust, Zig, C — building small compilers and game engines from scratch. Most of those projects are not about shipping a product. They are how I explore unfamiliar layers of software and sharpen my understanding.

I still play OSRS.

I lift. After a couple of less active years I am getting back into proper shape.