About

Before I wrote software, I worked on elevators, tracing faults through machine rooms, relay panels, and shafts where a wrong guess doesn't just cost you time, it strands someone between floors.

You learn fast that you don't shrug at a system you don't understand. You open the panel, follow the circuit, and keep tracing until the cause stops hiding behind the symptom.

That's still how I work. I'd rather spend an extra hour finding the actual fault than ship a fix that holds until the next report comes in.

Software caught me for the same reason elevators did: there's always a system underneath the complexity, and finding it is the actual job. I like code because the feedback is honest: it runs or it doesn't, the log tells you where it broke, and nobody can talk you out of a stack trace.

I don't need a problem to arrive already defined. I need one real thread to pull (the desired behavior, what steps create the problem, a place to start tracing), and I'll work out the rest, even when "the rest" takes longer than anyone wants to admit.

That patience is the part of the trade that followed me into code.

When a problem gets stressful (outage, deadline, everyone talking at once), I split it into pieces small enough to actually reason about, then go back to first principles on each one: what has to be true for this to work, and which of those things just isn't. Find the next honest step, take it, and resist the urge to solve three things at once because it feels more productive.

That's how I show up for a team, too. I'm not going to give a speech when things are on fire. I'll hand you a clearer cut of the problem when you're too tired to see it yourself, and that's usually worth more.

I don't treat software as a job title. It's one of the ways I build, alongside the stuff in the shop below.

Most of what's on this site came through my own practice: I've run ClientFirstLabs as an independent consultant since 2022, embedding with teams like Aspire, Wecasa, and Button Inc. when they need someone who can walk in, find the real constraint, and start shipping.

That's the paper trail. Here's the other bench.

I 3D model, print, and tinker with electronics because building things is the clearest way I know to actually understand how the world works. You start by noticing something real (a problem nobody invented, just one you ran into), and building the thing is how you find out whether you understood it correctly. Same habit, different tools: if it doesn't make sense yet, there's a system under it somewhere; if it doesn't work, you trace it the same way you'd trace a fault in a panel or a bug in a stack trace.

I don't clock out of engineering when I close the laptop. I just change materials: trade code for filament, a terminal for a soldering iron.