A couple of weeks ago, I gave my keynote, “The Most Valuable Engineer Isn’t Shipping Features,” at Rails World 2026 in Austin, Texas.
If you want to just go ahead and watch it, here it is.
If you’re interested in the backstory… read on.
Just a few months ago, I took myself to a somewhat secluded Airbnb near the Oregon Coast and started writing it. I ordered a stack of yellow notepads, index cards, Sharpies, and a bottle of scotch.
I had been drafting ideas before my retreat, but this was when I knew I really needed to immerse myself in the subject matter. This is what proper authors do, right?
So, I was out at the coast and found myself in a flow state, with all these wild ideas about specific ways people could make their codebase easier to work in for both humans and agents. I was probably getting close to ten tangible tactics, with code samples and such.
But as I began to script this out, other patterns started to emerge. It felt like I had two different talks trying to fit into one long talk. Where would I start this thing off?
The premise for my talk was straightforward. If a software engineer isn’t shipping features… then what could be more valuable than that?
Tending to the systems that make it easier for their teammates, human or agent, to do their work.
It was the morning of my second day at the coast when I was out on a run, thinking about how focused we are on producing, shipping, and doing it safely. When do our brains get to explore things we’re curious about without necessarily needing to solve a problem every time we dig into something?
Aren’t these new AI tools supposed to be saving us time?
Is the goal of embracing AI tooling to help us ship more? Or is it to reclaim some of our cognition so we can think/learn more?
…and might there be a mutual benefit in applying some of that curiosity toward making things a little easier for whoever has to work in these systems next… humans and agents?
I began looking through our current tooling and experiments to pull out a handful of technical examples. But as I did that… I kept thinking about how quickly those recommendations could change in the months leading up to the conference.
Meanwhile, I could imagine what felt like a much more useful version of this keynote: someone walking on stage with a lot more confidence about what was working and what everyone should try next.
Which made it pretty easy to think…
This topic idea sucks…
I should suggest they replace me with someone who can confidently give everyone a list of 3-5 things they can do to improve their apps when they get back from the conference.
Surely, that would be more valuable for everyone than what I was trying to convey, right? Right!?
Who Is This For?
So… of course, I kept at it.
If I wasn’t going to give everyone a list of 3-5 things to take back to their apps, what the hell was I trying to give them?
I kept coming back to Andrea Goulet’s framing of makers and menders, which I’d planned to reference in the talk. I’ve always identified more as a mender.
I’m drawn to the work of figuring out why something is weird, understanding how we got here, and trying to leave things a little better for whoever comes along next.
I had a hunch there were a lot of other menders in the audience, too.
People who are accountable for what their teams ship, with or without the help of agents… but don’t always feel like they have the authority to step away from the immediate work and improve the environment around it.
And I could picture 4-5 specific people I’d met who I knew would be in the room.
How many more of them would be there? I had no idea… but at least I knew who I was speaking to.
Then Came WUTS
Somewhere in all of this, I began mapping out WUTS, a framework for… your curiosity. This wasn’t going to be part of my talk, but by the next day, it had become a central theme.
The message I wanted to convey to those people? Hey… when you encounter something weird… how do you channel that curiosity? What should you consider doing with it?
Maybe it’s the undocumented command you run when you hit that weird boot error, or the button you know never to double-tap because it’s slow to respond.
How can we make it less weird for whoever comes along next?
These are behaviors we already perform, but I’m realizing how often I rush through them just to get to the next thing I’m curious about. I don’t think I’m unpacking enough… nor sharing enough.
Rather than go into it all now, I launched a companion site for the talk at wuts.wtf.
Maybe you’ll find it useful… if you’re curious enough, that is.
We even snuck WUTS into Planet Argon’s conference swag. Did you get your WUTS pin?
The rest of the talk grew from there… thinking about our applications and systems as workshops we’ve built up over the years, and the role we can play in making them better for whoever has to work in them next.
Fast Forward to Austin
One thing I really appreciated throughout all of this was how much trust the Rails World organizers gave me. They handed me a keynote slot and a lot of room to figure out what I actually wanted to say with it.
I don’t take that trust lightly… especially given how many times along the way I wondered whether I knew what the hell I was doing.
DHH gave the opening keynote that morning, and there was no shortage of conversation, debate, and unease around the conference afterward about where all of this is heading.
My talk wasn’t until the end of the day… which gave me several hours to second-guess whether the talk I’d prepared was still the right one for that room.
By the time I was getting ready to walk on stage, I reminded myself of those 4–5 people I’d decided to write the talk for in the first place.
They were still out there.
What I wasn’t expecting was how many people would come up to me throughout the rest of the conference… and well into the after-party… to talk about what they’re navigating in their own careers and teams.
Turns out, there were a lot more than 4-5 of you in the room.
talk resources:
