Work

In March 2026 I started building software for my racing rig with coding agents, and I haven't stopped. Seven months later it's 29 repositories and 2,259 commits on 128 days, one person and one model. It's the clearest record I have of how fast an idea of mine becomes something I use.

A telemetry plugin that became a platform. The first commit, on March 5, was a plugin that reads the car in real time. By May it was a motorsport information system: a live HUD over the game, race recording with a telemetry sidecar, a coach that comments on my driving as it happens, lights in the room that follow the flags, and a web dashboard that reads my racing history and tells me whether tonight is a good night to race.

Four platforms in four days. From April 23 to 26 I added native apps for iOS, macOS, Windows and Apple TV, split the one repository into seven, and moved every calculation behind one API so every screen shows the same numbers. A shared agents folder in every repository carries the instructions, so an agent working in any one of them knows the rest.

Tracks from real roads. In June I built a pipeline that turns OpenStreetMap roads and USGS elevation into tracks I can drive in Assetto Corsa: streets in Commerce City, the Lake Murray loop in San Diego, a rally stage in Rangely. I rebuilt the hard part three times. The rule that came out of it: a track only counts once I've driven it. A ledger keeps my words about what felt wrong, measures it, and closes the entry only after a drive.

Taking the cloud out. In September I brought it all back onto one machine on purpose. The racing service added its own track map, fuel and incident tools, and changed how outside apps sign in, so a hosted version depending on that sign-in was the wrong bet. Racing Desk runs for one driver on one rig: the calculations kept with their tests, the accounts, sync and database gone.

Liveries. The cars wear my own paint, the same shattered glass as the field behind this site, made with agents driving Illustrator through scripts.

Rule is one of Denver's premier art galleries, representing some of the most talked-about names in both Denver and Marfa, Texas.

Leveraging a sleek, minimalist feel, this website was a joy to work on, letting white space breathe, and giving the artwork space to speak for itself.

This site uses Advanced Custom Fields for custom post types, Timber for templating, and a statically-built React app for browsing art.

Due to COVID-19 restrictions, the gallery cannot be open to the public. We quickly put together a WooCommerce site to get cash flowing to the artsists in need again.

View the Shop

In the fall of 2020 Cisco Meraki hired four contractors to try an experiment: one React design system for the Meraki Dashboard, built in the open inside the company, that product teams would choose over rolling their own. I was one of the four. I'm the only one of the four still on it; the experiment became my job.

It's called Magnetic. It's the component library, the design tokens and themes, the charts, the accessibility work and the release train behind Cisco's network administration products. It ships monthly. I give the release talk to a couple hundred engineers.

The work in between is the work: a 2022 proposal to replace the third-party Select we'd started with, a 2023 Storybook project, a 2024 series teaching React to people who didn't think they were React people, spacing-token audits, a second theme for Cisco's company-wide design language, and the long tail of a library that a lot of teams depend on and nobody wants to be surprised by.

In 2025 I became the engineering manager for Magnetic. In 2026 I took on the other two teams under the same umbrella: the one that modernizes the existing Dashboard with it, and the one that owns the JavaScript platform underneath. Three teams, one output: the experience every Cisco administrator sees.

In March 2026 we turned entirely to agentic development, and the design system became the first thing I opened to coding agents, so they read it and use it the way our developers do. That story continues in Agents.

What's not measured yet, honestly: time saved per team, and how many teams extend the library on their own. I'm working on both.

Community Funded came to me with one need: the first version of their product that got them to where they were was built on old technology, and was now limiting their growth potential. Could I help steer them toward the right choices to make for version 2?

And could I help them build it?

After meeting with their founders, and finding that I could have a strong passion for their business, I enthusiastically agreed to help. V1 was heavily based on WordPress, something I have a unique amount of experience building and building for; React + Next.js were my suggestions for the front-end technologies, and three years later, we launched to live clients in the first quarter of 2020. I have worked hand-in-hand with the CTO, Chief Creative Officer, and VP of Product to craft not just a cohesive visual design system, but the codebase and UX patterns necessary to pull it off, in a real product, right now.

We used an iterative, design sprint-based approach that included customers, clients, success managers, board members, and executives. This all-inclusive approach led to the product improving by leaps and bounds in short amounts of time, with ideas we knew were already vetted with users.

I began my work with CF by asking questions, and iterating on Next.js-based prototypes complete with animation, beautfiul custom components, and an extensible architecture that worked as a bridge between quick prototyping and prodution-ready code.

Using a modified Agile methodology, with an ad-hoc mixture of scrum, dailies, plannings sessions and spikes, we delivered a beautiful experience to delighted users, who often found that the extensive training needed to onboard for the first version of the prdouct, was now simply unnecesary.

Rally Software was a company providing Jira-like Agile tools, which got purchased by CA in 2015. As part of a broader initiative to modernize CA's software offerings, Project Catchfly was spun up as a startup within the large corporation.

Within the first two days on Project Catchfly, I had outlined the problem the team was trying to solve – something they had tried to use Lean Startup methodology to define – and had provided the first real mockup of their app they'd ever seen.

We quickly iterated through approaches to find the right solution. We held design sprint sessions, big-room planning sessons, and worked with a team in North Carolina building the mobile version of the app.

I spent a lot of time taking Material UI (a Material Design component library implemented in React), and customizing it for our needs. This was also my first introduction to TypeScript.

When the business needed me to step out of the codebase and into Sketch in order to iterate even faster on projections 1.5 years into the future, I re-built our component system as graphical assets in Sketch.

When Project Catchfly was cancelled 9 months afer I started, I quickly pivoted to providing prototyping for the Agile Central (Rally) design team. Within a week, I had a custom component library rendering a Kanban board, that the designers were taking screenshots of to send to their developers as the final design.

I worked at Automattic for six years, and two of them were spent on Calypso, an API- and JavaScript-powered UI for WordPress. Calypso runs the WordPress desktop app, the WordPress.com UI, influences the UX of the WordPress mobile app and is built using Node.js + React.

WordPress.com is the largest installation of WordPress in the world with 131 million unique monthly users in the US. We were seeking to modernize our users’ experience by taking WordPress, which clearly still exists in its unchanged form and is in active development, abstract the core technology to an API, and build new experiences on top.

We had historically eschewed email, working together through the internally-developed P2 WordPress theme and IRC. Prior to Calypso, we usually launched code pretty quickly through Subversion to the main production codebase, and teams often iterated in silos, attending to their own needs first and foremost. Calypso changed all of that, moving a large portion of the design and development discussion to Slack and Github, adding beneficial layers of peer-based code and design review on top of each Pull Request. The end result was a more cohesive product, for us in the code and for our users in the experience. Designers started working more closely together on specific issues across teams, developers and designers collaborated in quicker iterations to get to better solutions, and the standards we used to build the app progressed along with evolving React and ES6 best practices.

Despite this increased flow of communication and priority-dovetailing, there were still inconsistencies within Calypso’s design. In September 2014, I organized a workshop for four designers to:

• Look at the UX we’d achieved at breakneck speed over the past year and a half
• Find UI inconsistencies and gotchas
• Provide recommendations on how to bring the app into a more pure Atomic Design model

Since we were already using React, this made for a perfect time to adopt a more standards-driven UI design process, placing the idea of functional components at the heart of the design language. We reviewed every page, outlined the parts of it that differed from the UX of other parts of the app, and made general recommendations for how to bring the application more in-line with itself.

The result of these workshops were 6 lengthy internal blog posts outlining the changes that we felt should be made, and created much discussion. Some recommendations were implemented by other teams and some of them were decided against by the wider group of contributors.

There was a third group of recommendations which were generally agreed upon by everyone, but were not going to be worked on by anyone, so I took it upon myself to get them finished. I took specific problems that the team had seen crop up over and over again and created Pull Requests in Github to address them. I re-engineered the interfaces in question to use core Calypso React components, got my designs and code reviewed by my peers, and launched them into production. This work is evident on WordPress.com in the following ways:

• Stats modules got simplified, including a cleaner way of clicking through into detailed information
• A cleaner Site Settings section
• Sharing Settings and Connected Applications use the same components to do the same interactions
• Standardized patterns covering Connect/Disconnect, Remove/Delete and Disable actions
• I created and edited core Calypso components as-needed to express improvements needed for implementation across the entire app

In the fall of 2006, I was part of a small team at Wall Street on Demand that pitched The New York Times on a replacement for their MarketWatch-powered (meaning competitor-powered) financial markets research portal. We continued to meet with the client periodically for about a year before work started in earnest.

While our pitch work had been valuable in demonstrating our abilities from a cold start, we needed to start all over again once things were officially underway. This included meetings on-site with news editors, graphics editors, and web designers. We learned the ins-and-outs of their archaic publishing system (since replaced with WordPress) so that we could better understand how their web content producers’ work flowed throughout the day and night.

We learned the intricacies of their standards for web design, content design, and print-based financial visualization, and weaved them together into a new set of rules. Since few of these disciplines had been integrated by the Times themselves, we had to work with them to forge a hybrid model of displaying financial information on the web that felt at home within their sprawling, ever-changing site.

As our main work would take over a complete CNAME subdomain of their site, our developers needed to build a new platform on our end that perfectly mimicked the look and feel of the actual nytimes.com. I worked hand-in-hand with the development team to build both HTML and Flash-based tools (hey it was 2008) for users to investigate market data. We also worked closely with the client’s developers to create ways in which our content could show up within the main news stories.

In 2006, when we first pitched the client, I had been with the company a year, and was still a relatively new member of the design team, taking much direction from the Creative Director. By late 2007, when we started work from scratch, I was an Associate Creative Director myself, and oversaw 60-70% of the design and front-end engineering work, managing a range of 2-3 designers at a time. Our Creative Director oversaw the broad scope of work but many day-to-day management tasks were handled by me.