One of my son’s friends messaged me asking how to get started with coding.
My answer was to start with AI. Use ChatGPT or Claude, probably the paid versions, and have it help you code something that you actually care about.
That’s how I learned to code with WordPress. People wanted features that WordPress didn’t have out of the box. I figured out the code to make it work. That cycle of problem then solution kept me moving forward.
AI makes this easier if you use it right. If you just ask for a finished game, you probably won’t learn anything. If you ask the model to explain what it built, piece by piece, then you start learning.
To provide a concrete example to my son’s friend, I asked ChatGPT to build a Frogger style game in JavaScript. One prompt and I had a working game in the browser.
Frogger Game Preview
Starting from something that is working then provides many threads that can be pulled on:
Explain why all of this works.
Break down the code section by section.
What code defines the cars, frog, and logs?
How can we use actual images?
How can we change the speed of the pieces?
How can we insert in a concept of leveling where the difficulty starts out as easy and gets much more difficult?
Each of these threads, or questions, is small enough that you can ask AI to walk you through it. Each time you walk through one of these questions, you’ll gain a bit more knowledge.
You can even push further and ask it to build you a whole learning plan around extending Frogger. The game is not the point. The point is pulling on those threads until the pieces start to click.
This past week, I was in York, England to see the folks from team Shilling. It was a good meetup, with a good mixture of fun and work activities.
The biggest takeaway from the meetup was seeing faces light up with joy as Claude Code worked magic. The most fun thing was playing Dungeons and Dragons, which I hear now makes me an official Shill.
I got this photo of Ember while we were at Bahama Bucks to get a weekend snow cone.
We were in Houston last week for some medical research appointments for Ember. What this really meant is that we spent a few hours at the hospital and then a lot of hours in the hotel room.
While waiting around in the hotel room, I decided to deploy some code to WordPress.com. As I was walking through the steps, I had Ember type in shift + y to handle the final deploy to 100s of Millions of sites. 😄
Yesterday morning, Ember and I snuck out for a burrito at El Norteno. Ember had pancakes with syrup for the first time. 😄
While I was doing a bit of work this weekend, Sara decided that Ember needed to come spend some time with Dad in the office. ❤
This past week, I was in Lisbon with the Gamma team. It was a great week, filled with discussion about PCI compliance, demos, upcoming work, great food, and a bit of fun.
Below are some photos from the meetup.
As I was swapping out laundry yesterday, I sat Embed down in the half-full laundry basket. She liked it for maybe 10 seconds and then wanted to be picked up.
I snuck away for dinner on Tuesday night with Sara and Ember.
Sara went to DFW today, so I got to spend much of the day with Ember. Starting with giving her breakfast. ❤
Earlier this week, I spent a few days in Miami with the Quark team. We did quite a bit of work, but still found some time to head to walk along Muscle Beach and play a game of Pokemon.
We’ve used automatic waterers at home, for our pets, for a while. They refill themselves, which is sweet.
They also leak. Constantly. The seals wear out. The fittings are garbage. I’ve bought replacement parts, bowls, adapters. Today, after another new bowl leaked straight out of the box, I gave up.
I bought one of those upside-down jug waterers. Put it by the hose. I’ll just fill it every few days.
Automation’s great until it becomes your newest maintenance burden.
Same with teams. Permissions. Infrastructure. CI. If your “easy” system isn’t reliable, it’s just waiting to leak.
Earlier this week, I flew to Los Angeles to spend a couple of days with one of my teams, Chronos.
I grabbed this impromptu photo in our working space.
We took this photo at dinner.
And then grabbed this wonderfully imperfect set right before I ran out the door, with my phone balanced on a power adapter and the shutter triggered from my Apple Watch.😂
Sara sent me this photo of Ember from their lunch today.
This past Wednesday, I went to the Destined Rivals prerelease at Collector’s Den and won 2 out of 3 matches. 😄
I hadn’t touched code in six months. Had never worked on Tumblr. And I’d spent the last five years in engineering leadership.
The prompt I got? Do a speed run project to get from zero to one site migrated… in 2 weeks.
So yea. I laughed. Then panicked.
Fortunately, I was joining a team that had already done good foundational work. The challenge was just to get something across the finish line—fast.
Taking Stock
At first I got caught up in everything that might go wrong:
How do we migrate users?
What legal implications, such as terms of service, are involved?
How do we handle content moderation?
What about the differences in how Tumblr and WordPress store and render content?
How will we hydrate Tumblr’s APIs from this new data source?
But, the tight timeline was a gift. Because it forced me to realize that none of this was essential for migrating a single site.
We picked a Tumblr-owned blog with only one user: staff.tumblr.com. To handle content format differences, we decided to just export and migrate rendered HTML. To keep Tumblr’s APIs working, we double-wrote to both Tumblr and the migrated blog on WordPress.com.
With that framing in place, we moved on to just the things that were absolutely necessary:
Theme
Content
Interactivity
Moving Forward
For each of these, I then approached them with the minimal set of requirements.
For the theme, I went to staff.tumblr.com, viewed the source, copied it into index.php, and added a quick style.css. And committed that to WordPress.com. 😂
Dirty. But it worked.
The team had already done some work exporting rendered HTML from Tumblr. We took that export and piped it into WordPress.com using WP-CLI. Now we had something to look at.
Then I started cutting up index.php into real templates and added the WordPress loop. At that point, we had a mostly working theme that we could iterate on.
For interactivity, we stepped through this one-by-one:
Reblogging: Tumblr stores references. WordPress.com duplicates. We deferred solving this.
Likes, reblogs, embeds: Tumblr uses iFrames, so we copied them.
Archive pages: We quickly built a template that mimicked Tumblr production.
Notes: We added a new endpoint on Tumblr to fetch notes, cached the result, and skipped the complexity of partial migrations.
With this approach, we were able to migrate a single site in about 2.5 weeks.
Iterating Through Weirdness
That initial migration wasn’t perfect—but it gave the team what we needed to build momentum. From there, we kept scaling and refining.
Of course, weird things came up as we iterated. 🫠 But the team stuck with it and scaled the approach from that one messy win.
Migrations were slow. As we added more content, we uncovered new edge cases—and had to migrate even more data to handle them.
Functionality needed to be rewritten as we considered more edge cases.
At times, this approach felt slower than designing the perfect system up front.
Maybe it was.
But it was real progress. And that mattered more.
The lesson?
When you’re working on something massive, don’t try to solve it all at once.
Solve one piece. Then the next. Then the next. Move fast. Build momentum.
