About

A lot of my interests look unrelated at first.

I’ve contributed engineering work to medical software, developer infrastructure, and Kubernetes tooling. In my own time, I’ve built community software, an AI-assisted writing tool, and a life simulation.

The common thread is that I like complicated systems: lots of interacting pieces, relationships, rules, state, and consequences. I like figuring out how those pieces fit together, and what happens when they interact.

I'm a software engineer, but the technology itself is rarely the part that interests me most. I'm much more interested in what you can do with it: what it lets you understand, build, or make possible.

Relationships matter

I tend to be interested in software where the relationships between things are as important as the things themselves.

In Multiforum, users, forums, content, permissions, moderation, and plugins overlap; a single piece of content can belong to several communities. Beta Bot keeps chapter summaries, characters, locations, wiki pages, and source history connected so later feedback has the context of the story so far. Clockwork Town models residents through changing needs, locations, schedules, memories, and relationships.

See the personal projects and screenshots →

Hidden state needs an interface

Software gets difficult when important state exists somewhere the user can’t see. I’m interested in making that state legible without making the user understand the entire implementation.

At Flightcrew, I implemented a GitOps-style diff that showed proposed Kubernetes configuration changes before a user applied them, along with the expected effect on cost and resource utilization. The product and its decisions were collaborative; my contribution was the engineering work that made those proposed changes inspectable.

In Multiforum, the same instinct shows up in versioned plugin configuration, pipeline status, failure reporting, retries, and recovery. Loading extension code is easy; the harder problem is helping administrators understand what ran and what happened.

See professional roles and technologies →

Read about the plugin system →

Rules create behavior

Rules aren’t merely implementation details. Permissions, moderation policies, workflows, configuration, and failure boundaries change what people can do and how a system behaves.

Multiforum is the clearest example because I chose the problem and make the tradeoffs. Moderation works at both forum and server scope. Content can appear in more than one forum. Server administrators choose which plugins are available, while forum owners choose which of those plugins to enable. Each rule changes the possibilities available somewhere else in the system.

I usually start with a question

My personal projects rarely start with a technology I want to use. Usually there is something I want to understand, and building software is how I explore it.

Multiforum started with questions about online communities. How much should the platform decide about how a community works? What should be built in, and what should individual communities be able to change? Once communities can work differently, what happens to permissions, moderation, content, and the relationships between them?

Clockwork Town asks a different kind of question: what happens if simulated people behave because of interacting needs, relationships, values, locations, and events, rather than mostly following scripts? Much of the fun is seeing behavior emerge from the rules instead of deciding in advance what should happen.

Beta Bot grew out of questions about using AI with long-form fiction. A novel isn't just a sequence of chapters; it accumulates characters, places, relationships, history, and context. How can a tool keep track of that growing world well enough to give useful feedback about what comes later?

The projects end up looking very different from one another. The part I enjoy is similar: define enough of the system to make the question concrete, build it, and then find out what I failed to anticipate.