I have one trick and I run it on repeat. Find a corner of the world full of rules nobody has modeled well. Fire code. Pilot duty limits. The scoring math of a twenty-four-hour race. Learn it until it's boring. Then turn it into software that's right enough to disappear into the work.
Do that well and people stop noticing the software at all. They just notice that the thing they have to do every day got quietly easier. That's the whole job, and it's the one I keep coming back to.
The staff box on the left is a joke with a straight face. I write the code, draw the screens, run the servers and answer the phone. One person. That isn't a weak spot to explain away. It's a constraint that shapes every system I build. Nothing gets shipped that one person can't hold up at 2am.
§ 1 · first editionA fire-alarm app and a borrowed degree
My first real product was a fire-alarm inspection system I built for my dad's company while I was supposed to be paying attention in college. It encoded the parts of NFPA 72 the techs actually wrestle with, generated the reports they had to hand inspectors, and ran for five-plus years with effectively zero maintenance. Long enough that management tried to replace it and couldn't make the case.
The degree was almost an accident. I didn't really want to be there. I was already shipping software on the side, so I followed friends through CS, CE and EE classes and walked out with a computer engineering degree and a habit I never kicked: build the thing once, build it right, watch it keep working.
In hardware, there is no patch. You know every limit before it ships, because there is no after.
§ 2 · beats coveredThree industries, identical job
Since then the same skill has shown up in three unrelated places: fire-safety inspections, aviation crew-duty scheduling, and endurance racing. Take a fuzzy domain that lives entirely in someone's head and make the computer understand it without ever getting it wrong.
It turns out modeling the FAA's duty-hour math and modeling pit-stop penalties are the same problem wearing different clothes. Most engineers never get to do this once. The pattern of my career is getting to do it over and over.
Fire code
NFPA 72, encoded so a tech in a stairwell gets the right answer.
Crew duty
FAA duty-hour limits, where a wrong answer grounds a flight.
Race scoring
Laps, stints and penalties, live, for about fifty cars a weekend.
§ 3 · the night deskEight years on the timing stand
For most of a decade I've quietly been the whole technical department of an endurance racing series. Live timing and scoring pulled straight off the hardware. RFID read over cell modems trackside. A custom server I wrote just to time pit stops. Registration, payments, and the messaging that keeps a paddock of fifty cars pointed the same direction. All of it mine. All of it still running, basically crash-free, across years of race weekends.
GridPulse is what happens when you take everything you learned doing that the hard way and build it properly, for everyone else. I'm not guessing at this market from a spreadsheet. I'm in the paddock. Read the weekend it first ran →
§ 4 · editorial policyHow I build
Make it work, make it right, make it fast. In that order. I build to find the real shape of a problem, then delete most of the first attempt once I can finally see it clearly. I care about the whole thing, the architecture, the interface and all the unglamorous edges in between, because that's exactly where software earns trust or quietly loses it.
And I genuinely cannot leave a finished thing alone. Every “done” just looks like a better place to start. Which is, more or less, why the studio is called a restless mind.