Run Out to Meet It

Charity, welcome to Still Burning. It is great to meet you in person. I've read a bunch of your stuff. We've interacted, but never in person. So it's great to have you here.

Honestly, it's kind of hard to believe that, but yeah, no, it's great to be here. It's a lovely place.

When did you first know you were a geek?

I was homeschooled when I was young. I didn't touch a computer until I went to college. I actually had a performance piano scholarship. I started to realize that the people who played piano for a living — they graduated in music, and then they were still in their 20s, 30s, 40s hanging around the music department, accompanying, giving piano lessons, then going to work at Subway. And I was just like, no. And that's when I started hanging out in the basement of the computer labs. That's where I learned that I was a geek. That's when I learned that geeks existed. And I definitely was one of them.

I use GeePaw Hill's definition of geek — someone who's highly technical, highly creative, and highly desirous of being both. Like you, I also spent time in the music school — guitar. And I did music and computer science every other year. I just ended on the wrong year.

You talked about how a year ago you couldn't necessarily see exactly where the genies were going.

I just wrote a little Substack post about this. Eleven months ago, Fred Hebert and I were giving the closing keynote at SREcon 2025. And our big pitch was: okay SREs, it's time to learn to vibe code — pause for cynical laughter. Our big pitch was: people aren't going to take you seriously when you try to slow things down unless your complaints are coming from inside the building. And I look at that now and I'm like, that was less than a year ago. I can't even connect with it.

I think it was reasonable until sometime in 2025 to be very skeptical about whether or how long it would take AI to generate code roughly as good as a median developer. At some point it turned a corner. A lot of people seem to date that back to the Claude Opus 4.5 release. That's just in the past few months — dizzying.

You can try something and it doesn't work and you can feel all superior. And then a week later, you try the same thing in the same circumstance — smooth as silk. I didn't have to do anything to get better tools. But also: oh, holy crap. What does this open up for me next?

And so the advice that I would give now is: this is coming. It is changing the way we build software. You should spend your time at work doing this if you can. If you can't, do it at home. You want to run out to the waves. Don't sit there and wait for the waves to come to you. Run out to meet it. Because it's hard to master, but it's really easy to get started. And it's never going to be any easier. It's always going to be the easiest right now. We're all novices. And there's a real fellowship in that.

That's my hope for our community — that we're going to be learning and helping together. Everybody's ignorance has been reset to 100. All at once. And it doesn't matter how experienced you are, how smart you are, how broad your experiences are, how well you write — none of that stuff matters. Everybody's back to ignorance 100. And the only way out of that is doing some stuff.

I've gotten some spicy questions from SREs — "my value add for my entire career has come from this part of the software development lifecycle that we're saying is gone." But SREs seem to be doing great. SREs have always been very outcome-oriented. The people who I see struggling right now are the software engineers who have taken the most pride in their craft. The best proxy that we have had for maintainability has been: is it beautiful? Is it well-architected? Is it idiomatic? We've rewarded people for this for so long. But I think it's really hard to give that up.

I wrote two books about writing code that people can read — Implementation Patterns and Smalltalk Best Practice Patterns. And I took and still take great satisfaction in taking something, looking at it, not really understanding it, then just tweaking and massaging until the fundamental structure of the logic is completely revealed to anybody who wants to read it. Nobody's reading it anymore. That just doesn't matter.

And we have to get used to that. It's not that understandability doesn't matter, but that kind of understandability to a human doesn't have leverage. If I could write code that the genie could read and humans couldn't read — that would be the right way.

The number one debugging technique that almost every team has is: oh, something broke — by the person who wrote it. Whoever wrote it, even if they wrote it a year ago or a minute ago, they are the one who's going to be able to figure it out the fastest and fix it. And what happens if you don't have that person? The code is not the system. You might understand the code, but you put it in one system versus a different system and everything changes. Unless you've instrumented it, you don't know what's happening.

My sense of code review? I've been anti-asynchronous blocking code review for a very long time. I think we as geeks have a tendency to want to avoid human contact — and I've seen the fetishization of blocking asynchronous code review because then I don't have to talk to people. I submit my PR and get the feedback electronically. There are ways to make human communication safe, and when you do, there are huge advantages — social norms that grow naturally, knowledge shared around. I'm not a big fan of code review as ritual.

Code review has been so overloaded for so long. We use it for teaching people, for shared context, for trying to hold a standard of consistency. But what really struck me about code review now is: the PR was never really supposed to be about catching bugs. It's about: do I want this in my product or not?

I wrote a blog post about disposable code versus durable code. At the time, nine months ago, it was still reasonable to say: the best way to change durable code is by taking what is known to be good and making small iterative changes to it. But new workflows for durable code are emerging that are based on a different model. I don't think auto-generating from specs will replace all durable code models. But the landscape is genuinely unclear.

Nobody knows. Do I have a spec, regenerate from it, that's the disposable model? Or do I have a thing that works and make changes to it? I don't know which is going to predominate or what the landscape looks like when you'd choose one versus the other.

My heuristic that I've used for 15 years is: the closer you get to laying bits on a disk, the more rigorous you need to be. Persistence problems have a nasty habit of being permanent — or very hard to back away from. And so we put all this discipline around it.

I am worried about the junior. Not worried about them in the sense that they can't figure it out. I get these questions from a sophomore CS student — what do you tell them? What an awesome time to become a programmer.

I think that could be true, but that depends on someone being willing to hire them. I was watching — an Anthropic co-founder was on a podcast and he just straight up was like, "oh yeah, we don't even hire anyone except the very super senior. We have no use for anyone in the middle, let alone the juniors." And I'm just like... wow. Did you hear yourself? But the thing is, it doesn't have to be true for all the smart people in the industry to follow that lead. And for the kids to get worried, and for really smart people to leave the field.

And they are going to figure out these tools in ways that we can't even imagine. They're going to smoke us when they get a chance.

I believe you are right. But someone has to be willing to give them a shot. The main thing is — everywhere I know of where companies are investing in junior engineers in the last year or two, it wasn't driven by managers, or execs, or accountants. It all came from senior engineers, people who were in those shoes in the last five to ten years. They were the ones who brought it up and didn't let it go. Engineers often act like they don't have power or authority over things like this. But if you make yourself annoying enough — and often if you volunteer to do some of the work — I've seen it happen in many places.

I love that the question you asked me was: how are you playing with these things? You have to run to meet the wave. I think the best way to get a handle on your anxiety is to realize how easy it is to get started. What makes me happy might not make you happy — which is why you can't wait for someone to give you your assignment. You have to find the fun. Do the thing. Find the fun. Because if you can tap into it, you'll stop feeling like the cool kids are over there doing this thing and it's going to come get me.

Charity, what an absolute pleasure to talk with you. Thank you so much for coming up here. I really appreciate it.

Thanks for having me. Very nice to see you. Bye.