Product · Engineering · Design
An interface is a function of the data.
Design tells the story; the data supplies the words.
Adaptive Self-Efficacy
Twenty years ago I walked into a college career office with a graphic-design course load and no real lane. I walked out with a job shooting product photos for an ad company — which also needed a catalogue and a website, so I learned those too.
That set the pattern: I took the work that was there and learned what it needed. Design, web, photo, video, a few years around film sets, writing the whole way through. In 2015 I went full-stack, and for ten years I've written the code.
For those ten years the job was building web applications. Now I'm combining my experiences to power a turn towards product management and development.
The deciding was always the part that mattered: what to build, for whom, what to refuse. The typing was how you found out whether you'd decided well. Now the machine takes the typing, and the deciding is what's left. So I'm reaching for it on purpose.
Three things taught me how to decide, and for years I thought they were three careers.
Story — from writing and film: there's a story in everything, and the idea behind a product has one of its own.
Interface — from design and front end: not decoration on a system, but where the system and a person meet. And it's a function of the data — decide the shape of the data and you've decided the product; the screen just reports it.
Data — from ten years full stack: what's kept, what's derived, what must never be deleted. Get the shape right and the interface falls out of it.
There's a fourth thing that isn't a trade: how the product gets made — process and operations. And that's where the ground actually moved.
Because computing only ever does one thing: it builds the next abstraction on the last and hands it to you through an interface. Assembly hid the machine, the compiler hid assembly, the framework hid the compiler — each layer letting you decide more and type less. The language model is the next layer. Plain language became a way to program, so how we make software changed as much as the software. Nothing is ending. The abstraction took one more step — onto the interface itself, the thing I spent a decade learning to read.
The same shape is everywhere: an app's meaning is cut out by use, one loop at a time; a career's judgment emerges from years of accumulated craft; computing's abstractions emerge from piled-up patterns. Stock becomes flow. It's why this turn feels like arriving, not leaving.
Writing
The words you write to direct an AI aren't notes — they're source code, in plain language. The instrument in that layer is structure: name the things of your work exactly, and the shape of your information becomes the shape of your control.
Everyone building with AI runs a loop. The fold is an answer to what kind — not a loop that resets each morning and climbs toward needing you less, but one that carries, folding each result into the next until the state compounds and the interface built on it keeps getting better, with the person still at the center.
Before AI, the programmer's craft was a stack of capabilities — knowing what to build, and the iterative loop toward it. AI has been climbing that stack rung by rung, matching each and then outrunning it, until the last rung: the one that was never a capability at all.
Three trades — story, interface, data — turned out to be one job: deciding what gets built. The machine took the typing; the deciding is what's left.
We bolted a non-deterministic machine into an interface built for a deterministic one, then went looking for the trouble in the model. It isn't a tuning problem — it's an interface problem: what do we hand the machine, and what stays ours to decide?
I don't just write code — I architect experiences.
I'm a web developer who sees systems everywhere — in codebases, in narratives, in the trails that wind through fog-covered ridges. I believe the best interfaces tell stories, and the best stories have elegant architecture.
By day I build scalable web applications with the kind of obsessive attention to detail that comes from treating every project like a chapter in an unfolding world. By night, I fill notebooks with strange maps and stranger ideas.
"The map is not the territory, but a good map makes you want to explore."
Every system has a narrative
I've been building fictional worlds since before I could write code. The skills that make a story immersive — pacing, tension, consequence — are the same ones that make software feel alive. The veins of every system are full of story.
Complexity made navigable
I'm drawn to the hidden architecture of things — organizing the chaos to invoke emergent connections between systems and ideas that aren't obvious until rendered visible. I see feedback loops in everything and can't resist asking what's governing the governors.
The wilderness is a debugger
Solvitur ambulando. It is solved by walking. Hiking has taught me how to carry only what matters, navigate in the absence of signals, and find clarity where discomfort lives. My best architectural decisions happen at elevation, far from a keyboard.
Contact