I write code, do math, build hardware, and teach.

I started close to the product.

Early work took me through API platforms at AT&T, payroll infrastructure at ZenPayroll, and computer vision for fresh-produce growers. The domains were different, but the lesson was consistent: a system is judged by what a user can reliably do with it, not by how elegant the architecture diagram looks.

I kept following the difficult parts downward. A feature depended on a runtime assumption. A platform depended on a trust boundary. A distributed service depended on an identity nobody had made explicit. That trail led from applications into developer platforms, cloud systems, security, and eventually the layers below the operating system.

Then I built a school around the gaps.

I founded newline (formerly fullstack.io) because too much technical writing showed what to type without explaining how the system worked. It grew into books, courses, software, and a community of engineers: more than 50,000 developers reached, ten technical books, and classrooms on five continents.

Teaching changed the way I build. If I cannot give someone a useful model of a system, I probably do not understand it well enough yet. The best explanation is not a simplification that hides the sharp edges; it is a map that shows where they are.

Understand the difficult system deeply enough to make it useful without sanding away the constraints that make it true.

The systems got larger, and the boundaries got sharper.

At AWS, I worked on distributed machine-learning infrastructure and secure cloud systems. Later, in financial technology, I helped move legacy banking infrastructure toward a cloud-native platform serving more than 100,000 customers. Security work—including three Stripe capture-the-flag competitions—made the abstractions less forgiving: where does authority enter, how far can failure travel, and what evidence remains after the system makes a decision?

Now I’m working on the machinery beneath the prompt.

These days I’m building secure execution infrastructure for AI agents, deterministic compute runtimes, microVM systems, and content-addressed objects. The work reaches into Rust, Lean, applied mathematics, hardware, kernels, hypervisors, filesystems, and protocols.

It is all part of the same question: how do we make powerful computation easier to use without becoming vague about what it is allowed to do?

Away from the keyboard, I mentor engineers, referee youth sports, and keep learning formal methods. I’m still curious about nearly every layer of computing—and about the human systems that make the technical ones matter.