about

I build the software that runs a factory floor: device drivers and message-passing services that connect physical machines to the systems around them, and the tools operators and engineers use to see what's happening and plan around it. Some of it is about two things talking reliably when a connection drops or a check fails. Some of it is turning scattered machine data into something a person can actually act on, like knowing what maintenance is due before something breaks.

What I like about the work is that failure is never abstract. A dropped connection or an unhandled edge case has a concrete, visible consequence, and the fix has to actually hold up under real conditions.

I've mentored three junior developers, one through their first production service and two others currently, through code review and hands-on time on the floor testing what we're building. It's one of the better ways I know to catch problems early and get someone new up to speed on a codebase.

I'm part of the on-call rotation for the automation services I've built, which means the honest failure paths in this site's project write-ups aren't hypothetical. I'm the one who gets paged if they're wrong.

I've been using Claude Code for personal projects, including this site. I don't use it to skip understanding something. I use it to get through the parts that are mechanical once I already know what needs to happen: reading through an unfamiliar service before I touch it, drafting the tedious half of a migration, catching a failure case I described but hadn't handled yet. I still read every line before it ships, and I'd rather spend the time it saves on the part that actually needs a person.