// the through-line
I find a cost I keep paying by hand, then build the thing that absorbs it.
It's the most reliable thing anyone can know about me, and it holds across contexts that look nothing alike. The clearest version is also the oldest: long before any of this was a job, I ran what amounted to a one-woman supply chain inside an online game's player economy. Read as a career, it had a procurement function and a documentation department. It went in four moves, and every one of them started as something I was doing by hand and got tired of.
- The marketplace took a cut and hid the counterparty from me, so I left it and negotiated direct, in bulk, with the people actually on the other end.
- Coordinating buyers and deliveries by hand got tedious about a week in, so I automated the coordination.
- The same questions kept arriving forever, so I wrote the reference manual — 1,700+ documented functions, with an early language model pressed into service to draft the descriptions, years before reaching for one was an obvious thing to do. When the docs weren't enough, I made videos.
- Part of what the operation ran on wore out at a steady rate I couldn't engineer away. So I stopped treating that as a bug to drive to zero and started treating it as a supply problem: price the loss in, secure the resupply, keep running.
That last one is the move I'm proudest of, and it's the easiest to miss. Most people in that seat optimize harder and get angry when the losses happen anyway. Treating an irreducible attrition rate as a base rate instead of a defect is inventory management, derived from first principles, inside a game.
Everything since has been the same move in a different costume. Every project on my portfolio is a cost I decided to stop paying by hand — an assistant that screens my phone so I don't, a framework I generalized and gave away, a background job whose promise outlives the process that made it.
I teach the model, not the answer
My instinct with a question is to hand over the structure that generates answers rather than the answer itself. That 1,700-function reference wasn't documentation; it was an artifact that answered while I slept. Docs, then videos, then a language model drafting descriptions — none of that was giving up on teaching. It was teaching one-to-many. It's also how I'd rather be taught: tell me why the shape is what it is and I'll get the rest faster than an answer would have gotten me there.
The coordination layer is the part I actually want
Ownership, sequencing, dependency under time pressure — that's what holds my attention, and a logistics problem will hold it when a CRUD problem won't. Worth saying plainly: it was never the dealmaking. I don't miss negotiating contracts even slightly. The part I liked was automating the coordination, not performing it.
I know exactly where that came from. FIRST Robotics in high school is still the happiest I've been: a hard problem, a trusted team, a deadline, and hands and mind making a machine actually work. All four. I've been quietly scoring things against that list ever since, and it's usually the fastest way to tell whether I'm going to be any good at something.
If you want the structured version, my résumé lays out the work, and my portfolio shows a few of the things I've made.