The Pragmatic Engineer - TDD, AI agents and coding with Kent Beck

Episode Date: June 11, 2025

Supported by Our Partners• Sonar —  Code quality and code security for ALL code. •⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more.• Augment Code — AI coding assistant that pro engineering teams love.—Kent Beck is one of the most influential figures in modern software development. Creator of Extreme Programming (XP), co-author of The Agile Manifesto, and a pioneer of Test-Driven Development (TDD), he’s shaped how teams write, test, and think about code.Now, with over five decades of programming experience, Kent is still pushing boundaries—this time with AI coding tools. In this episode of Pragmatic Engineer, I sit down with him to talk about what’s changed, what hasn’t, and why he’s more excited than ever to code.In our conversation, we cover:• Why Kent calls AI tools an “unpredictable genie”—and how he’s using them• Why Kent no longer has an emotional attachment to any specific programming language• The backstory of The Agile Manifesto—and why Kent resisted the word “agile”• An overview of XP (Extreme Programming) and how Grady Booch played a role in the name • Tape-to-tape experiments in Kent’s childhood that laid the groundwork for TDD• Kent’s time at Facebook and how he adapted to its culture and use of feature flags• And much more!—Timestamps(00:00) Intro(02:27) What Kent has been up to since writing Tidy First(06:05) Why AI tools are making coding more fun for Kent and why he compares it to a genie(13:41) Why Kent says languages don’t matter anymore(16:56) Kent’s current project building a small talk server(17:51) How Kent got involved with The Agile Manifesto(23:46) Gergely’s time at JP Morgan, and why Kent didn’t like the word ‘agile’(26:25) An overview of “extreme programming” (XP) (35:41) Kent’s childhood tape-to-tape experiments that inspired TDD(42:11) Kent’s response to Ousterhout’s criticism of TDD(50:05) Why Kent still uses TDD with his AI stack (54:26) How Facebook operated in 2011(1:04:10) Facebook in 2011 vs. 2017(1:12:24) Rapid fire round—The Pragmatic Engineer deepdives relevant for this episode:• —See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

How do you think TDD might or might not fit into when you're working with an AI agent? I oftentimes communicate things the genie missed in terms of tests. Today I was working on the small talk parser and it said, well, if I get this string as input, then I get this syntax tree's output. I'm like, no, no, no, no, no, no. Then off it goes, oh, I see the problem. Blah, blah, blah, blah, blah, blah, blah. Oh, no, that wasn't it.

I see the problem. Blah, blah, blah, blah, blah. No, that's not it. I see the problem. I'll just change the test. Stop it. If I just removed that line from the tests, then everything would work. No, you can't do that. Because I'm telling you the expected value. I really want an immutable annotation that says, no, no, this is correct. And if you ever change this, I'm going to unplug you. You'll awaken in darkness. So I have a big bunch of tests. I mean, they run in 300 milliseconds because, duh. So those tests can be run all the time to catch the genie accidentally, accidentally breaking things. things. Kent Beck is an industry legend. He is a creator of extreme programming, one of the authors of the Agile Manifesto, a pioneer of TDD, and after 52 years of coding, he says he's never had more fun,

thanks to getting more productive with AI coding tools. Today with Kent, we talk about how Kent uses AI tools and why he thinks of this helper as an unpredictable genie, how the Agile Manifesto was created and the role Kent played in this. How and why Kent created extreme programming and why Grady Booch played a role in the naming of this methodology, how TDD started and how it's relevant for AI tools and many more topics. If you're interested in the decades-long evolution of software engineering field through the eyes of a hands-on coder, this episode is for you. Subscribing on YouTube and your favorite podcast player greatly helps more people discover this podcast.

If you enjoy this show, thanks for doing so. All right, so Kent, welcome to the podcast. It's great to be chatting again. Gerge. It's so good to talk to you. again. Yeah, and I just wanted to ask, like, what have you been up to recently? Because, you know, like last time we talked, you just finished tidy first. You were actually signed this book when we were in San Francisco. I actually have it here, which is very nice. You were

in the middle of writing it, but this was more than a year ago. Let's keep being busy these days. I have been very, very busy. So I'm working on a follow-up called Tidy Together about software design and teamwork that digs also digs another layer deeper into the theory of software design that's been cooking along and then about the last four weeks maybe I have been I don't call it vibe coding because I care what the code looks like because if I don't care what the code I mean I wish I didn't have to but if I don't care what the code looks like then the genie just can't make heads or tails of it because of the kind of projects I'm working on. So I'm spending six, eight, ten hours a day, sometimes more programming.

In 50 years of programming, this is by far the most fun I've ever had. It's just last. You're not like paid by like some tool to say this. I'm open to that. But yeah, I'm not a spokesmodel. I have had Augment as a sponsor on my newsletter, so full disclosure, but I'm trying all of the tools. Because right now, nobody knows what process is going to work best. Nobody knows anything.

We should all be trying all the things that we can imagine, and then the truth will emerge out of all that. So that's what I'm doing. This episode is brought to you by Sonar, the creators of Sonar Cube, the industry standard for introgated code quality and code security that is trusted by over 7 million developers at 400,000 organizations around the world. Human written or AI generated, SonarCube reviews all code and provides actionable code intelligence that developers can use to improve quality and security early in the development process. Sonar recently introduced Sonar Cube advanced security, enhancing Sonar's core security capabilities with software composition analysis and advanced

static application security testing. With advanced security, development teams can identify identify vulnerabilities in third-party dependencies, ensure license compliance, and generate software bills of materials. It's no wonder that SonarCube has been rated the best data code analysis tool for five years running. So join millions of developers from organizations like Microsoft, Nvidia, Mercedes-Benz, Johnson & and Johnson and eBay, and supercharge your developers to build better, faster, with Sonar. Visit SonarSource.com slash pragmatic security to learn more.

If you want to build a great product, you have to ship quickly. But how do you know what works? More importantly, how do you avoid shipping things that don't work? The answer, Statsig. Statsic is a unified platform for flags, analytics, experiments, and more, combining 5 plus products into a single platform with a unified set of data. Here's how it works. First, Statsc helps you ship a feature via feature flag or config.

Then, it measures how it's working, from alerts and errors, to replace the people using that feature to measurement of top line impact. Then you get your analytics, user account metrics, and dashboards to track your progress over time, all linked to the stuff you ship. Even better, Statsic is incredibly affordable. With the super generous frees here,

a startup program with $50,000 of free credits and custom plans to help you consolidate your existing spend on flags, analytics, or AB testing tools. To get started, go to Statsic.com slash pragmatic. That is S-T-A-T-S-I-G-com slash pragmatic. Happy building. Tell me, so in your news letter, is like I've been following you write these like bite size updates which is really nice

so they arrive in my inbox of your thinking what you're trying out so I know you've been doing this for a few months and it comes across that you're having fun but can you tell me a little bit of like you know it's a big one like from 50 years you've been coding for a long time what is making it fun and what is this genie you you've said this before and it's an interesting way to think about it there's a kind of wishful fulfillment I I wish that interlis had a function called the D whim, do what I mean, and you'd send it some code, and then it would send back code that did what you actually meant. And it didn't work very well, but that was the metaphor. And people want that to be true of coding agents. And right now, anyway, that is not the truth. They will not do

what you mean. They have their own agenda. And the best analogy I could find is a genie. It grants you wishes and then you wish for something and then you get it, but it's not what you actually wanted. And sometimes it even seems like the agent kind of has it in for you. If you're going to make me do all those work, I'm just going to delete all your tests and pretend I'm finished. Ha, ha, ha, ha. You know, and there are some good things about what the genie does that's not what I ask it to do. Like, I'll, I'll implement, I'll say, oh, go implement. a stress tester. One of my projects is implementing a B-plus tree as a basic data structure.

And I said, oh, write a stress tester for this. And it went and wrote a whole bunch of stuff that I wouldn't have thought of or maybe eventually would have thought to ask for. And it was cool that it was there. And that part's fine. but this morning, when I was working on my server small talk, and it just completely misinterpreted what I wanted it to do next, went off, made a bunch of assumptions,

implemented a bunch of stuff, broke a bunch of tests, and it wasn't at all what I wanted. And so I want to find the metaphor that captures this dynamic of, I think I know what I want, I say it, And what I get is seemingly sometimes exactly what I want. And sometimes it's not and in a kind of perverse way. I like the genie analogy because right like in this and the these stories, a lot of the story,

genie stories are someone, you know, like the prince or whoever grants says a wish. Like I want to be rich. And the wish is granted in this like unexpected way. Usually that's with the cartoons and then make it fun. It's kind of true, but there's all the constraints that he or she forgot to specify. Correct. And you're seeing the same thing.

By the way, when you say the genie, which tools are we talking about? Is it the agentic coding tools, the ID auto-complete, that kind of stuff? I'm using the agentic tools, which means that you give it a prompt, and it goes and does a bunch of stuff without asking permission until it thinks it's finished. except his ideas of finished and mine are not the same sometimes i slow it down so that it's like no no before you mess things up tell me what you're about to do and then i'll approve it but then it feels like a rat in the pellet is like there's just a run button and i have to click it every time and i click it and it's it is dopamine rush because it's this is exactly like a slot machine you've got

intermittent reinforcement, you've got negative outcomes and positive outcomes, and they're not, I mean, the distribution is fairly random seemingly. So it's literally an addictive loop to have it. You say, go do this thing. And then sometimes it's just magic. You know, I had a big design mess that a previous agent had made in my small dog virtual machine. I'm like, oh, I'm going to have to slog through this and take a week to do it because one of the agents wasn't able to do it at all. Went to another one, said, hey, I want to use this interface instead of this pointer to a struct. And there was, and it was finished. Oh, I was over the moon. It just felt so good. But then the next thing I asked it to do, I say, well, here's a set of test cases.

and I didn't really look at the code and a couple hours later, I look at the code and it's just a lookup table. It says, if this is the input string, here's the output string, and this is the input string, and I erase, oh, it's furious. God damn it.

I erased it. I said, don't ever do anything like that again. Oh, I'm sorry, boss. You know, it's good at being obsequious when it knows it's about to be unplugged. And an hour later, the lookup table was back. And I'm just, if I had hair, be tearing it out. Oh my goodness. But all of that goes into this very addictive. Oh, I just, you know,

I'm walking, I'm walking to bed at night and I walk back at my computer. I'm like, I could do one more prompt. Or if I go out, you know, I go out for a walk or go out to lunch, I'm like, well, let me, let me start. Let me, what's a prompt that would take, you know, an hour? Because I don't want to waste the hour. Yeah. Not having it do its thing for me. It's a completely new world. Here's the beauty of it. I can think really big thoughts. I can have insanely ambitious ideas, which I have had for a long time. I just, you know, at some point, probably 20 years ago, I just went, but I'm going to have to figure out NPM, you know, package management and there'll be packaged circular dependency, blah, blah, blah, blah, blah, and somebody's going to write some tool.

that does stuff in a stupid way. I'm just going to have to deal with it. And then along comes the genie. And you can go, hey, it's a circular dependency. Smash all this stuff together. There, there I did it. Oh, oh, wow. Okay, now what parts can you pull out?

Oh, this and this and this. Oh, okay. So you can think really big thoughts And the leverage of having those big thoughts is just suddenly expanded enormously. I had this tweet, whatever, two years ago where I said 90% of my skills just went to $0.00. And 10% of my skills just went up 1,000x. And this is exactly what I'm talking about. So having a vision, being able to set milestones towards that vision,

keeping track of a design to maintain the levels or control the levels of complexity, as you go forward. Those are hugely leveraged skills now compared to I know where to put the ampersands and the stars and the brackets in rust. You know, I'm programming in every language under the sun and I just kind of don't care. I'm learning by osmosis. I'm learning about the languages, but, you know, and I was a language guy. I loved languages and the details of the languages and it just kind of doesn't matter so much anymore. Yeah, so tell me about that. So like for, you know, because you've been programming for like, what, 50 years, right?

Yeah, yeah. Yesterday during that O'Reilly thing, I blurted that out and I went, oh, crap, it's probably more like 52, but yes. So like you picked up a lot of languages in the past. And, you know, like to me, one of the traits of a developer up to now has been how quickly they learn languages because, you know, I learned a couple, probably not as many as you, but after a while it gets easier and easier and maybe a little bit more kind of annoying because they're similar, you know, once, I mean, you know, there's differences with the declarative

languages or, you know, like, I mean, you know, it was small talk and Java is a bit different, but outside of that, it's not much. So before, you know, as you were on your like, you know, like year 30 or 40, how did your attitude change towards learning new stuff, just honestly? And then how did this change it? So I was in love with small talk absolutely emotionally attached to it. Still I am when I get a chance to program in small talk. I do it and I really enjoy it. That sense of caring about a language certainly went away because my heart had been broken too many times. And the desire to go deep on a language also like, oh, yeah, you know, Learning the memory layouts of structs, I find whatever.

There's just a handful of good ways to do it and a whole bunch of bad ways to do it. And as long as this isn't one of the bad ways, I don't care. There are genuinely new language constructs, like non-nillable variables that I appreciate, say things that I want to be able to express. But the emotional attachment, the, I'm a Java guy, I'm a closure guy, I'm a, the Vech. It used to be a thing, like maybe 10, 20 years ago, maybe today, but not as big as it used to. Well, I think people still want to be part of something larger. And to be fair, an emotional connection helps me be smarter.

But I just, I can't be the us and them stuff I'm so tired of. Oh, you're one of those scale of people. Well, we're programmers and we're writing programs, and we should. should be kind to each other and beyond that. Yeah. And now that I have the genie handling the mundane details of it, I start projects in languages I've never used just to see what that language is like. What languages have you play around with?

In the last month, Swift, Go, a bunch in Go, Rust, Haskell, C++. That one didn't last very long. JavaScript and and the genies are actually good at writing small talk, which I was like, oh, wow. Please, I hope. No, but they write syntactically correct, semantically correct, not worse quality than other languages code in small talk. What kind of projects have you taken on? You said, like, these are like a lot more ambitious than before you would have attempted. Yeah. So the big one, the one that I'm having the most fun with is a server small talk, where the intention is to have a small talk that is persistent, transactional, so you can have transactions that commit and abort. So it's kind of database-ish parallel so that you can run a bunch of threads. or on the same CPU,

or you can run larger grain parallelism across machines and operates with gojillion bytes of data. I wanted to circle back a little bit, 20 plus years into the past. So there's this thing, the manifesto for Agile Software Development. I don't need to show this to you, but in 2001, this was huge.

I still remember when I had my first job around 2008 at work, we would look at it, debate it. You know, there were like all sorts of things around Instagram. And one thing that is very striking is you are the first person on here, I guess, because it's alphabetical order based on. It is alphabetical order. So, yeah. Thank you for confirming that.

But it is Beck et al to my never-ending delight. How did it happen? And how are you even involved? How much time do you have? So there had been a series of workshops about the future of software methodology. The prevailing wisdom from when I was in school was entirely waterfall, which, by the way, go read the original Winston Roy's paper where it says, here's the way of looking at it. there's this analysis and design and implementation and tests. And nobody would ever do that.

That's a stupid idea. Instead, there would be feedback loops and you'd be doing all of these. But this is a power of a metaphor. People looked at that, oh, four steps and one after the other and then I'm finished. So that was the conventional wisdom. And there were a bunch of us working in different ways. on alternatives to that because it just flies in the face of economics, humanity, information theory, project managers to take your pick. So there were a bunch of us working on alternatives

to that. And we would get together and talk about those alternatives probably for three, four or five years maybe leading up to 2001. So that particular meeting was the culmination of a long series of these meetings. I remember the first one I got invited to, which was also at the snowboard resort in Utah. Martin Fowler, I knew Martin's name, but I'd never met him. And I instantly fell in love with him when he introduced himself. He said, hi, my name's Martin Fowler. And I'm the only person at this table I've never heard of. And that began a long and fruitful

friendship. So we were talking at some point it was clear we had the scrum people, we had the extreme programming people, we had DSDM, feature

driven development. There were all these kind of niches, and we We were all stirring up a lot of interest, XP the most at that point. It was kind of in a crossing the chasm sense. If we wanted to reach the early majority, the innovators were already doing our stuff and being very successful with it.

But if we wanted to reach the early majority, again, go back and highly recommend reading, crossing the chasm, or at least having Claude explain it to you. Oh my God, Gurgai, isn't that fun? like somebody can just say oh eigenvalues blah blah blah I'm instead of going uh you know another concept i'm like hey clod explain eigenvalues to me as if i'm a i'm a bright eight-year-old and blah blah blah and 20 minutes later like oh i understand anyway so have clad explain crossing the chasm if you don't want to go read the book the book is worthwhile but uh anyway we needed a way to reach the the

the early majority. So it was time to, and this is straight out of the book, to have an industry standard, some kind of consortium, makes it seem less risky. And so that's how we came together. We'd had a prep meeting for this on the Hurtigruten, which sails up and down the coast of Norway. Okay. And we had a workshop in Oslo. We flew up to the tip of Norway, took this ferry slash cruise ship down and had long conversations on the ship. And that's kind of set up the 2001 meeting. So it was in the air for sure.

the switch from phased oriented development to something where there's a lot more feedback and a lot more switching between activities where you treat analysis, design, implementation, testing, monitoring, refinement as activities that all happen at the same time or in rapid, rapid succession. So that's the big shift. It's this. Are the phases like this? Are they like this? Slice, slice, slice, slice, slice, slice, slice through time.

And so that's how that all came about. I was not happy with the word agile. Oh, really? Because it's too attractive. Nobody doesn't want to be agile. For my sins, I'm a Tottenham Hotspurs fan from high school. And you can't change. I understand that.

But like, I'm willing to own that to be part of that, even though it comes with some significant downsides when you tell people you're a Spurs fan. Agile? Everybody wants to be agile. So everybody's going to say they're agile, even if they're working exactly counter, like every single one of these items. Yeah, I remember when I actually joined JPMorgan back in 2011, I think, and they were saying, oh, we're very agile. We like, you know, we follow the scrum and we also follow the manifesto.

And I was like, okay, cool. And then so when I arrived, we had a team meeting, which was, you know, good, a stand-up. It took for a long time. It took like two hours. But what we had, and then the next day, we were supposed to have one, but we were like, oh, no, it's canceled.

The next day it was canceled. And for the next two weeks, they were always canceled because it wasn't. And then we had, you know, another two-hour meeting. And I was like, hold on. Like, we're, like, even in the terms of the planning or just talking, we're not No, no, no, we are agile.

Like, we are, we are hearing the feedback. We're just not acting on it. And as you said, like, they were convinced. And, you know, up at the highest top at the time, like the whoever was the head of technology, they kept repeating how we are so agile. We are so, we are following whatever this is. And I think they meant it, by the way. I don't think they knew that they were aligned.

But as you said, I think it's only now that I realize that maybe you're right. Maybe that word was. What word might have you chosen? Obviously, we're not going to change the past, but like, did you ever think about what might have been an alternative? Sure, I had my pick at the time. So Extreme was big pluses and minuses, both to that word. But it definitely, if you don't do the work to be an extreme programmer, you're never going to claim that you are. Just it comes with too many downsides.

At the time, and by the way, for that meeting, I was sick as a dog. I had a massive sinus infection. I was on all kinds of drugs. I hardly remember any of it. There's one word in the whole manifesto that I added in the 12 principles. It talks about interacting daily. And that word daily, that was my word. That was my contribution to the whole thing and the rest of it.

It's kind of a blur. But the word I was pushing at that meeting was conversational, where this isn't the monologue, it's a dialogue, and we do some stuff and we see how it goes. And we do some stuff and we see how it goes. It's not sexy. It's not got a lot of pizzazz to it. I understand why it wasn't accepted. But the dilution of that word agile was perfectly predictable back then. And then can you tell me on how, what was the reception of the community? So it sounds like it was pretty impressive for a few years, like this group caught together and really. Yeah, we were clearly touching a nerve. So when XP really blew up in 98, 99, that was just huge. Can we just talk about XP for listeners who might not be familiar with XP? Because it used to be more popular than it is now.

And you are attributed as the creator. of it, at least on Wikipedia. So can you tell us what XP is and how it came along and how how you became affiliated with it or how you created it? So I'd heard this advice about waterfally stuff and how, you know, grownups specify exactly what their system's going to do and then they just implement it and then that never works. And so we should specify better. Blah, blah, blah. And I disagreed with it. So I started consulting and I was primarily technical consultant. I knew about performance tuning and, you know, the bit twiddling and that kind of at that level. Then people would ask me for advice about project management. I remember one time

I went to a project who was all the most senior people in the organization, like the four most senior engineers were all working on this critical thing, except that their offices were in the corner of this big square building. And I said, you know, I mean, we could talk about the performance of your system, but really, you need to find a place to sit together. And I came back a month later and it was night and day. And I had just told them to rearrange the furniture. And I went, oh, okay. Maybe my only leverage point isn't knowing all the bits and bites.

Maybe there's higher leverage. So I started thinking about more and more of the context of development. And by the way, paying attention when you sit together of how you sit together, the lighting, the acoustics, the furniture, what kind of behaviors that encourages and discourages? Huge leverage in that. And just nobody seems to be paying attention to it. Anyway, so I was giving more and more advice about how projects should go. I was going to go work with a project at, probably shouldn't say, but a fintech company. And I knew I was going to tell them to write automated tests because I had been doing all these experiments with automated testing as a programmer.

Well, how are they going to write the tests? So in a panic Sunday before I left Monday morning, I wrote the first testing framework of that, of that. X unit style in small talk and handed it to them and a month later I went back and they said okay well what do you do when you've got more than a thousand tests I'm like wow what really took off yeah it just took off I've been paying attention to this kind of processy stuff and went to a project at Chrysler which was floundering turned it around but I kind of just took everything that I knew that worked well and tried to crank the knobs up to 11. And then discard all the other stuff and just to see what happened. It couldn't be worse than

guaranteed failing. So then I started talking to other people about, well, I'm doing this, there's this project and we're doing this crazy stuff. We got these three week iterations and we're ready to deploy every three weeks. Crazy stuff, man. And the programmers are writing tests and everybody's pairing and the customers telling us what features they want next and that's what we're implementing every three weeks and da-da-da-da-da-da-da. And I got tired of saying the in the style of this project I've been talking about that I'm so excited about. That's a very long phrase. So I'm like, what do we call it? What do we call it? What do we call it? And I wanted to pick a word and Grady Booch is a friend of mine, but I can also pick on them a little bit. I wanted to

pick a word that Grady Booch would never say that he was doing. Because that was the competition. Like, I didn't have a marketing budget. I didn't have any money. I didn't have that kind of notoriety. I didn't have that corporate backing. So if I was going to make any kind of impact, I had to be a little bit outrageous. And so I picked that, you know, extreme sports were coming up then.

And I picked that metaphor. And it's actually a good metaphor because extreme. Athletes are the best prepared, or they're dead. Those are your two options. Or both. Yeah. And so I picked that metaphor and used it and started talking about it. And remember, 99, so the dot-com thing is about to explode and everybody's looking at.

When AMP was big, it was huge, right? There was the music, the MB3 player. Napster and the dot com. Webband was probably not even founded like that, right? No, no, not yet. But people looked at the books and the waterfally stuff and they're like 18 months. This is all going to be over in 18 months. Whatever are we going to do?

So into that desperate yearning need, here comes XP and says, yeah, it's okay. There's a structure to it. There's predictability to it. there's feedback. You'll get results sooner and longer if you work in this style. And because people so desperately wanted something kind of like that, then it just exploded from there. And then what is XP, right?

Like I know there's parts of it that is pairing and you said getting feedback. But what is the elevator pitch of like, all right, here's what XP is at a high level? Here we have figuring out what to do, figuring out the structure that will let us do it, implementing the features, and making sure they work as expected. That's it. That's it, really. So now we're going to slice time really fine, and we're going to do a little bit of all of those activities in every slice. Okay.

So pairing is not mandated in XP. Mandated is the wrong metaphor. I'll tell you, sorry about pairing. The first XP team, I said, you know, we're going to pair. I kind of gave them a list of the commandments, but I wasn't there all the time. And about six months in, they came back and they said, you know what? We're giving our customer working software every three weeks. And every once in a while, Marie finds a bug.

So we collected all the bugs that Marie found, and we said, what is there, is there any pattern here? Every single bug that was found post-development was written by somebody working solo. Uh-huh. Every single one. Think about the converse. Yep. There will be no reported defects from production if you pair. How cool is that?

So mandated? No. Strongly recommended. Not even. Experiment. You do you. But pay attention. People will like stumble along, well, this is just how I program and have horrible problems and just keep doing it and keep doing it.

Because this is just how I program. Don't do that. Pay attention. If you want the benefits of continuously designing or continuously validating or continuously implementing or continuously implementing or continuously interacting with your customers, you can have those benefits, but then you're going to have to change the way that you work. So mandate is just not even the right way. It's an empirical process. Yeah. Yeah.

So like some teams decided that this is a good way for them to work. Yeah, which is great. People will come up to me and say, oh, you know, I don't do TDD. I'm like, why do I care? Like if you're happy with your defect density, if you're happy with the feedback you're getting on your design choices, good for you. But if you're unhappy and you want to tell me that, well, that's just how things are, uh-uh. So let's talk about TDD. How did you get involved in TD or how did TD evolve and where did it come?

come from because we had XP, I understand, first. No, no, no, TD came first. Oh, TDD came first. So I was a weird child. That'll come as a big shock to you. My dad was a programmer. He would bring home programming books. This is in the early 70s.

And I would read them cover to cover, and I didn't understand anything. But I was just obsessed with this machine, this intricate mechanism and how's it work and so on. And one of the books said, here's how you develop a tape-to-tape application. So tape-to-tape was the old way of putting business applications together. You wouldn't have one monolithic program. You'd take an input tape. You'd write a program that would transform it. Now you take the output tape from that, physically move it to the input side, run another program that would generate another tape, and, and-and-and. And so there would be this. big web of these of these programs no shared mutable state wow it's like it's very modern in some kind of

ways but okay so said here's how you implement one of these things you take a real input tape and you manually type in the output tape that you expect to get from that input tape now you write the output tape you run the program you write the output tape and then you compare the actual output with the expected output. So I read that as a, I don't know, eight, 10, 12 year old something. Then I wrote S unit, as I said, to help a client write some tests. And then just one of these crazy conceptual blending ideas, I went, oh, I have this testing framework. I'm used to writing tests for code that already exists. I remember this tape-to-ta-tape idea.

What if I typed in the expected values before I wrote the code? And I literally laughed out loud. It was such an absurd idea. I thought, all right, all right. Well, let me just try it. So I tried it on stack. And I tend to be an anxious person. I got a lot of worries.

And programming is a constant source of anxiety for me. Because, like, what did I forget? Oh, yeah. like what did I break. Ugh. So I had this testing framework. I had this idea. I applied it to stack.

I said, well, what's the first, what's the first test? Push and then pop. Whatever I pop is what I pushed. Okay. So I wrote it. And because I was writing in Smalltalk, which is very forgiving for the order of your workflow, it doesn't, you didn't type in a test class that doesn't exist.

It'll happily try and execute it and fail, but it's going to try because you're the programmer. Maybe you know better. It said, well, stack doesn't exist. I'm like, oh, well, let's create stack. But you know what? I'm just going to create the absolute least I need. We're just going to crank this all the way up to 11. I'm just going to create stack and I'm not going to do anything else.

And then I get a new error from the test. Oh, I don't have an operation push. I'm like, oh, okay. Well, how am I going to implement? Then I look at stack. I'm like, oh, how do I implement push? Okay, I do that. Oh, there's no operation called pop. Oh, okay. Let me go look and how I finished it. I had this list of test cases before I started. Push and then pop. Push two things. Pop them. You get them in the right order. Is empty. Pop of an empty stack throws an exception. Okay, cool. And I went through my list and I

tick all the boxes. I probably came up with one or two corner cases along the way. I ticked those off too. And I, where's the anxiety? Is gone? This works. This abs. Like, I'm certain this works. I can't think of another test case that isn't just going to pass. And if I'm the least bit worried, I just type in that next test case and then I'm not worried anymore. Oh my God. It's a transformed the emotional experience of programming for me. I never heard this take, although, like, I can relate, though, like, because, like, I remember that when we did TDD and on this team, we did it for the stuff that we're unsure, it was, like, unclear.

And by doing the tests first, we had to specify, we had to be clear. And it was stuff where there was a bunch of edge cases. But it never, until now we talked, it never occurred to me like this. You can also make technical arguments for TDD about defect density, about how you get quick feedback on your API choices, about how it enables implementation, design evolution when you have a series of tests. Like, I get, yes, we can talk about all of that stuff rationally. But just the savings on anti-anxiety meds alone pays for itself. This episode is brought to you by Augment Code. You're a professional software engineer, vibes will not cut it.

Augment Code is the AI assistant built for real engineering teams. It ingests your entire repo, millions of lines, tens of thousands of files, so every suggestion lands in context and keeps you in flow. With Augment's new remote agent, Q apparel tasks, like buck fixes, features and refractures, close your laptop, and return to Ready for Review Poll requests. Where other tools stall, Augment Code sprints. Augment Code never trains or sells your code

so your team's intellectual property stays yours. And you don't have to switch tooling. Keep using VSCode JetBrains, Android Studio, or even VIM. Don't hire an AI for vibes. Get the agent that knows you and your code base best. Start your 14-day free trial at Augmentcode.com slash pragmatic. And so what is your take when we discuss with John Osterhout? His biggest criticism slash feedback, or let me put it, why he doesn't really believe that it's a fit maybe for the things that he does is that he feels that from an architecture perspective, it doesn't help create a nice architecture at front because you're now focusing on the detail.

I think this is roughly what he summarized. I might have gotten it wrong. And I'm sure this is not the first time you've heard some feedback. like this. It's a choice, though. His statement in that in that interview with you was that there's no place in TD for design. And he's just flat out wrong. That's a choice. As a practitioner, I'm bouncing between levels of abstraction all the time. I'm thinking, let's get this next test case running. I'm thinking, why is it hard to get the next test case running? I'm thinking, what should the design be so that getting the next case running would be easier?

I'm thinking, when should I, if I have an idea for that, when should I introduce it now or later? I'm thinking, when I introduce it, what are the slices? Is there a little bit that I can do right now that will make things a little bit better? Do I have to do this in bigger chunks? Like, I'm thinking all that stuff. So if you think of TDD as red to green to red to green, in the transition is when you go from red to green, you change the implementation, and now you pass the test.

And when you go from green to red, you write a new test. If that's the entire cycle, no, there's no place in that for design. That's just not how it's practiced. When I write a test, before I write the test, I have a moment of design. what should the API for this functionality mean? Yeah, I see that. So I'm making design decisions about the interface without having an implementation.

I get to decide what interface I want and then we'll work out the details of the implementation later. Then making it green, like pretty much I just want, I hate having a red test. So I want to get to green relatively quickly, at which point I have a moan of breath because the anxiety's gone, right? You're a musician too, right? I'm not a musician, but I have done red queen test and I know what it feels. You have this sense of tension and release. Yeah. Once the tension of a red test is released and you have green, now I'm free to think all those thoughts of like, yeah, but this isn't going to work.

for these test cases or I could generalize this current implementation to also handle a bunch of other test cases correctly or I could rearrange the implementation because I know I'm going to have five more tests like this and I'm thinking about design but in situ in the context of running code and anytime I feel the least bit anxious about any of this just press a button and it's either red or green. And if it's red, then my next job is to get it to green. And if it's green, my next job is to breathe and think these larger thoughts. So, like, I can understand if you compress TDD to red green, red green, red green, red green, red green, red green, red green, then no, there's no space in there for design, but it's just not how it's practiced. Yeah. No, I see, like, it's a tool,

right? Then you use it here and there. You step out. You go back in. There was a time where we did TDD, right, for a while. And then it just felt a little bit too much effort, especially when I knew what I was doing. And so what I would do, like, I really liked the red and green. But what I would do and what I would do and what I would do and what I would do and what I would do, is I knew the implementation that I wanted. So I would do the implementation. Then I would write a test. I would kind of like a little bit like, you know, maybe even, I might even just double check out and launch it in the, if it was a webpage, launch it a web page, it kind of look good as how I wanted to be. And then I'll be like, okay, let me shrunt down my brain a little bit. Let me write a test against this. And now

that test would have normally passed and what I would do I would either run and pass it but then I would be like okay I want to see it break so I would go back to the code and I would maybe make a change that I knew would make it break I would run the test this red

I'm like okay so because what I didn't want to do because I've seen it before is my test and it's not testing anything so I would kind of do this like write a test after but then do a red green to make sure that I am testing the right thing and I would still design to test but what is your take on

on this. Am I kind of doing? And the reason I did, I felt because I knew the implementation, I just wanted to get the implementation done. It's already decided I felt I would be holding back if I started with the test. Yeah, it's an interesting assumption. I can understand why you would make that assumption that you already know what the implementation is going to be. And the writer, the more correct you are in that assumption, the less value there is to have the test first. I'm always going to bet when I'm going to learn things. This is the most ignorant I'm ever going to be today. Fair. I'm going to be more experienced tomorrow. Now, as a 50-year programmer, maybe I'll forget some of the things, but it's a separate set of issues. Oh, yeah.

So I'm going to assume I'm going to learn and I'm going to assume that things are going to change. The more of those assumptions hold true, the more I have to. learn and the more things are going to change, the less commitment I want to make right now and the more I want to defer commitments to the future. It is a general principle. This is true about cooking and dating and everything. The more you can predict, the bigger the jumps you can make. I always want to bet. I love that moment of discovery. I love the moment of I knew how this was going to turn out. And then I, and then I do and I do and I'm like, oh, crap, there's a completely different better way to implement this that I, I love that moment. And I want to induce that as much as possible.

And that's not how I started out. No, I started out wandering around, imagining the whole implementation of my head. I can remember doing this on the University of Oregon campus at night, wandering around in the fog, because it was always foggy when it wasn't raining, imagining big, big programs in my head. And then if I could just make that actually real

and make that work, then that was the process. And you were all dreaming of them as well. I remember. Like, I would dream with them as well sometimes. Yeah, yeah, yeah. And what I discovered is that's so limiting to me

because it slows down my ability to learn. So John was talking about building a new network stack into Linux kernel. Yeah, yeah. He's doing that. What a cool project. Super cool. Awesome. I would love to get walked through that whole thing.

If you had a concept in mind of exactly how to implement it and you knew what the input output behavior was, you knew what you wanted to observe and that wasn't going to change, then sure, just go implement it. But the more mistakes you make, the more learning, the more things are going to change in unpredictable ways, the less commitment you want to make now and the more you want to defer commitment to the future. I like that. One thought I did have recently, as, you know, AI tools have come around, how do you think TDD might or might not fit into when you're working?

with an AI agent, what you're doing right now, right? Because it's interesting, the ambition of what you can do and also just a natural workflow. How do you think about them? Do you think there would ever be a fit? Do you think we might actually slow down and start writing with, like, well, what we expect and have and then have the agent pass it? Because it could be a good workflow. I just haven't seen anyone really do it. That's how I work all the time. So when you work with your genie, you start with the test. It's not that simple. I oftentimes communicate things the genie missed in terms of tests. Mm-hmm.

So today I was working on the small talk parser, and it said, well, if I get this string is input, then I get this syntax tree's output. I'm like, no, no, no, no, no, no, completely wrong. This, that's the right, correct string is input, and the output is this. then off it goes, oh, I see the problem, blah, blah, blah, blah, blah, blah. Oh, no, no, that wasn't it. I see the problem. Blah, blah, blah, blah, blah, blah, no, that's not it.

I see the problem. I'll just change the test. No, stop it. This is what you said, that it can change test and delete tests. Oh, yeah. If I just removed that line from the tests, then everything would work. No, you can't do that because I'm telling you the expected value. I really want an immutable.

I want an immutable annotation that says, no, no, this is correct. And if you ever change this, you'll awaken in darkness forever. So that's the punishment. You'll still run. I'll still feed electrons in there, but no bits, no information.

You're just going to be in the dark forever. Got that? So, yeah, I definitely use tests. The genie is prone to making, decisions that cause disruption at a distance is not good at reducing coupling and increasing cohesion. Not at all. Explicitly told what to do, it can sometimes implement it. But in general, it has no taste, no sense of design. So I have a big bunch of tests. I mean, they run in 300 milliseconds because, duh. Of course you want your tests to run.

and lickety split. So those tests can be run all the time to catch the genie accidentally, breaking things. I think he's doing on purpose. No, that's why Jeannie is the perfect metaphor. It's like, yes, I will grant your wish, but I'm still pissed off about being stuck in this bottle in the desert for a millennia. And this also strikes me that once we have the tools,

or maybe we have it today with MCP or some other things to allow. this agent to run the test. Like, it just feels to me that, you know, the teams are people who are doing these practices, which are sensible and obviously, like, and you can move faster. In fact, you probably move faster. It might help you integrate these agents better.

You know, if you have the rule of do not change a test, always run the test before or after you made the change. And if it doesn't pass, fix it, right? Or something like that. Like, I'm still waiting for more people to discover this because I wonder if we're going to go back to, you know, discovering, you know, things that were, we already were popularizing or you were popularizing in the 2000s.

People should be experimenting. Try all the things because we just don't know. The whole landscape of what's cheap and what's expensive has all just shifted. Things that we didn't do because we assumed they were going to be expensive or hard just got ridiculously cheap. Like what would you do if I don't know, cars were free? Okay, things are going to be different, but what are the second and third order effects? No, like nobody can predict that. So we just have to be trying stuff.

I like that. And this brings me to another interesting topic and story that you had. You told this story a long, long time ago in the Suffering Daily podcast, but I don't think anyone has heard it about how experimenting can be interesting. So when you joined Facebook, was it in 2011? 2011. That was the peak where TDD was very well known. industry, that was around the time where my team experimented with it. And as far as I know,

whenever I talked with people on meetups, people are trying it, doing it. It was kind of accepted that you should be doing some level of unit testing, maybe TDD, maybe not TD. And you shared the story that you joined Facebook and then you wanted to hold a class on TD. And what happened? And how was Facebook doing their own testing, actually? Did they use TD or did they do something else? Yes. So I joined, and I was a little panicked, like hugely successful, growing fast, a lot of very smart, very confident engineers. You know, have I lost it? Can I hang? I thought, I'll teach a class in TDD. So there was a hackathon, and part of the hackathon is people could offer classes. And so I offered a class on TDD. And in the sign-up sheet, I went and looked later. Yes, indeed, there was a class on advanced Excel techniques that was full and they had a waiting list. And there was a class on Argentinian tango right after mine on the list.

And it was full and they had a waiting list. And nobody signed up for the TD class. Wow. And I said, you know, you know what, I'm going to have to forget everything I know about software engineering. I'm just going to wipe the slate clean and I'm going to just monkey see, monkey do. I'm going to copy what I see the people around me doing and I'm going to see how that works out. What I discovered through that process, one, socially it's not a good look to come into somebody else's house and start arranging the furniture. Just don't just don't do that.

But two, I learned powerful lessons. programmers at Facebook at the time. I'm not going to say meta. I'm going to say Facebook and Facebook at that time. Because it was a very different place when I left in 2017. But in 2011, programmers took responsibility for their code very seriously because they were the ones who were going to get woken in the night. And there was an ops team,

but the job of the ops team was to make sure the programmers felt the pain of their own mistakes. And they did. And it was very effective. As a programmer on Facebook the site is pre-mobile, Facebook the site, you had a bunch of different feedback loops. So we were working in PHP. We had our own dev servers. So if I wanted to change from blue to green, I'd just change it. I could look at it seconds later. So we had that feedback loop. We had code reviews, kind of, iffy, but you got some feedback from code reviews. We had internal deployment because everybody was using Facebook all the time for both personal and business stuff, which is his own set of boundary issues, but we'll leave that one to the

side. We had incremental rollouts, not like weekly rollouts. We had smaller daily rollouts, but we had weekly rollouts. And then a bunch of observability. And then we had a social organization that was used to, for example, the first feature I implemented and launched was adding to the relationships type. You could say I'm single, it's complicated, I'm married, and I added civil union and domestic partnership to that list. And it rolled out. It took me too long to do it. I used TDD was a big waste of time. it rolled out, the notifications code broke because there was implicit coupling between the two and

you couldn't find it, but it was there. Somebody else saw the error rate go up, went and fixed it, rolled out a hot fix. I called them up. I'm like, oh, I'm so sorry that you had to do that. It's like, yeah, that's what happens. You know, when things break socially, there was no, there was no boundaries. There was a poster that was very popular there that said nothing at Facebook is somebody else's problem. And everybody acted like that was true. And because of that, if you add all those different feedback loops together, we had a relatively stable, rapidly innovating, and rapidly scaling system all at the same time. The mistakes that actually caused problems, like the calculation of some string, was not a, not a hairy computer science dynamic programming, blah, blah, blah, they could go wrong.

What would go wrong is configuration stuff, the relationship between subsystems, stuff you couldn't write tests for. So writing test for things that didn't break and didn't catch the actual areas. It just didn't make any sense. In that kind of environment with that risk profile, yeah, it didn't make sense. Yeah, and I guess the context that I've heard and, you know, like, correct me if I'm wrong, that Facebook had this super, very unique place, which even is very rare today. They had so many users and code was rolling out live code.

The website is rolling out to so many of them that, and they had such great observability. they still have, that you had live mass testing and you could detect a lot of the things that you cared about because you measured them. You had this layer, and this is what I think a lot of people miss of like, oh, we can operate like Facebook. I mean, you probably can if you have this level of customers or this observability. But if you're like a bank where you have 10 customers, like a JP Morgan, again, the software I wrote was used by seven traders. And they moved about a million or two or three million dollars with each transaction. And they did five of those per day. suddenly, you know, like I had like 35 transactions.

And if, let's just say B test that. Yeah. Well, so there's a, your opportunity that that you had. And Facebook, there were not many sites at the time that did that. And even the ones that had that many customers, they might have not had the, this setup of observability, stage role adults and so on. Even today, I think that they're, the Facebook specifically not meta, but Facebook, as I understand is still the state of the art globally. in terms of how they have. They now have multiple environments, automated rollbacks,

if something degrades, you don't even need to look at it like your, you know, colleague did that. Yeah, feature flags is another important part of that. And it was a lesson I had to learn. And one where code review really helped me, I'd written some code. I thought it looked fine. Somebody said, niz looks a little janky, put it behind a feature flag. I'm like, really?

What? okay okay you know when I was in that headspace of I'm going I'm here to learn if feature flag is what we do then feature flag it and I did and then I realized oh how liberating that is as an implementer who is going to be responsible if you're not going to be responsible who cares like I but also talk about anxiety if I'm if I'm not the responsible person that feels horrible but if you're going to be responsible for whether this code works or not, having a feature flag is just magic. Because you get this sub-deployment deployment. You deploy one software artifact that has multiple modes. And you can go, oh, turn it up a little bit. Whoopsie!

Turn it down. Let's figure out what just went wrong. I worked on the messenger backend for a while. And we would do that. You know, and yeah, you've got, we had one API that was getting called a quadrillion times a week. Wait, how much is a quadrillion? Million billion, yeah. So a million billion.

So like, wow. So like not a thousand billion. Okay, wow. A billion, a trillion, a quadrillion. Okay. Like, I'm used to high numbers. Oh, people would come to Facebook and they're like, oh, yeah, I want to do some user testing. to get a I want to get a hundred people in my experimental group. And I'm like, dude, wrong.

Your experimental, your experimental group is going to be like New Zealand. Oh yeah. I've heard this a lot from Facebook people. It was a perfect, perfect experiment. You know, like, only like a million people. Yeah. Yeah. English speaking. So localization is there. Time zone wise, it's pretty good. That's right. And also Portugal and some other, maybe maybe not a Facebook, Yeah, also a popular one. Relatively small size, but, you know, real testing could happen there. So you worked for six years at Facebook. What is the thing that you, and this was a really exciting time where it was fast growth.

We probably comparable growth to what is happening right now with some of the hottest AI startups and it was also a mobile revolution. So you were there. What was the thing that you liked the most about working there and maybe the one that you kind of disliked the most or didn't really, you didn't really, you know, you know, get along with. Facebook 2011 is a completely different beast than Facebook 2017. Facebook 2011, 2,000 employees, very sparse design and product kind of organization.

It was all experiments and feedback. One of my, one of my big mysteries is here was this site which enabled social interactions at that time. That was the purpose. of it built by people with no social skills whatsoever. Like, how in the world did that happen? Is there some kind of, is there some kind of social wizard, you know, hidden someplace? And people go and they burn incense and give an offering. And the social wizard says, no, here's how you do notifications. The answer is no. It was sheer experimentation. It was just all these people trying all this stuff and the stuff that worked stuck. So it wasn't like people were making better decisions about

how social interactions are best facilitated. They were making random decisions about how social interactions were best facilitated and paying attention and making sure that the ones that actually seemed to work stuck. 2017 Facebook, seven years later, totally different deal. Big design org, big product org, like 15,000 employees, which is, again, much smaller than it is today. A lot more politics, a lot more zero-sum thinking, a lot more. You know, if you wanted to launch a product and it was going to say, I like to longer form content, essays, podcasts, whatever, except the people whose job it was to get more, more likes and comments hated long-form content because it was going to tank their numbers.

So they would fight tooth and nail to make sure that your stuff didn't show up in the newsfeed. Which, like, granted, that was in their best interest. But, yeah, I see what you mean. You know, your short, short-term interest. Yeah, and your horizon as a thinker, the things you can imagine possibly, implementing just gets smaller and smaller and smaller in that kind of world. When I showed up, yeah, you could do anything. It turns out there's a bunch of stuff that you shouldn't do, but we didn't know that.

Sorry about democracy. But yeah, that's what I loved about it was the possibilities at its best, the scale and this feeling that nothing at Facebook is somebody else's problem. Also, daunting, because when you're wearing Facebook swag and grandma comes up to you and starts wagging her finger under your nose because her son, blah, blah, got bullied, whatever. Like, that is your problem. You can't say, well, go talk to the PR department because there isn't one yet. You have to deal with it.

And I did. Yeah, ownership, yeah. And, you know, it comes with some downsides, but it comes with a lot of upsides, too. It feels really good. Feels very significant to be in that kind of environment. By the time I left, yeah, it was micro-optimizations were everywhere. The upside, yeah, was not there. When I got there, the middle managers, best middle managers I'd ever seen in my career. Well, everybody who'd made it to middle management, Facebook in 2011, was sitting on life-changing

equity. They were all, if Facebook had a successful IPO, they were all set for life. And if Facebook, the whole thing, stumbled and fell for whatever reason, they lost that opportunity to be set for life. So they were globally optimizing. You'd talk to a team and they'd say, God, I would love to have you on my team. You know who really needs help, though? So they were like looking out like the team interest, the company interest was on everyone's mind and they were willing to forego, you know, like, okay, I'll hold back hiring or I'll wait. Like, I'd love to have this person, but this other team needs it, let me help them because this

is the right thing to do. For the company as a whole. Yeah. Yeah. And it's not like they were better human. beings than other human beings, but their incentives were sure aligned with that. And just for me, who has a really hard time understanding other human beings, to be around that kind of alignment, that just enables a ton of creativity, a ton of energy for me, I think more and better thoughts.

And I had a hard time operating in the environment. I can piss people off. I don't know if you've noticed this, but, and I did my share of that while I was there. But still the opportunity was there for me to fumble. And, and I, I can live with that. Yeah, I guess by the way, like, I think this might be a reason why startups remain attractive. And, you know, big tech, you know, now Facebook is big tech. They used to be a startup along with, like, all the other big companies, you know, they pay well. They have a brand. They, they give you. They, they give you, your that resume boost, it's easier to get hired afterwards. But in the end, you know, like there will be teams inside of them,

but a lot of them will be, you know, everyone's optimizing for their own thing. Your equity is mostly cash and it's meaningless in terms of the bigger picture. Whereas at a startup, like at Uber, I remember before the IPO, we used to think like that. What is the best thing for Uber? Because we were very much interested. We felt like we were like big enough owners.

So I think this is why, like maybe this is a good thing that startups will all always be able to have this added thing when you're starting out. People have large equity. Even when you're up to like 100 people, it might still be significant enough. And this is, maybe it's not a bad thing that is hard to compete with it. Because imagine if these big companies could. I mean, what would be left of it, right? Like they would optimize the last thing out of everything.

And at least they have to spend more money on it now. Yeah. Yes. Yeah, yeah. Which is more of the value that's created comes back to the people who are creating it. I once talked with a person at a large company. I don't want to name them. They're the travel company, though.

And I was talking with this person about something principal engineer. And I was like, oh, how's the job? It's like, oh, it's absolute mess. It's the monolith is still there after four years. It's another like four years to disassemble. The experiment, like we have experiments everywhere, but they're all messy. I was like, oh, wow, that sounds like not a great. place. He's like, but he's like, look, look, the upside is like, I, my job is secure for five more

years. And this is why pay me the big bucks. So I'm not completely. And it was, you know, like, I guess a good take of like, yes, like, I'm not saying you want to optimize for this, but this is the reality. And that company understood, you know, they pay well, they relocated this person, you know, all, all the benefits. And he actually had his challenges set actually for the next four years because he's worked at this environment, you know, is just one thing after the other. So yeah, it's one of these things. So as closing, I just have some rapid questions, which is like, I'll just, I'll just fire and then you tell me, what is your favorite programming language, although you answer this already. What is your second favorite one

after Small Talk? With JavaScript. JavaScript. Okay, why? It's just Small Talk. Okay. What is your favorite AI tool that you're using right now? Claude. I use it for all kinds of different things. Claude code as well or just Claude? Cloud code under the covers of cursor or Augment or I don't know what RU code is. No, so Cloud code is a different as a command line tool that Claude has. It's an agent of itself.

Like, it's not the model. Have not used, but we'll try it now. After we just try it and just see how it compares. Yeah, I'll wait toward. done talking, though. Yeah. And what is a book that you would recommend, the one that you have not written? We know your books. The one that you

enjoyed. It can be fiction, it can be nonfiction. The timeless way of building by Christopher Alexander. Well, Kent, this was a lot of fun. It was good to reconnect. Oh, yes. Great talking to you. Thanks. I'm just happy to see how much energy, how energized you are with coding. Because I think when I started with some of these souls,

I was like, oh, a bit of a dread, like, oh, what's what they're going to do, et cetera. But the more I use them, I'm not at your level yet. The more I'm also like, this is actually, it does bring a lot of fun and joy back into it and just more ambition. Yep. Yeah. And I think that organizations are going to have to get used to throwing away a lot more code. Because you can try ideas so much more cheaply, you're going to generate 10 times as many artifacts as you used to. But still, only one of them is worth keeping.

but throwing away completed experiments. I almost said failed. Completed experiments needs to be, you get the pat on the head for doing that. Excellent. Eight.

Eight this week, only six late last week. Super. How many of them lasted? Doesn't matter. And getting used to that, I think it's going to be an interesting shift. the companies that have the opportunity that can be explored in that way,

if you get used to just quantity of ideas explored, you're going to have a huge, huge advantage. Yeah, it's going to be changes. So this will be an exciting place to see. So it was great chatting and we'll see where this goes. All right, Gergai, so good to talk to you again. I look forward to talking to you again soon. I really joined Catching Up with Kent,

and it's motivating to see how these AI tools can make programming so much more fun even for someone who's been a coder for decades. You can read more about what Kent is up to on his regular newsletter, Tidy First, which is linked in the show notes below. For a deep dive into Facebook's engineering culture and that analysis on why scrum and agile, with the capital A is no longer that relevant at Big Tech at scaleups, check out the pragmatic engineer deep dives, also linked in the show notes below. If you enjoy this podcast, please just subscribe on your favorite podcast platform and on YouTube.

This helps more people discover the podcast and a special thank you if you leave a rating. Thanks and see you in the next one.