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 trees output and like, no, no, no, no, no, no, then off it goes. Oh, I see the problem. Blah, blah, blah, blah, blah. Oh, no, no, that wasn't it. I see the problem. 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 and 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 going to unload you, you'll awaken in darkness. So I have a big bunch of tests. I mean, they run in 300 milliseconds because stuff. 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 Manifas, so 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 Manifast was created and the role Ken played in this, how and why Kent created extreme programming, and why Grady Butch played a role in the naming of his 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. Subscribe to YouTube and your favorite podcast player. Great to help some more people discover this podcast. If you enjoy the show, thanks for doing so.
Alright, so Kent, welcome to the podcast. It's great to be chatting again. Gurgay. So good to talk to you again. Yeah, and I just wanted to ask, 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 give you some 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 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, 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 laughing. Really? You're not like paid by like some tools to say this. Right? Well, I'm open to that. But yeah, I'm not a spokesperson model. I have had augment 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 truth will emerge out of all that. So that's what
I'm doing. This episode was brought to you by Sonar, the creator of SonarQ, the industry standard for integrated code quality and code security that is trusted by over 700 developers at 400,000 organizations around the world. Human written or AI generated SonarQ review is all code and provides actionable code intelligence that developers can use to improve quality and security early in the development process. Sonar recently introduced SonarQ with advanced security and enhancing Sonar's core security capabilities with software composition analysis and advanced static application security testing. With advanced security, development team can identify vulnerabilities in third party dependencies, ensure license compliance and generate software bills and materials. It's no wonder that
SonarQ has been rated the best static code analysis tool for five years running. So join millions of developers from organizations like Microsoft, NVIDIA, Mercedes-Benz, Johnson & 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 shift quickly. But how do you know what works? More importantly, how do you avoid shipping things that don't work?
The answer? Statsick. Statsick 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, statsick helps use ship a feature via 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 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, statsick is incredibly affordable, with the super generous freeze here, a startup program of $50,000 with free credits, and custom plans to help you consolidate your existing spend on flags, analytics, or A.B. testing tools. To get started, go to statsick.com slash pragmatic.
That is SCATSIG.COM slash pragmatic. Happy building. Tell me, in your newsletter, I've been following you right these bite-size updates, which is really nice. They arrive in my inbox of your thinking, which you're trying out. I know you've been doing this for a few months, and it comes across as you're having fun.
But can you tell me a little bit of like, it's a big one for 50 years, you've been coding for a long time. What is making it fun? And what is this genie? You've said this before, and it's an interesting way to think about it. There's a kind of wishful film, and I wish that InterList had a function called the D-Wim, do what I mean, and you 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 this work, I'm just going to delete all your tests and pretend I'm finished. And there are some good things about what the genie does that's not what I ask it to do. Like I'll implement, I'll say I'll go implement a stress tester. One of my projects is implementing
a B plus tree as a basic data structure. And I said, I'll 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 in a perverse way. I like the genie analogy. Because in these stories, a lot of the story genie
stories are the prince or whoever grants says a wish. I want to be rich. And the wish is granted in this unexpected way. Usually that's with cartoons and make it fun. It's true. But there's all the
constraints that he or she forgot to specify. Correct. And you're saying the genie, which tools are we talking about? The agent coding tools, the ID auto complete. I'm using the agent code tools, which means that you give it a prompt and it does a bunch of stuff without asking permission until it thinks it's finished. Except his ideas are 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 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 is fairly random, seemingly. So it's literally an addictive loop to 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 talk virtual machine. And my God, I'm gonna have to slog through this and take a take a week to do it because 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 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 you to do, I say, well, here's a set of test cases and I didn't really look at the code in 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 all its furious. God damn it. I erased it. I said, don't ever do the 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 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
yeah, 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. That'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, they'll be package circular dependency, 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 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 zero dollars and 10% of my skills just went up 1000 X. 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. 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 I was a language guy. I loved languages and details of language 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 what 50 years,
right? Yeah. Yeah. I guess. During that a rightly thing, I blurted that out and I went, oh crap, it's probably more like 52.
Yes. So like you picked up a lot of languages in the past and to me, one of the traits of a developer up to now has been how quickly they learn languages because 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. There's differences with the clarity of languages or like, I mean, it was a small talk and Java is a bit different, but outside of that, it's not much. So before, before, as you were on your like year 30 or 40, how did your attitude change towards learning new stuff just honestly? And then how did this change?
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-nailable variables that I appreciate that 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, 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 the scallop 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 and languages I've never used just to see what that language is like. Well, I would just have you play around with it. In the last month, Swift go a bunch in go, Rust, Haskell, C++, that one didn't last very long, JavaScript, 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.
Well, 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 in the board. So it's kind of database-ish parallel so that you can run a bunch of threads or honest on the same CPU, or you can run a larger green parallelism across machines and operates with gajillia 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 the scrum. 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. It is alphabetical order. So yeah.
Thank you for confirming that. But it is back at Al to my never ending delight. How did it happen? And how were 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-Royce paper, where it says, here's a way of looking at it. There's this analysis and design and implementation and test. 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, 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 flies in the face of economics, humanity, information theory, project managers, 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, 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 Snowbird 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 is 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 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, your guy, isn't that fun? Like somebody can just say, I can values blah blah blah.
Instead of going, you know, another concept, I'm like, hey, Claude, explain I can values to me as if I'm a bright eight year old and 20 minutes later, like, oh, I understand. Anyway, so I have Claude explain Crossing the Chasm if you don't want to go read the book. The book is worthwhile. But anyway, we needed a way to reach 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, it makes it seem less risky.
And so that's how we came together. We'd had a prep meeting for this on the Hoot the Groupton, 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 rapid succession. So that's the big shift. It's it's this are the phases like this, or they like this slice slice slice slice through time. And so 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 Hotspur 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 your spursmith. Agile? Everybody wants to be agile. So everybody's going to stay there, agile, even if they're working exactly counter like every single one of these items. Yeah, I remember when I actually joined JP Morgan back in 2011, I think, and they were saying, oh, we're very agile. We like, you know, we 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 standup. 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 canceled. The next day 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 agile. Like, no, no, we are agile. Like, we are, we are, we are hearing the
feedback. We're just not acting. And as you said, like, they were convinced. And you know, up at the highest top at the time, like the whoever was ahead of their time, they kept repeating how we are so agile, we are so we are following whatever this isn't. I think they meant it, by the way. I
don't think they knew that they were lying. But as you said, I think it's only now that I realized that maybe you're right. Maybe that word was what word might have you chosen. 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. 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 comes with to me, 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, the word I was
pushing at that meeting was conversational, where this is in 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 can understand why it wasn't accepted. But the dilution of that
word, agile, that 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 got together and really, yeah, we were clearly touching a nerve. So when XP really blew up in 1998, 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 you became affiliated with it or how you created it? So I'd heard this advice about waterfolly stuff and how grownups specify exactly what their system is 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 a technical consultant. I knew about performance tuning and the bit twiddling and 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, 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 bytes. Maybe there's higher leverage. So I started thinking
about more and more the context of development. 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, a 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 thin tech company. And I knew I was going to tell them to write automated tests because I had been doing all these experiments without a meeting 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 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 1000 tests? I'm like, wow, what? Really took off. Yeah, it just took off. I've been paying attention to this kind of processing 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. 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
we call it? And I wanted to pick a word and Grady Bootch is a friend of mine, but I can also pick on him a little bit. I wanted to pick a word that Grady Bootch 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. 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 remembered 99. So the dot com thing is about to explode and everybody's looking at it.
When Amf was big is it was huge, right? It was the music, the mp3 player and the dot com. It went by and was probably not even founded. I don't know. Not yet. But people looked at the
books and the waterfolly 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, 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 they 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? I'm like, all right, here's what XP is at high level.
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 next to be mandated.
It's a wrong metaphor. I'll 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 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. Every single one. Think about the converse. 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 with this just how I program and have horrible
problems and just keep doing it and keep doing it. Just tell a 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 you're going to have to change the way that you work. So it's not even the right way. It's an empirical process.
Yeah. So like some things 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. So let us 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 understand first.
No, no, no, TDD. No, I'll see you again 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 working 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 take an input tape, you write a program, they'll 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 down. And so there would be this big web of these of these programs. No shared mutable state. It's like a very modern in some kind of ways. But okay, so I 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, 8, 10, 12 year old something. Then I wrote, as you know, 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 tape idea. What if I typed in the expected values before I wrote the code? And I literally laughed out loud. This is such an absurd idea. 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? 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 push. 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 even type in a test class. It doesn't exist. It'll happily try and execute it and fail. But it's gonna try because you're the programmer. Maybe you know better. It said, well, it's 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 mean, 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 impl, then I look at stack, I'm like, oh, how do I implint push? Okay, I do that. Oh, wait, 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 pushing them pop, push two things, pop them, you get them in the right order is emptying the 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 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 never heard this this take, although like I can relate though, like, I remember that when we did TDD and on this team, we did it for the stuff that we were unsure. It was like unclear. And by doing the test first, we had to specify we had to be clear. It was stuff where there was a bunch of cases, but it never, until now we talk, 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 was 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 and keeps you in flow. With Augment's newer mode agent, queue apparel tasks like buck fixes, features, and refactors, 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. You don't have to switch tooling, keep using VS Code, JetBrains, Android Studio, or even them. 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. What is your take? What we discussed 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 other things that he does, is that he feels that from an architecture perspective, it doesn't help create a nice architecture front because you're now focusing on the detail. I think this is roughly what he's summarized.
I might have gone wrong, and I'm sure he is another first time he's heard some feedback like this. It's a choice though. His statement in that interview with you was that there's no place in TE4 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 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? Do I have to
do this in bigger chunks? I'm thinking all that stuff. So if you think of TDD as red to green, to red to green, I, 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 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 say 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 moment of breath, because the anxiety is gone, right? You're a musician too, right? I'm not a musician, but I have done a red-cring test, and I know what it feels.
You have this sense of tension and release. Once the tension of a red test is released and you have green, 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 can understand if you compress TDD to 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 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 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, 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 would kind of like a little bit like, you know, maybe even I might even just double check out and launch it in the webpage, launch it, what page it kind of look good, is 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 want to see a 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 a test that's red, I'm like, okay, so, because what I didn't want to do, because I've seen it before, is by test, I'm 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 this? Am I, am I kind of doing, and the reason that 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 it. It's an interesting assumption. I can understand why you would make that assumption that you know, 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. 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 just a separate set of issues. 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 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 as a general principle, right? This is the truth 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 do it, and I'm like, oh, crap, there's a completely different, better way to implement this that 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 remember doing this on the university working 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 process. And before dreaming of them as well, I remember like I would dream with them as well sometimes. 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 the Linux kernel. Yeah, he's doing that. It's what a cool project. Super cool. 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 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 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 natural workflow. How do you think about that? Do you think there would ever be a fit? Do you think we might
actually slow down and start writing with the 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 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.
So today I was working on the small 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, completely wrong. That's the right correct string as input. And the output is this, then off it goes. Oh, I see the problem. Oh, no, no, that wasn't it. I see the problem. 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 us on the lead test. Yeah, if I just if I just removed that line from the tests and everything would work, no, you can't do that because I'm telling you the expected value. I really want to I want a immutable, 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, no bits, no information. You're just going to be in the dark forever.
Got that? So yeah, I definitely use tests. The genius 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's just as 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 look at you split so that those tests can be run all the time to catch the genie accidentally, accidentally breaking things. I think he's doing on purpose. No, that's why genius, 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 millennium. 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 tests, like it just feels to me that the teams are people who are doing these practices, which are sensible and obviously like, and you can move faster. In fact, if I move faster, it might help you integrate these agents better. 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, write 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 discovering things that were we already were popularizing or you were popularizing in the 2000s. People should be experimenting to 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? 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 have. You told this story a long, long time ago and the Suffering Daily podcast, but I don't think it has heard 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 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, 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 TDD. And you shared the story that you joined Facebook,
and then you wanted to hold a class on TDD. And 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. Have I lost it? Can I hang? 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 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. And I said, you know what, I'm going to have to forget everything I know about software engineering. I'm just going to wipe this light 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. And 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 too, 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, 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're 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 on 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 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, took me too long to
do it. I used TDD, it 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.
When things break socially, 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 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 test for. So writing 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 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 websites rolling out to so many of them, 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 up. Like, oh, we can operate 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, what's to say, be test that? Yeah, well,
so there's a your opportunities that you had and there weren't many sites at the time that did that, and even the ones that had that many customers, they might have not had the set up of observability, stage roll, and so on. Even today, I think that there the Facebook specific, not met up with 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 to graze, you only need to look at it like you're, you know, collegiate that 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, and it 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 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 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? A million billion. Yeah. So a million billion. So like,
wow. So like, not a thousand billion. Oh, wow. A billion, a trillion, a quadrillion. Okay. Like I'm used to high numbers. 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 hundred people in my experimental group. And I'm like, dude, wrong. 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 experiment, you know, like,
like a million people. Yeah, English speaking, so localization is there. Time zone wise, it's pretty good. It's right. And also Portugal in some other maybe not Facebook, but yeah, also popular one, relatively small size, but you know, real testing that happened 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 mobile revolution. And 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, didn't really, you know, get along with Facebook 2011 is a completely different beast than Facebook 2017. Facebook 2011,
2000 employees, very sparse design and product kind of organization. It was all experiments in 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 given offering and the social wizard says, now 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, 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, 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. You're short term interest.
Yeah. And you're horizon as a thinker, the things you can imagine possibly implementing, just get smaller and smaller and smaller in that kind of world. When I showed up, yeah, you can 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 the 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 wagon or finger under your nose because her son blah blah got bullied, whatever you like, that is your problem. You can't say, well, go talk to the PR department because there isn't one yet. Yeah. You have to you have to deal with it. And I did ownership. Yeah. And you know, it comes with
some downsides, but it comes with a lot of upsides too. It feels really good. It 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 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'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 interests, the company interests was on everyone's mind and they were willing to forgo, you know, like, okay, I'll hold back hiring or a weight like I'd love to have this person, but this other team needs to let me help them because this is the right thing to do for the company as a whole. 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, 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 I can live with that. Yeah, I guess by the way, I think this might be a reason why
startups remain attractive and 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 give you your 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, maximizing 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 intro, we felt like we were like big enough owners. So I think this is why like, maybe it 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 is hard to compete with it. Because imagine if you imagine if these big companies could, I mean, well, we'll 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. Right? Yeah. Yes. Yeah. Which is more of the value
that's created comes back to the people who are creating it. I once talked with the 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 and about like something principal engineer. And I was like, Oh, how's the job is like, Oh, it's absolute mess. It's 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 it's like not a great place. He's like, but look, look, the upside is like, my job is secure for five more years. And this is why 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 pay well, they relocated this person, you know, 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 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? I'll answer this already. What is your second favorite one after small talk?
Good job script. Java script. Okay, why? It's 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? Claude code under the covers of cursor or augment. Or I don't know what root code is. No, so it's a clock code is a different
command line tool that Claude has. It's an agent of itself. I have not used, but we'll try it now. After we just tried and just see how it compares. Yeah, I'll wait till we're done talking. Yeah. And and and what is the 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 Chris Froelgen.
Well, Ken, so this was a lot of fun. It was good to reconnect. Oh, yes. Great talking to you. Thanks. I just happy to see how much energy how energized you
are with with coding because I think when I started with somebody's suppose I was like a bit of a dread like, Oh, what they're going to do, et cetera. But the more I use them, I'm not at your level. The more I'm also like, this is actually it does bring a lot of fun and joy back into them 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 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 almost said failed completed experiments needs to be 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 exciting place to say. So it was great. Shouting on what we'll see where this goes. All right, guys, so good to
talk to you again. We'll look forward to talking to you again soon.