About me
I have always been drawn to systems that take time to understand.
That started with games and code, but over time it became architecture: legacy platforms, unclear ownership, awkward integrations, and technical decisions where there is no perfect answer.
I started with games
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, picking something I do not understand and refusing to stop until I do, has not really gone away.
The moment software got bigger than code
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.
Consulting made the pattern obvious
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.
Why architecture fits
At Storyteq I have moved into the Principal Engineer 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.
What I am like to work with
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
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.
On the side I have been spending time in low-level programming (Rust, Zig, C) building small compilers and game engines from scratch.
I still play OSRS.
I lift. After a couple of less active years I am getting back into proper shape.