About

I often think about what it would be like to work at, or run, a chain restaurant like McDonald's. I like to think that I'd run the best McDonald's in town, with the happiest staff and customers that chose to come to our McDonald's instead of the one 5 minutes closer.

That would genuinely satisfy me. I worked at a pizza place for most of high school and college, and I loved the process of rolling out dough, getting the right amount of sauce on the pizza, evenly placing the pepperonis, and ultimately giving that end product to a smiling customer.

That's my north star—what drives me now. I get this dopamine hit when I build something excellent, high quality, well thought out, and useful or joyful to someone.

I do like to code and software specifically, but what keeps me going is feeling my purpose is to serve people and create great tools for them.

It annoys me when people don't take their work seriously or settle for low quality. I hope for a world where the bar is higher—and I want to be part of the solution, whether that means making great things myself, or inspiring others to do even better.

In all my stops along the way in my career, I usually ended up becoming the "static typing zealot + we need linting and autoformatting + we need unit tests and integration tests" guy.

But it's not about coding purity—it's always been about moving faster and better towards delivering that end product that users love, and conversely, not breaking or delivering bad quality things.

I just can't tolerate poor developer experience. Why is the build so slow? Why does this service take 2 minutes to cold start? Why wasn't this bug caught at compile time or by lightweight unit tests? All of these things are obstacles that prevent us from bringing joy to the user.

The user empathy obsession extends to the tools that we are building for ourselves too. What will devs feel when it's time to start work on a Monday? Do they feel a sense of dread, or excitement? Are they worried that the build will be broken, or that any change they make could bring down prod? Or are they excited to build—because they know the easy problems have been solved—and their path is clear to bring new solutions to our customers?

That's really what brought me into DevEx—that thought that, if we could make one of our most expensive and precious assets (engineering staff) a little more excited to do their work, how much better would the product be?

Wouldn't this spread to every other part of the business? Better product, better employee retention and satisfaction, faster iteration + feedback loops.

My first taste of pure DevEx was with tsoa—the open source library for building OpenAPI compliant REST APIs with just TypeScript. This got into TypeScript compiler internals, building CLIs, and supporting a community of devs.

Netflix is really where I started to be able to do DevEx essentially as a full-time job—and to help lead a team of folks working towards the same mission. Media production workflows are complicated, but at the root of these workflows are a lot of tools that all have to work seamlessly with each other, and a lot of "developer surface" that—traditionally in the studio world—has been, uh... not to my standards.

What I work on now at Netflix, Studio Orchestrator, let me transform what was essentially a prototype into a production-critical platform. I helped rethink how media workflows are built and observed at Netflix scale.

We went from 0 to 1 over 3 years—a loose product idea with zero adoption to something powering the biggest virtual production operation in the world. Studio Orchestrator is now a platform—backed by Conductor, comprising a node-graph UI, rich observability tools, and SDKs—that integrates seamlessly across the Netflix ecosystem.

That experience cemented what I now know: when you improve how developers work, you improve everything that depends on their work.