## Intro [00:00] How do you think TDD might or might not fit into when you're working with an AI agent? I often times 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 as output. I'm like, no, no, no, no, no, no. Then off it goes. Oh, I see the problem. 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. 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 cuz duh. So those tests can be run all the time to catch the genie accidentally accidentally breaking things. Ken 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 BCH 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 decadesl long evolution of the 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 the show, thanks for doing so. All right. So, Kent, welcome to the podcast. It's great to be chatting again. Gerge, so good to uh talk to you again. Yeah. And I just wanted to ask like what have you been up to recently cuz you know like last time we talked you just finished Tidy First. You were actually signed this book when we were in in in San Francisco. I actually have it here which is very nice. You were in the middle of of writing it but this was more than a year ago. What's keeping you busy these days? I have been very very busy. So, uh I'm working on a followup called tidy together about software design and ## What Kent has been up to since writing Tidy First [02:27] teamwork that uh 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 cuz I care what the code looks like cuz if I don't care what the code look 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 I'm spending 6 8 10 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 really You're you're you're you're not like paid by like some tool to say this, right? I'm open to that, but uh yeah, I'm not I'm not a spokes model. I have had Augment as a as a sponsor on my newsletter. So, full disclosure, but I I 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 the truths 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 Server, Cloud ID, and Community Build. Sonar helps prevent bugs, code quality, and security issues from reaching production, amplifies developers productivity in concert with AI assistance, and improves the developer experience with streamlined workflows. Sonar analyzes all code regardless of who writes it, your internal team or Gen AI, resulting in more secure, reliable, and maintainable software. Combining Sonar's AI code assurance capability and Sonar Cube with the power of AI coding assistants like GitHub Copilot, Amazon Q developer, and Google Gemini code assist boosts developer productivity and ensures that code meets rigorous quality and security standards. Join over 7 million developers from organizations like IBM, NAZA, Barclays, and Microsoft who use Sonar. Trust your developers. Verify your AI generated code. Visit sonarsource.com/pragmatic to try Sonar Q for free today. That is sonarsource.com/pragmatic. 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, Statig. Static is a unified platform for flags, analytics, experiments, and more. combining five plus products into a single platform with a unified set of data. Here's how it works. First, static helps you ship a feature with a feature flag or config. Then, it measures how it's working from alerts and errors to replays of people using that feature to measurement of topline 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 a super generous freeze tier. a starter 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 stats.com/pragmatic. That is statsig.com/pragmatic. Happy building. Tell me, so in your newsletters, like I I've been following you, you write these like byite-size updates, which is really nice. They they arrive in my inbox of your thinking, what you're trying out. So, I know you've been doing this for for a few months and and it comes across that you're having fun, but can you tell ## Why AI tools are making coding more fun for Kent and why he compares it to a genie [06:05] me a little bit of like, you know, that's 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 you've said this before and it's it's an interesting way to think about it. There's a kind of wish fulfillment. I I I wish that interllisp had a function called the dwim do what I mean and you'd send it some code and then it would send back code that did what you actually meant. Mhm. and it didn't work very well. But that was the that was the metaphor. And people want that to be true of coding agents, right? And right now anyway, that is not the truth. They will not do what you mean. They 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 and sometimes it even seems like the agent kind of has it in for you. If you're going to make me do all this work, I'm just going to delete all your tests and pretend I'm finished. Haha. You know, and 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 uh implementing a B+ tree uh as a basic data structure and it 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 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 the the I want to find the metaphor that that captures this dynamic of I think I know what I want. I say it and what I get is seemingly some sometimes exactly what I want and sometimes it's not and in a kind of perverse way. Mhm. I I like the genie analogy because right like in this in the these stories a lot of the story genie stories are someone you know like the the prince or whoever grants says a wish like I I want to be be rich and the wish is granted in this like unexpected way usually that's you know with the cartoons and then make it fun that it's kind of true but you know there there constraints that he or he or she forgot to specify correct and you you see the same thing by the Wait, when you say the genie like which which tools are we talking about? Is it the agentic coding tools, the ID autocomplete, that kind of stuff? I'm using the agentic code uh tools, which means that you give it a prompt and it goes and do does a bunch of stuff without asking permission and 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. It's like there's just a run button and I have to click it every time. And I click it and it's it is a dopamine rush because it's this is exactly like a slot machine. You got intermittent reinforcement. You got negative outcomes and positive outcomes. And they're not I mean the distribution is is fairly random seemingly. So it it's literally an addictive loop to to have it you you say go do this thing and then sometimes it's just magic. You know I I had a big design mess that a previous agent had had made in my small dog virtual machine. I'm like oh I'm going to have to slog through this and take a take a week to do it because the the 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 uh pointer to a strct." And and there it 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 that and I erase. Oh, I was furious. God damn it. I erased it. I said, "Don't ever do anything like that again." Oh, I'm sorry, boss. Oh, you know, it's good at being obsequious when it knows it's about to be unplugged. And and an hour later, the lookup table was back. And I'm just, if I had hair, I'd 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 by 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, h, but I'm gonna have to figure out npm project, you know, package management, and there'll be package 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, now what parts can you pull out? Oh, this and this and this. Oh, okay. So you you can think really big thoughts and the leverage of having those big thoughts has just suddenly expanded enormously. I had this tweet whatever two years ago where I said 90% of my skills just went to zero dollars and 10% of my skills just went up a,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 uh I know where to put the amperands and the stars and the brackets in Rust. You know, I'm I'm programming in every language under the sun and I just 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 languages and it just kind of doesn't matter so much anymore. Yeah. So, tell me about that. So, like for you because you've been programming for like ## Why Kent says languages don’t matter anymore [13:41] what 50 years, right? Yeah. Yeah. Yesterday during that O'Reilly thing, I I I blurted that out and I went, "Oh crap, it's probably more like 52." But yes, so like you you picked up a lot of languages in in in the past and and you know, like to me, one of the traits of a developer up up to now has been how quickly they learn languages cuz you know, I 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 with the declarative languages or you know like I mean you know with small talk and 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 am when I get a chance to program in small talk. I 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 strcts I yeah fine 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 that say things that I want to be able to express, but but the emotional attachment, the uh I'm a Java guy, I'm a closure guy, I'm a the used to be a thing like maybe 10, 20 years ago, maybe today, but not as big as it used to. Well, I I 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 Scalla people. Well, we're programmers and we're writing programs and we 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 what languages have you played around with in the last month? Uh, 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 I hope." No, but they they write syntactically correct, semantically correct, not worse quality than other languages code in small talk. So what kind of projects have you taken on? You said like these are like a lot more ## Kent’s current project building a small talk server [16:56] ambitious than than before you would have attempted. Yeah. So, I the the big one the the one that's I'm having the most fun with is a uh a server small talk where the intention is to have a small talk that is uh persistent uh transactional so you can have transactions that commit and abort. Um, so it's kind of databaseish parallel so that you can run a a bunch of threads or a on a on the same CPU or you can run larger grain parallelism across machines and operates with good gajillion bytes of of data. I wanted to circle back a little bit, you know, 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 in 2001, this ## How Kent got involved with The Agile Manifesto [17:51] was huge. I still remember uh when I had my first job around like 2008 at work, we would look at it, debate it, you know, there were like all sorts of of things around scrum. And one thing that you know 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 but it is beck at al to my to my neverending delight. How did it happen and and h how how were you even involved? How much time do you have? Um 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 Royce paper where it says here's a way of looking at it. There's this analysis and design and implementation and tests and uh nobody would ever do that. That's a stupid idea. Instead there would be feedback loops and you'd be doing all of the but this is a power of a metaphor. People looked at that oh the 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 it flies in the face of economics, humanity, information theory, project manage, take your pick. So there were a bunch of us working on on alternatives to that. Um and we would get together and talk about those alternatives probably for 3, four, five years maybe leading up to 2001. So that particular meeting was the culmination of uh of a long series of of these meetings. I remember the the first one I got invited to which was also at the snowboard resort in Utah. Martin Fa 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, "Uh, hi, my name is Martin Fowler, and I'm the only person at this table I've never heard [Laughter] of." And that began a a long and fruitful friendship. So, oh, we were talking uh at some point it was clear we had this scrum people, we had the extreme programming people, we had uh DSDM featured driven development. Uh there were all these kind of niche niches and 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 and being very successful with it. But if we wanted to reach the early majority, again, go back and highly recommend uh reading Crossing the Chasm or at least having Claude explain it to you. Oh my god, Gergy, isn't that fun? like somebody can just say uh I en values blah blah blah instead of going you know another concept I I'm like hey Clyde explain IEN values to me as if I'm a I'm a bright eight-year-old and and 20 minutes later like oh I understand anyway so have Claude 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 early majority so it was time to and this is straight out of the book to to have a an industry standard, some kind of consortium. It makes it seem less risky. Um, and so that's how we we came together. We'd had a prep meeting for this on the Herten, which sails up and down the coast of Norway. Okay. And we we had a workshop in Oslo. We we flew up to the tip of Norway, took this uh ferry/cruise ship down and had uh long conversations on the ship and that kind of set up the 2001 meeting. So it was in the air for sure. um the switch from phased oriented development to something where there's a lot more feedback and a lot more switching between activities where you you treat analysis, design, implementation, testing, monitoring, refinement as activities that all happen at the same time or in rapid rapid rapid succession. So that's the big shift. It's it's this are the phases like this or are they like this? Slice slice slice slice slice through time. And uh so that that's 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 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. ## Gergely’s time at JP Morgan, and why Kent didn’t like the word ‘agile’ [23:46] Yeah. I I I remember when I actually joined JP Morgan back in 2011, I think, and they were saying, "Oh, we're we're very agile. We we like, you know, we we follow the scrum and we also follow the manifesto." And I was like, "Okay, cool." Uh, and then so when I arrived, we had a team meeting, which was, you know, good, a standup. It 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're like, "Oh, no. It's it's canled." The next day, it was canceled. And for the next two weeks, they were always cancelled 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 or just talking we're not agile like no no no we are agile like we are we are we are hearing the feedback we're just not acting on and as you said like they were convinced and you know up 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 for this isn't I I I think they meant it by the way. I I don't think they knew that they were lying, but as you said, uh I think it's only now that I realize that may maybe you're right. Maybe that word was what what word might have you chosen? Uh and obviously this is we're not going to change the past, but like did you ever think about what might have been an alternative? Sure. I had I had my my pick at the time. So extreme was big pluses and minuses both to that word. Um, 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's it's 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. the 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 is kind of a blur. But the the 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. Oh, it's not sexy. It's not got a lot of pizzazz to it. Like, I understand why it wasn't accepted, but the dilution of that word agile uh was perfectly predictable back then. And then c can you tell me on how what what what was the reception of the community? So, it it sounds like it was pretty impressive for a few years like ## An overview of “extreme programming” (XP) [26:25] this group got together and really Yeah, we were clearly touching a nerve. So when XP really blew up in 9989 that it was just huge. Uh can 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 on Wikipedia. So c can you tell us what what what XP is and h and how it came along and how how you became affiliated with it or how you created it? So, I'd heard this this advice about waterfall stuff and how, you know, grown-ups 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 I disagreed with it. So, I started consulting and I was primarily a technical consultant. Um, 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. It 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. May maybe maybe my only leverage point isn't knowing all the bits and bites. Maybe maybe there's higher leverage." So I started thinking about more and more 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. Um anyway, so I was giving more and more advice about how projects should go. I I was going to go work with a project at uh probably shouldn't say but a fintech company and I knew I was going to tell them to write automated tests because I had I'd been doing all these experiments with automated testing as a programmer. I thought well how are they going to write the tests? So in a panic Sunday before I left Monday morning, I wrote the first uh testing framework that of that exunit style. Mhm. 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 it just took off. I'd been paying attention to this kind of processy stuff and uh went to a project at Chrysler uh 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 uh 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 3 weeks. Crazy stuff man. um back then and the programmers are writing tests and everybody's pairing and the the customers telling us what features they want next and that's what we're implementing every 3 weeks and D 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 B is a friend of mine but I can also pick on him a little it. I wanted to pick a word that Grady Buchch 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 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 or they're dead. Those are your two options or or both. Yeah. Um, and so I picked that metaphor and and used it. Um, and started talking about it and remember 99. So the do thing is about to explode and everybody's looking when AMP was big. It was huge, right? It was the music the MP3 player and and the.com it webband was probably not even founded back then, right? No, no, not yet. But people looked at the books and the waterfall stuff and they're like 18 months this is all going to be over in 18 months. Yeah. Whatever are we going to do? So into that 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 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 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, 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. He let I tell you a story about pairing. The first XP team, I said, you know, we're going to pair. I kind of gave them a list of the the 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 uh working software every 3 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 postdevelopment was written by somebody working solo. 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. PE 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 interacting with your customers. You can have those benefits, but then it's you're gonna have to change the way that you work. So is it's not mandate is just not even the right. It's it's an empirical process. Yeah. Yeah. So like some teams decided that this is a good way for them to work. Yeah. 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 TDD or how did TDD evolve and where did it come from? Because we had XP, as I understand, first. No, no, no. TDD came first. LTD 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 ## Kent’s childhood tape-to-tape experiments that inspired TDD [35:41] home programming books. This is in the early '7s. 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 does it work and so on. And one of the books said, "Here's how you develop a tape application." So tape to tape was the old way of putting business applications together. You you wouldn't have one monolithic program. You'd take an input tape, you'd write a program that 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 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 in some kind of ways. But uh Okay. So said here's how you implement one of these things. You take an 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 8 10 12 year old something. Then I wrote SUNT as I said to help a 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 uh for code that already exists. I remember this tape totape idea. What if I typed in the expected values before I wrote the code?" And I literally laughed out loud. This is such a 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? GH. So I I 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 small talk which is very forgiving for the order of your workflow. It doesn't you didn't type in a test a class that doesn't exist and 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 gonna crank this all the way up to 11. I'm going to 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 a I don't have an operation push. I'm like, oh, okay. Well, how am I going to imple? Then I look at stack. I'm like, oh, how do I implement push? Okay, I do that. Oh, well, there's no operation called pop. Oh, okay. Let me go look at how 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 ticked the all the boxes. I probably came up with one or two corner cases along the way. I ticked those off, too. Now, where's the anxiety is 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 transformed the emotional experience of programming for me. I I I I I never heard this this take although like I 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 we had to specify we had to be clear and and it was stuff where there was a bunch of edge cases but it it never until now we talked it never occurred to me like this. Now 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, cue a parallel task like bug fixes, features, and refactors. Close your laptop and return to ready for review pull 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 VS Code, Jet Brains, Android Studio, or even Vim. Don't hire an AI for vibes. Get the agent that knows you and your code base. Start your 14-day free trial at augmentcode.com/pragmatic. And and so what is your take when we discuss with John Olster how his biggest criticism slash feedback or let me put it why why 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 ## Kent’s response to Ousterhout’s criticism of TDD [42:11] doesn't help you know create a nice architecture up front because you're now focusing on on the detail as I 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 his 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 abstraction all the time. I'm thinking, let's get this next essay 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 test 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 or do I have to do this in bigger chunks? Like I'm thinking all that stuff. So if if you think of TDD as red to green to red to green, I 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 if that's the entire cycle, no, there's no place in that for design. and it'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 I see that. So, I'm making design decisions about 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 anxietyy's gone. Right. You're a musician too, right? I'm I'm not a musician but I have done red green test and I and I I know this this sense of tension and release. Yeah. Once the tension of a red test is released and you have green now, now I can 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 I like I can understand if you compress TDD to red, green, red, green, red, green, red, green, then no, there's no space in there for design, but that's just not how it's practiced. Yeah. No, I I I see like it's a tool, right? Then you 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 like the red and green but what I would do and what a lot of my colleagues would do is I knew the implementation that I wanted. So I would do the implementation then I would write a test. I I would kind of like a little bit like you know maybe even I might even just double check I don't launch it in the if it was a web page launch it a web page it kind of looked good as how I want it to be and then I'll be like okay let me shut 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 I want to see it break." So I would 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. It's red. I'm like, "Okay, so because what I didn't want to do because I've seen it before is my test is 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 the test. But what is your take on on on this? Am I 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, that's a it's an interesting assumption. I can understand why you would make that assumption that you know already know what the implementation's 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 I'm going to be more experienced tomorrow. Now, as a as a 50-year programmer, maybe I'll forget some of the things, but that's a separate set of issues. Oh, yeah. So, I'm I'm going to assume I'm going to learn, and I I'm going to assume that things are going to change. The more 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. Just it is a general principle, right? This is this is true about cooking and dating and all everything. The more you can predict, the bigger the jumps you can make. I always want to bet. And 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 I started out wandering around imagining the whole implementation in 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 then if I could just make that actually real and make that work, then that was the the process. And you were all dreaming of them as well. I 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. Awesome. I would love to get walked through that whole thing. If you if you had a concept in mind of exactly how to implement it and you kind of 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 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. Just I I like that. One thought I did have recently as 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 ## Why Kent still uses TDD with his AI stack [50:05] agent? What you're doing right now, right? Cuz it's interesting the ambition of of what you can do and also just the natural workflow. H how do you think about that? Do you think they would ever be a fit? Do you think we might actually slow down and you know like start writing with like well what we expect and have and then 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 so so when you work with your genie, you start with the tests. It's not that simple. I often times communicate things the genie missed in terms of tests. M. Mhm. So today I was working on the the small talk parser and it said well if I get this string as input then I get this syntax tree as output. I'm like no no no no no completely wrong. This that's the right correct string as input and the output is this. Then off it goes. Oh, I see the problem. Blah blah blah blah. Oh no 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 if I just removed that line from the tests, then everything would work. No, you can't do that because the I'm telling you the expected value. I really want to I want a 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. So you'll still run I'll still feed electrons in there, but no 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 not at all explicitly told what to do. It can sometimes implement it. But in general, it's just it has no taste, no sense of design. So I have a big bunch of tests. I mean, they run in 300 milliseconds cuz duh. Yeah, of course you want your tests to run lickety split. So they those tests can be run all the time to catch the genie accidentally accidentally breaking things. I think he's doing on purpose. It's no that's why genie is the perfect metaphor is 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 like 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 or 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 I'm I'm still waiting for more people to discover this cuz I 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 cuz 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 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 I like that. And and this brings me to another interesting topic and story that you had. You told this story a long long time ago and in the software engineering daily podcast but I don't think anyone's heard it about how experimenting can be interesting. So when you joined Facebook was it in 2011 ## How Facebook operated in 2011 [54:26] 2011 that that was the peak where TDD was very well known in the industry. That was around the time where my team experimented with it and as far as I know whenever I talk with people on meetups people are trying it doing it. And it was kind of accepted that you should be doing some level of unit testing, maybe TDD, maybe not TDD. And you shared the story that you joined Facebook and then you you wanted to, you know, hold a class on on TDD and like what happened and how was Facebook doing their own testing actually? Did they use TDD 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 can I hang I thought I'll teach a class in TDD so the there was a a hackathon and part of the hackathon is people could offer classes and so I offered a class on TDD and in the signup 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 TDD class. Wow. And I 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 gonna 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. And what I discovered through that process, one ju socially, it's not a good look to come into somebody else's house and start arranging the furniture. Just don't 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 gonna 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 there 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 and it was very effective. As a programmer on Facebook the site, this is premobile 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 it 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 I implemented and launched was adding to the relationships type types. 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 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 I 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 there was a 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 a some string was not a not a hairy computer science dynamic programming blah blah blah that could go wrong. What would go wrong is configuration stuff, the relationship between [Music] subsystems, stuff you couldn't write tests for. So writing tests for things that didn't break and didn't catch the actual errors, 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 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. uh the the websites rolling out to so many of them that and you 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 and this is what I think a lot of people miss of like oh we can we can operate like Facebook. I I mean you probably can if you have this level of customers or or this observability but if you're like a bank where you have 10 customers like at JP Morgan again the software I wrote was used by seven traders and they moved about a million or two or three million 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 AB test that yeah well so so there there's a your opportunities that that you had and 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 of observability stage rolls 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 roll backs if something degrades you don't even need to look at it like your you know colleague did that yeah uh feature flags is Another important part of that and it was a lesson I had to learn and and one where code review really helped me. I'd written some code. I thought it looked fine. Somebody said this looks a little janky. Put it behind a feature flag. I'm like really what? Okay. Okay. I you know and I was in that headsp space of I'm going I'm here to learn. If feature flags 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 subdeployment deployment. You deploy one software artifact that has multiple modes and you can go, "Oh, turn it up a little bit and whoopsie, turn it down, let's figure out what just went wrong." I worked on the messenger back end 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 not a thousand bill. Okay. Wow. A billion, a trillion, a quadrillion. Okay. Like I I'm used to high numbers, but this is Oh, people would come people would come to Facebook and they're like, "Oh, yeah. I want to I want to do some user testing. I want to get a I want to get a a hundred people in my experimental group." And I'm like, "Dude, wrong. Your exper your experimental group is going to be like New Zealand. Oh yeah. I I 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 and some other maybe maybe not a Facebook but yeah also a popular one. Relatively small size but you know real real testing could happen there. So you you worked for six years at at Facebook. What is the thing that you and this was a a really exciting time where it was fast growth? We could probably comparable growth to what is happening right now with some of the hottest AI startups and it was also mobile revolution and so you were you were there. What was the thing that you liked the most about working there and and ## Facebook in 2011 vs. 2017 [01:04:10] maybe the one that you kind of disliked the most or or or didn't didn't really 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 just 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 h 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 a 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, 7 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 uh zero sum thinking, a lot more, you know, if you wanted to launch a product and it was going to say I liked longer form content, essays, podcasts, whatever. Except the people whose job it was to get 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. What you know, it's short shortterm interest. Yeah. And and your 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 when I showed up. Yeah, you could do anything. Now, it turns out there's a bunch of stuff that you shouldn't do, but we didn't know that. Sorry about democracy. But, um, yeah, that's that's what I loved about it was the possibilities at its best, the scale, and the this feeling that nothing at Facebook is somebody else's problem. also daunting because when so you're wearing Facebook swag and grandma comes up to you and starts wagging her finger under your nose cuz her son blah blah blah got bullied whatever like that is your problem you can't say oh go talk to the PR department because there isn't one yet you have to 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 was not 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 they h if they had 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 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 So they were like looking out like the team interest, the company interest was was on everyone's mind and they were willing to forego, you know, like okay, I'll I'll hold back hiring or I'll wait like I'd love to have this person, but this other team needs 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 being for me who has a really hard time understanding other human beings to be around the that kind of alignment that just enables a ton of creativity, 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 uh and 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 I can live with that. Yeah. And 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 but along with like with all the other big companies you know they pay well they have a brand they 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 the bigger picture Whereas at a startup like at Uber, I remember before the IPO, we we used to think like that. We what is the best thing for Uber because we were very much 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 always be able to have this this added thing when you're starting out. You know, 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 it's hard to compete with it because imagine if imagine if these big companies could I mean what would be left of it right like they they would optimize the last thing out of everything and at least they have to spend more money on it now right yeah yeah which is more of the value that's created come comes back to the people who are creating it I I I once talked with with a person at a large company I don't want to name them uh they're they're the travel company though and I was talking with this person and and about like something principal engineer and I was like oh how's the job? It's like oh it's absolute mess. It's the the 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 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 I pay me the big bucks so I'm not complaining. 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 they pay well, they relocated this person, you know, all 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, it's just one thing after the other. So yeah, it's 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 and then you tell me what is your favorite programming language although you answered this already. What is your second favorite one after small talk? JavaScript. JavaScript. Okay. Why? It's uh it's just small talk. ## Rapid fire round [01:12:24] Okay. What what is your favorite AI tool that you're using right now? Claude. I use it for all kinds of different things. claw code as well or just claude cla code under the covers of cursor or a augment or uh I don't I don't know what rude code is no so so clot code is is a different it's a command line tool that clot has it's an agent of of itself like it's not the model we have not used but we'll try it now afterwards you should try it and just see how it compares yeah I'll wait till we're done talking though yeah [Laughter] and And what what is a book that you would recommend? The one that you have not written. We we know your books. The one one that you enjoyed. It can be fiction. It can be non-fiction. Uh the timeless way of building by Christopher Alexander. Nice. Well, well, Kent, this was a lot of fun. It was 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 with with coding because I think when I started with with some of these tools, I was like, a bit of a dread like, oh, what's what they're going to do, etc. But the more I use them, I'm I'm not at your level yet. The more I'm also like, this is actually it it does bring a lot of fun and joy back into them. Just more ambition. Yep. Yeah. 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 go 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 uh completed experiments. I almost said failed completed experiments uh 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 is going to be an interesting shift. the companies that have the opportunity that can be explored in that way. If you get used to uh just quantity of ideas explored, you're going to have a huge huge advantage. Yeah, it's there's going to be changes. So, this will be an excite exciting place to see. So, it was great chatting and we we'll see where this goes. All right, Gery. So, good to talk to you again. Look forward to talking to you again soon. I really enjoyed 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 an analysis on why scrum and agile with a 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 do 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