The Pragmatic Engineer - How Kent Beck shapes the software engineering industry

Episode Date: July 1, 2026

Brought to You By:• Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages.• turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable.• WorkOS – everything you need to make your app enterprise ready.—Few have made as big an impact on software engineering as this week’s guest on the Pragmatic Engineer podcast, Kent Beck. He created Extreme Programming, pioneered test-driven development (TDD), co-created JUnit, and is one of the authors of the famous ‘Agile Manifesto’. But these days, he's re-examining many ideas for the age of AI, and says we’re failing to accumulate trust during this new era at the same high rate as new code is being accumulated.In this episode of the Pragmatic Engineer podcast, Kent and I dig into his journey from discovering Smalltalk in the early days of personal computing, to helping define modern software engineering practices. We explore the origins of TDD, design patterns, Extreme Programming, and Agile – along with some lessons learned at Apple and Facebook.Kent explains why he believes software engineering is about far more than writing code, why no one yet knows exactly how engineers should work alongside AI agents, and how his "explore, expand, extract" framework can help engineers navigate major technology shifts.—Timestamps00:00 Intro03:47 Human engineers aren’t going away08:00 Kent's path into tech13:50 Undergraduate and graduate studies17:21 Kent’s first programming job18:54 The rise and fall of Smalltalk27:04 Working with Ward Cunningham37:36 Design patterns44:05 Working at Apple51:08 CRC Cards59:29 Testing tools in the language1:04:22 The C3 project with Martin Fowler1:09:54 Extreme Programming1:16:25 Developing TDD1:25:07 Writing the Agile Manifesto1:30:00 Agile’s impact1:32:40 Agile’s downside1:37:32 The Dotcom Bust1:44:30 Lessons from working at Facebook1:59:44 Kent’s ‘Good to Great’ program at Facebook2:06:07 Soft skills engineers need to learn2:09:30 AI and the challenges of acceleration2:15:53 Explore, expand, extract2:22:33 What Kent is excited about—The Pragmatic Engineer deepdives relevant for this episode:• Measuring developer productivity? A response to McKinsey – co-written with Kent Beck• TDD, AI agents and coding with Kent Beck• Paying down tech debt• The past and future of modern backend practices—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Ken Beck is one of the living legends of the industry. He's greatly shaped the software engineering profession and keeps impacting it even today. But there's not been a podcast episode covering his whole career from start to present, until today. In this conversation we cover how Ken grew up with computers in the 70s and how he fell in love with small talk. The origin of stories behind TDD, Extreme Programming and the Agile Manifesto, and while Agile, the word, was a mistake. Lesser-known stories like how he got fired from Apple, Ken's lost decade in the 2000s, and why he thinks TDD has failed. How he thinks about and uses AI and what still excites him with coding after 40 plus years. And many more. If you'd like to understand how True Legends was shaped by the industry and

shape software engineering himself, this episode is for you. This episode is longer than most of my podcast episodes and I do hope that you'll find that it's worth the time to listen to Kent longer than he's ever told his story in one setting before. This episode is presented by antithesis. If you work with agents, your job is no longer just writing code, it's specifying and testing it. And Anticistis is the most effective method of verifying agentic code today. This episode is brought to you by TurboPuffer. A fun fact about TurboPuffer is how they become the search engine for AI agents. It seems like every week they add a new use case from one of the leading AI companies.

Ramp, Lagora, Harvey, Granola, they're all on TurboPuffer. Or, as a team likes to say it, they're all puffin. TurboPuffer offers a full set of search tools, vector search, full text search, attribute filtering RageX, and more, in one API. It's built on object storage as a store. stateful dependency, so it's extremely scalable, reliable, and cheap. But it's also very fast thanks to its intelligent caching layer. One cool thing about TurboPuffer is you can have unlimited search indexes, so it's perfect for multi-tenant AI applications.

Build an index per tenant, data is isolated by default, and you can scale without thinking about it. Here's the best part. TurboPuffer just announced last week that they've dropped their base price from $64 per month to $16 per month, so there has never been a better time to test it out. head to turbopuffer.com slash pragmatic. And it's so good to have you in person on the podcast. It's great to talk to you again. Yeah, I want to kick off with something really timely.

There was this tweet going viral by Dario where he said, I quote, coding is going away first than all of software engineering. You had some things to say about it. Yeah, my response is that that's a statement by someone who doesn't understand software engineering. coding is part of what you're doing, but it's only a small part of what you're doing. Even if it takes up a fair amount of time, you're building confidence, you're building

connections with other people, you're building your own understanding. All those things are happening while you're coding. And coding's actually a great way to cement understanding. The more you program, the more you understand the domain that you're working in. So to say, well, we're just going to pass all that off to a machine. Well, that's not all there is to it. Interesting because one thing that is so obvious with LLMs is they just code really quickly, right? Like it used to take us a lot of time to both type it out and also thinking out,

but you're saying that there was thinking involved and understanding involved as well in that process, right? So a couple of days ago, I saw a phrase and it really hit me that we're accumulating code faster than we're accumulating trust. And that sense of trust comes from me struggling to understand some domain concept. I get it. I represented in the code. I write tests that demonstrate that I really did understand it. And now I trust my program. But if we're programming together, that active programming together means that we trust each other more.

If we talk to someone, an eventual user, and we demonstrate that we understand their needs and we, you know, they tell us, well, I want a button that does this. And we're like, well, what problem are you really solving? And we go back and forth and back and forth. That builds human trust as well. none of that can be automated. None of that occurs if we prompt the, we get the finger guns. You know, the genie goes, yeah, it's all finished, boss. And it's like, well, hang on, finished.

What's finished? As we're talking about software engineering, you've mentioned trust, connection, understanding. You didn't mention technologies. You didn't mention programming languages. you didn't mention, wouldn't even mention refactoring. This is really interesting. You've been doing this for, what, 50 plus years now? Do I understand that the human part is the hardest or most important part in software engineering?

This is the biggest cosmic practical joke ever. As young people who, some of whom, like I don't understand humans very well, we were promised, okay, here's this computer, and if you completely understand this computer, you'll be fine. That's all you need to do. So I set out the first part of my career just to become the best programmer that I could be because that's what it would take to be successful. And then, who, sorry, there's this whole human side. And your ability to affect change in the world is gated by your ability to communicate with, empathize with, ugh, empathy, not my natural strong suit,

to convince, to communicate with, to soothe, to understand other human beings. And those are exactly the skills that I thought I didn't need to learn. So I was promised, just understand the computer, and then just kidding, understand people from a position. where I was already 10 years behind. So I'd like to go back to write there to the very beginning because so many people know you from your books,

from a lot of the techniques and the techniques that you've co-created or made it made a lot more popular, XP, TDD, a bunch of other just small refactories and so on. But going back, how did it all start? How did you have your first contact with computers? I know your father was an electrical engineer. Yes. So my father started out as an electrical engineer.

He was in the Navy in the Korean War as a radio operator. Came out of that, went to school, got an electrical engineering degree, started working in aerospace as an electrical engineer. And then we moved to Sunnyvale, Silicon Valley. Before it was Silicon Valley. This is before the invention of silicon. Oh, this was before. Yes.

Before there was, this is when there were still cherry orchards on El Camino. And I was born there about the time. So I was in sixth grade. He brought home a programmable calculator, which was as big as, not as big as this table, maybe half this size of this table. Probably weighed 65 or 70 pounds. Yeah, yeah, it was. 65 pounds.

And it had Nixie tubes. Nixie tube is, this is before seven segment LEDs because LEDs hadn't been invented, you'd have an incandescent light bulb with 10 filaments in the shape of the numbers. And my first program was a loop that would just count up and down and up and down because the filaments were set one in front of the other, 012, 3, 4, 5, 6, 7, 8.9. So I just wrote a program that would count up and down because I loved watching this go back and forth and back and forth for hours. I could just. Was mesmerizing?

Oh, absolutely. That was the first time I had my hands on any real hardware. Although I did find my dad would bring home books and I was a kind of obsessive, back from me kind of kid. I would obsessively read these books, and I found one of them lately during a move, the Burroughs B-S-7-100 instruction set manual. And this was a really interesting machine to imprint on early because it has a hardware stack. It wasn't register-based. It was stack-based. How they did that with discrete transistors, I will never know.

But it's just a really interesting architecture. And that book, I would just read the pages over and over and I understood nothing, but I was just fascinated with this mechanism. So when I got an actual machine and I could play with it and something that resembled assembly language and I could get it to do stuff, I could have an idea in my head. And if I understood this mechanism, I could get it to do this stuff in my head, which would spark the next idea. that's what really hooked me, is that creative impulse coupled with knowledge of the machine, together I could create things in the world that I wanted to see. And this was very early 70s, right? Microsoft, 72 maybe. So Microsoft wasn't even founded, though, in 75.

What was it like in terms of how common or uncommon were these, machines, how much or little did you even think that they would go anywhere? Or was it just a fun thing that has just been invented? Probably the first wave of miniaturization was the programmable calculator. So the one that your dad brought home? So no, the like handheld calculators. Okay, so so is the big tabletop calculators was was one thing. But then, there were these little calculators. I remember my dad buying an HP 35 for $400, which I have no idea how much that would be today, but a lot of money just for this little thing.

It'll probably be something like $2,000. Yeah. So you had to keep the stack in your head of what order do I want to put the operands in and make sure that I stack everything and then you go plus plus plus and that would pop stuff off the stack. And then the HP45 came along and it had its own little programming language in it. And that was just like, okay, this is really, really cool. And then microprocessors started to come out. And we had the Z80 and the 800 and the 8,00 and the 6800. And my dad and I soldered together our first 6800-based machine. Then we were programming an assembly language.

Then out came basic. This was about 70s. Yeah. Yeah. So that was really, I was spending a lot of time working on that machine. Again, I wouldn't say I understood it at an elite level, but I was fascinated. Everything I could learn about it made me that much more effective at that creative impulse. imagination of a thing in the world, execution, there's a thing in the world.

And that just has always felt great for me. And then when it came to college, you chose University of Oregon, right? Well, University of Oregon kind of chose me because none of the other places I applied accepted me. No way. Yep. And what did you study there? How did your college years go?

Well, the first year was computer science. And so they already had a computer science. Computer science. Yes. Yes. We had invented computer science by then. The first year was CS and I enjoyed it, but I still wasn't a great programmer, but classes I breezed through. So I was a little bit bored. So before the start of my sophomore year, it was really hot and I was walking through the music building and there were some flyers for signing up for auditions. I thought, oh, I'd play guitar. Let me see what I I can do. Next thing I knew, I was a music student. So, wow. So I'd been playing, I started playing guitar when I was eight, kind of the end of the folk boom, Mrs. Card at a summer school class. And there was a guitar laying around at our house. And so I went and again, just obsessed. She'd show us something and I'd go home and I'd play it until my fingers bled and come in the next day. And And everybody else was kind of where they were before, but I would have mastered some picking

patterns, some strumming pattern because I just played it for three, four hours. So I was very into music. And in high school, I was in the choir, which was the big deal. We didn't have a lot of sports at our high school, but we certainly had music. It was kind of natural that I would study music. At the end of the year of music, I missed programming. So I went back to programming. Then I went back to music so I could do my senior recital. Then I went back to programming for a master's degree in another year and finished that.

And so as I say, I just ended on the wrong year. Yeah, because I checked. I think it was eight years in total that you spent at Oregon, at University of Oregon. Five years full time. And then I had a hard time finishing my master's thesis. What did you have a hard time? What was your master's teases on? It was a novel query language.

Not surprisingly, I did not get along with the authority figures, which is a theme of my career. Yeah, just had a hard time like checking off all the boxes and getting the whole thing finished. People said, oh, you're going to be sorry if you, I was just ready to quit. Just like, yeah, you know, this is all hoop jumping and has nothing to do with programming. and I was making good living as a programmer by then. So, oh, but you're going to regret it if you don't get your degree, if you don't finish. You're so close. And it's never, never helped me one bit as far as I can tell.

But you completed it. I did complete it. It is important to complete things that in that, in that process, from vision of thing in the world to careful activity to the thing in the world, there has to be some finishing. Even if I'm, as the Reverend Jesse Jackson said, I'm a tree shaker, not a jelly maker. And that's definitely me. Yeah, it's true for your work as well, also for software. Well, I keep switching topics. That's something that'll probably come up as we go through the various things that I've worked on.

What was your first job? It was while you were still finishing your degree the last few years. You started to work as a programmer, right? Correct. So during that graduate student year, a team from Tectronics came down to give a presentation about the programming environment work they were doing. Techronics started out as an electronic test equipment company in Portland, did well in their little niche, but they opened up an industrial lab, as lots of companies at that point did, to do basic research. and part of that basic research was on programming environments. They came and gave a presentation.

I asked some questions they couldn't answer. And so they invited me out to dinner, which led to an interview, which led to a job. Techronics was an interesting one because this is where you met Ward Cunegum, right? Yeah. So, Techronics had invested early in this crazy object-oriented programming language called small talk and was trying to make a commercial go of it. And I got there and looked at the research that had been presented down at Oregon and it kind of played itself out.

But this small talk thing, wow, that's cool. So I dove right into that. For those of us who have not touched small talk might have heard of it. What made Small Talk so, such a hitch? What pulled you in? What is the language like? There's a beautiful paper called the design principles behind Small Talk by Dan Engels. And the opening line is, Small Talk is computer support for the creative spirit in everyone, which had two big themes.

One was a language of programming, the Small Talk language, and another was, a language of interaction. Overlapping windows, mice as pointing devices, panes, scroll bars, those were all things that were pioneered out of the user interface. Those things are kind of ordinary today, but small talk, the language was built out of a very small number of primitives. There's really only three primitives in the language, sending a message, assigning a variable and returning a value. And that's really all that there is. And so maybe towards the end, we can talk about my current projects, one of which is to build a new small talk from scratch, just because now that's within reach for anybody. But what I found beautiful was that the language

pushed its own mechanisms to the absolute limit. So everything, thing is an object in small talk, including numbers. You don't call a function that adds two integers. You send a message plus, which is received by an integer and takes another object as a parameter. If that other object happens to be another integer, then you add them together. This leads to interesting things like there are no control structures to find. So no, if then else is not part of the language, it's part of the library. because there's a you send the message if true with a closure to true and it evaluates the closure. You send the message if true to false with a closure and it does nothing.

It just returns no. Everything is built out of the same kind of substrate. There's very few special cases in small talk, which means that sometimes you have to get clever to understand things like, How do conditionals work? But also, when the time comes for you to build abstractions, you don't have a bunch of special cases getting in your way. It is a different way to think,

especially looking at the modern programming languages that have a new language comes with so many things built in, whether even if we're thinking of like later languages like Coughlin or Swift or any of them, they have things like control structures and reserved words. why would you reserve words? How rude. The programming language should give me as much vocabulary as possible. But I do notice that with Small Talk, the people who have used it just get really passionate about it and love using it. And I understand doing my research that there was a time around that time for a few years where it started to become a lot more popular. Can you tell me why it got more popular? And then what happened? It seems to have kind of fizzled out. Yeah. Longer story. some of which I was not privy to, some of which comes down to business decisions. Objects were hopping.

We'd been programming with the previous generational languages, Cobalt 4-Tran Sea, Al-Gal, Pascal, for a long time, and we were used to kind of the constraints that those provided. And along came these objects, and objects were going to change everything. People were really, really excited. But, you know, objects were going to make programmers so much more productive that we wouldn't need nearly as many programmers.

And in fact... Really? Yeah. You know, it's so much easier to program with objects that ordinary people can write their own programs they don't have to... I've heard this recently.

Exactly. But seriously, like this was what they were saying where like inside of the industry, this was a thing, used objects or small talk. and do more, do more with less programmers, cheaper, the works? Yeah, and to a degree it was true. We would, people would come in.

So, electronics built a workstation. There weren't workstations. Technronics built a workstation and started to sell it with small talk bundled in it. And technical people, but in different domains, like chemical engineers or structural engineers or hydraulic engineers, would come in and show. show us the systems they built with small talk. And on the surface, they looked fantastic. The solved, and oh, they were so happy, so proud of their baby.

You look under the underneath, though, at the code. And it was just a horrible, unmaintainable mess. But the fact that people could program the programs that they wanted was a significant step forward as opposed to I'm going to write a thousand-page requirements document and then wait eight years and not get what I want, which was the alternative that we were offering at the time. So it's not the first time that we're expanding because again, if we jump today, similar things are happening. People in different domains who could never dream of hiring a developer are now building their programs.

And the same thing is playing out, which is if you look under the hood, if you put your software engineering hat on a look under the hood of that mess. There's lots of corner cases that aren't covered. It's impossible to modify and evolve. But so far, this story with Small Talk and Techronics selling machines that come with Small Top make everyone more productive, clearly it pays for itself. That sounds great. But then what happened? There were alternatives that were easier to understand.

So, for example, Small Talk syntax is funky. It's this keyword infix syntax. Along comes C++, which was originally called C with objects. And the syntax looks familiar. Even though it's the design philosophy is entirely the opposite of small talk. There's lots of mechanisms and they're very complicated. But just the fact that it was approachable that you could, there was a compiler because we were used to having compilers in small talk.

There'd be some code. to edit it, and now you're running with the new code. There's no compile and link step. Of course, it's just sitting right there. And if you're in the middle of, you know, if you could be editing some text and say, this isn't work the way I want and hit control C, and you get a debugger and go down the stack

and you find the code that's not doing what you want, and you fix it and you continue on your way, and then you're writing again. That was that level of, this is intended to be a personal, computer. And part of that, that sense of ownership was that you could see everything and you could change everything. Now, it turns out if you have 100 people working on the same program, you need to put the brakes on. Everybody can't be changing everything in incompatible ways at

the same time. That just doesn't work. But in terms of this is my computer and I feel power because I understand it, I can have more ideas that I can then execute on to create things in the world. It worked great for that. While at Techronics, you work with War Koonigam, who would later become the developer of the first ever Wiki. He had a huge influence or he helped create design patterns. He also helped with extreme programming. Can you tell me about what it was like working with him and how you and him started to

get into design patterns? which back then didn't exist, right? This was something you would invent later. We needed to give training classes on small talk and Ward had written some small talk. We knew each other. There were probably 60 people, 80 people in the labs. So we knew each other by side. I had learned a bunch about small talk working on my own projects.

I was working on programming language for prologue because logic programming was also a big deal at that time. So I implemented, I think, three different virtual machines. for prolog, including some nice animations showing how prologs unification mechanism work. And I guess for those who don't know, prologue is this, the current of language is a very different way of thinking. No, no, no, no, variables is I think. No, no, it's got variables. No variables is FP Bacchis. Oh, this FP, sorry, but it does have some, some funky stuff. I, I used it a long time ago. It's fun. Turns out to be difficult to write big programs in.

But it's a good exercise because there aren't control, like, do this thing, then do this thing, then do this thing. It's more like a theorem prover. So I was working on that. Ward had built this example code for the small talk class. And he said, I just want to run you through this code. So I sat down next to him and he showed me the code for plumbing, called plumbing. and I suggested some improvements.

We gave the class together. I met some people who would later become lifelong friends in that class. And then we just kind of fell into a rhythm of, well, I wonder if we can make small talk do this. Because the universe of what it meant for a computer to support programming was just exploding. We had this high-resolution screen, which nobody had ever had before.

We had this dynamic language, including our own implementation of it, so we could tweak it if we needed to. And we just didn't know what was even possible. So at first, and Ward was always a much better programmer than I was, in terms of low-level technique, you also had a gift-free.

for design at a higher level and a gift, as you see in the wiki, of picking powerful top level goals and then making something that does that. But I was this 24-year-old punk with attitude, and he didn't let me touch the keyboard for a while. I could watch him, and then eventually I was like,

uh, those parentheses don't balance. I need a period here. and I was actually being useful to him, even though, and I was absorbing watching a master programmer at work, but I wasn't really driving stuff. Eventually, though, I started, you know, understanding the low-level patterns

and then building up to the next level and the next, and then I would say, well, why is this called this and not that? We'd pull out a Thesaurus and look it up and find just the right word for things and then continue. and eventually I started making suggestions that he wouldn't understand right away. And so I would take the keyboard for a little while, say, lay something like this. Oh, I get it, I get it. And then he'd take the keyboard back.

Over the course of a few months, we developed both a programming style where the keyboard was going back and forth, where we were talking at multiple levels. You know, we talk about, here's this code, why isn't it working? Is this the thing we should be working on at all? What programming tools would we need for this to be easy? What should the design be so this whole thing should work well? Should we even be doing this at all philosophically? We would bounce between all those levels in the active programming. And we had a weekly cadence where money, day morning we'd have a coffee and we'd talk about of the list of things because we would then out of those conversations we'd come i wish we had a thing that did a thing we would talk about that and then we'd say okay well let's go down and see how far we can get and over and over tuesday wednesday we would make a bunch of progress on what we were working on Thursday we'd be giving demos and refining it and Friday we'd write a tech report so there's a

whole string of tech reports that we wrote over the course of maybe six or 12 months of really working together intensely. Even if one of those weeks failed, you know, we'd have our coffee Monday, Tuesday, Wednesday. This didn't work. We would know why it didn't work and what it was that we needed in order for that thing to be easy in the future. And that goes into the hopper for the next Monday's coffee. So we developed a wide range of programming tools and applications, some foundational stuff. So we had a graphics editor called Hot Draw. Because we had this graphical interface and everybody had been used to text interfaces for so long. But now we had high speed graphics. Oh my goodness. What can we do with this? So we kept making graphical

interfaces, but it was hard to make graphical interfaces. Yeah, I have a photo of early hot draw. Yes, absolutely. And this reminds you when I look at hot draw, this, you know, like these boxes and arrows, they do remind me later of things like UML and a bunch of just the, not the exact ideas, but visualizing. And of course, later, I think these days people don't use UML, but you still, you just go to the whiteboard and you draw out boxes and arrows and how they connect.

Sounds like, so you did this back in, in 80s. seven or something like that. Correct. And because we had high performance for the time, graphics primitives, the magic moment out of Hot Draw was we drew a series of rectangles kind of on top of each other. We selected every other one.

We clicked on it and we started to move it back and forth. And because we could do maybe 10 hertz animation, it was smooth. and you could just see half of the rectangles, you know, kind of moving behind the other half. And it just, this is so hot. We were just really excited about it. Oh, that's why that's what you called it, hard draw.

That was the name because that was the reaction to being able to see this smooth animation. And before that, writing that kind of smooth animation was a bespoke thing and took a lot of work. And with this, you subclass figure and now you have something that works in the this 2.5D world and away you go. Those figures, though, were meant to represent some thing in the interface. It wasn't just a rectangle. It was a processor. It was a generator or it was a whatever. And then you click on it and you get these handles on the figure, which, each of which represents some way to manipulate the state, not just of the graphic thing, but again, of the, there was intended to be meaning behind it.

So you'd have a handle that would raise and lower the temperature and another handle that would change the pressure or whatever domain you were working in. And then you had, it was a boxes and arrows model, so you'd have connections between things. And the connections, again, were intended to be semantic, but would follow the figures around. And actually the words figure handled,

drawing, Ward came up with those. Mine were something pedestrian, drawing object, drawing handle. I didn't have good words for it. And this was where the Thesaurus came in was, Ward would think about, okay, this is like figures in a book. You know, we had an analogy. There was a metaphor to what we were doing. But in the computer world, you can, you can have figures in figures. And do I understand that you actually had a physical pizarous? Like a book. Yeah, yeah, an actual book with words in it.

You would actually, as a programmer, reach for this book with words and open up to find better words all the time. Was this just you doing it? Or the programmers in general have, like, people that you knew that they also have the satiris. We were on the far end of the obsessive scale for this. There were other people, certainly, who were fighting for the right words. But this just reminds me of how programming is just more than just, you know, like writing code, how you need the skills of, for example, if you are well read, you can probably write more expressive programs.

Or if you're not well read, having a thesaurus. Of course, you could do it online, but I assume that by opening up the book and looking through and reading a lot of other, you know, words, you're very very good. the cabalier will start to grow, therefore making you a better program or someone who can write a lot more understandable or maintainable. Part of the goal of programs is to communicate intent to other human beings and now to models as well, which is a much more open-ended problem. We understand a lot more about how to communicate to other human beings, whether we apply that understanding or not. We don't understand it all how to communicate effectively to models and people are trying out all kinds

of things which is that's great that's what you do yeah and then later ward went on and he got very much involved with design patterns i can all now see with hot draw how you know the design patterns in the gang of four later you see boxes and arrows how i see some resemblance on being able to visualize objects on on a monitor yes all of the pieces were working together for us The patterns work, I had become interested in Christopher Alexander at the University of Oregon. I couldn't afford the timeless way of building, so I read it standing up in the bookstore over the course of several visits. And Ward had also been exposed to Christopher Alexander in patterns. Alexander wanted to build, wanted buildings with a certain spirit to them.

He talks about it in kind of mystical terms, but that's okay. And he hypothesized that if people made their own decisions about the design of buildings, that this spirit would exist in a way that didn't, when the architect would say, oh, well, you know, tell me what you need in a building, and then I will program myself to dream of your perfect space, and then I'll tell you, I'll bring to you the solution. The way he wanted to work was to empower people. to make decisions within constraints,

like me designing a house, I'm going to have roofs that fall down and walls that don't match and whatever, because I don't know. So I need constraints, but I know more about my life. So I should be the one making the decisions about, oh, family dinners are really important.

Oh, so this is in the domain of architecture, like strictly physical buildings. buildings. Wow. So you got a lot of inspiration from this domain, even though software is very much a virtual that's in our head, right, or in the computer? Right. So the patterns are the constraints. You can't just make any decision. You make particular decisions at particular times based on the constraints that come from the decisions you've already made. And that creates constraints for the next decisions that you make. We wanted that for the users of programs, taking this small talk personal computer ethos to the next level. And so we were consulting

on a project that wasn't going well at Tectronics. Some programmers were writing software for some test engineers and it just wasn't going well. So Ward came up with the initial set of patterns that we would use for designing a user interface. Again, graphical interfaces were brand new. Nobody knew what to do. There were all kinds of crazy things coming out. In music school, we learned about the evolution of musical notation. And when musical notation first came out, before then it was entirely an oral tradition, then musical notation was invented. And some of the most complicated music ever written was written in like 12, or 1300 right after musical notation had been invented because nobody knew what the limits were.

And then they settled down. It's like, okay, a four part in motet, that's fine. We don't need to have 60 different instruments doing 60 different things all at the same time just because we can. Well, it was the same kind of way with these user interfaces. Nobody knew how to organize them. So we gave this initial set of patterns that it wore it. come up with, and we talked about Christopher Alexander in patterns, and I ran across a copy of notes on the synthesis of form at Powell's books in Portland and devoured that, which is kind of

the theoretical underpinning of patterns. We handed the patterns to the test engineers and said, okay, we're just going to start over. Use these patterns to break your process down into windows with pains and we were careful to only allow them to do things that we knew that we could implement. So they couldn't come up with anything. The pains had to be lists or text or waveforms. The waveforms were special, but that's okay. We could do that.

Each task that you had to do in this testing process would have its own window. And so there was, you know, four or five different patterns. And they came up with an interface that was eminently implementable. And they felt like they owned it. And then the small talk programmers would look at that and go, okay, well, how do I implement this? How do I implement that? So that was our first foray into patterns. People get really fussed about this transfer of responsibility.

They want to think, I am the designer of interfaces and I worked hard this and I want to ask you a bunch of questions and then I want to cogitate on that and then I'm going to bring you the solution and then you'll thank me and pat me on the head. Of course that doesn't happen. Your understanding of somebody else's problem is bounded because you're not in the middle of it. You don't have the same skin in the game. If you're not semiconductor test engineer, you don't have as much skin in the game as somebody who is because they're going to have to be using this interface for a long time after you're gone. Yeah, there's also this concept of the fly-by architect on teams who, you know,

this very senior person has built a lot of stuff and the team is struggling. They call them and they call him or her in. This person comes, does some suggestions that kind of flies off. So the seagull. The seagull. The seagull, because you fly in, you make a bunch of noise, you scrap all over everything and then you fly out. Yeah. And you drop skin in the game.

Yeah, and it's interesting because we, anyone who's worked in teams of a certain size or certain tenure, you see it happen. And it doesn't really matter how highly skilled that person is. There might be a few exceptions, but generally, if you don't have skin in the game, you just make different decisions. And then after Tectronics, you worked at Apple. I only realized this about you. How did you get into Apple?

This was in 1987. It's a very exciting time from my research. How did you get in there? What did you do there? So Small Talk was. going up like a rocket at that time. Xerox had developed small talk. It handed it to four I think companies to see can you also implement it or is this something special. So HP, Apple, Tectronics and blanking on the fourth one. HP really didn't do anything with it but Apple and

Technronics ran with it. So Apple had its own implementation of smallpox, and they wanted to not commercialize it in the sense of selling it, but commercialize it in the sense of having something that this was right after the Mac had come out, something that you could use on a Mac. And so I knew about that project. I was getting too big for my britches at Techronics. I learned a lot, you know, there's a, there's a, there's a, There's a thing, there's this kind of compression that happens.

When you're growing faster than the organization can recognize that you're growing, but also you're not growing as fast as you think you're growing. And eventually that gap between how people see you and how you see yourself and then somewhere in between is how you really are, if those gaps get too wide, you just have to move. So I was ready to move on. So I contacted Apple and I worked for about a year on the Small Talk project, which ended up going nowhere because it really didn't make sense. Smalltock could work in quite a small memory footprint,

but the only developer tools Apple really needed was a C compiler, Pascal compiler. Because that's what they built their software on, mostly C. That's what they built their software on. That's what everybody else did. There was a thriving third market for other developer tools, but this small talk wasn't going to really do anything for anybody, maybe school kids or something, but it wasn't. It wasn't driving Apple sales.

People who bought Apple computers typically didn't want to do small talk. Correct. So we talked about the client of small talk. I'm sensing around this time, It's if, you know, like as personal computers started spreading, it's, it seems like it just remained the niche, right? No, it was quite strong at that time. He was growing fast. Lots of people, like relative to the previous year, were using it.

A company had spun out of Xerox called Park Place, which was selling small thog. as a big ticket item for developers. And this is before there was open source out there. So the idea that you could charge money for a language implementation was a lots of people were doing that kind of thing. And this was running out of that same kind of playbook. Okay. So it was still doing it. It just didn't make sense for Apple's customer base.

Correct. And their hardware. Yeah. Also, though, at the same time, a bunch of, of the X X X X Xerox people had come to Apple. So my friend Larry Tesler was there. And by friend, I mean, bitter enemy, who I respected a lot. Sometimes, you know, there are people who just raise the hair on the back of your neck. And Larry Tesla was one of those to me. And I don't know if even the feeling was reciprocated. He passed a few years ago. But so I never got a chance to talk to him.

But I talked to him, you know, we would check in afterwards. Anyway, he was the head of the Advanced Technology Group at Apple at that time. Alan Kay had moved to Apple and was working on a programming language for kids, another programming language for kids called Playground. Dan Engels was there. So a lot of the Xerox folks were at Apple, and I heard about Alan Kay's project and thought that was a dream of mine. Byte magazine had an article on Smalltalk.

I read about the development of Smalltalk. The project started in like 71, and it was 1980 before they released anything at all publicly. And just imagining working in that environment just seemed like heaven to me. So I moved to the Alan Kay's playground project. Now, I was horribly ineffective. ended up getting fired from that job. No way. Yeah,

oh, sure. As a programmer, you being inefficient, what happened? I wanted to do my own thing. And this was still, you know, I'm still in this punk mode

where I'd listen to somebody else's ideas and I'd go, yeah, I don't think so. I have a better idea. And if you're working by yourself, that's okay. But if you're working,

in a team, that's not okay. So it came to a head. I was the program chair for the Uppsla conference, which we probably should have mentioned earlier. There was this conference, and it was the hottest conference and everybody who was, anybody was, anybody was there, and it was growing fast. And I was involved in it, kind of stumbled into it. But I was, in 89, I was the program chair for Uppsla, right, for Upsla. And, I spent a month just reading papers while ignoring my duties to the playground project. And that was kind of the final straw. Okay.

You're not helping us. So you need to move on. And then the conference happened and my second child was busy not being born. So I didn't even get to attend the conference. But I'd heard about the playground project. So I moved to the playground project and did a little bit to help build this programming language for kids. That was the next thing beyond object-oriented programming. You would call it, today you'd call it reactive programming.

So you couldn't send a message. You could only raise some condition that some other object would be waiting on. So it's like PubSub, but that was the only control mechanism. And I wanted to ask you about this was around this time CRC cards. What are CRC cards? I know they stand for class responsibly collaborator cards, but what were they? And how did you come up with them? You have these imperative programs and you have a flow chart which represents accurately,

if kind of verbosely, the control flow in imperative program. Now we have these objects and you send messages, which are polymorphic, so you don't know exactly what code's going to be invoked when you send a message. And people were like, well, how do you even visualize, internalize? For me, I'm kinesthetic synesthesia. So I can feel in my body. If I'm looking at some code, I can feel in my body. It wants to go this way.

it's, ugh. Yeah. Which is it, you know, I don't know if I've met anybody else who describes their experience of programming the same kind of way. But there we go. How do you get a sense of however you internalize this of what's going on in this program where you can't just say we execute this line and then we execute that line? Because as soon as we send a message, we don't know what's going to happen.

So Ward came up with the idea to write down on cards, index cards. Here's what's going on. Because we would talk this way all the time. So, you know, we've got to have a rectangle and it asks the renderer to do the thing. And then that goes into the pipeline, which the bab, bab, bab, bab, bab, bab. So we would talk with our hands a lot. So he said, well, why don't we write these things down on cards? So a big challenge in object-order programming is dividing the responsibilities.

Because you're moving the computation to where the data is saying, well, this object does this and that object does, that is a really critical decision. Because you want the computation near to the data so that there's less coupling between them. Which is a lesson that I think kind of got lost in the noise. That's the fundamental design move in object in designing. object during programs. And I think I stand behind that. So have the data be close to where it's used, where the computation will happen. Backwards. Backwards.

Have the computation move to where the data already lives? Have the competition move to where the data is. So like if you have a rich object with lots of data inside of it, for example, you want the computations to move there. So you want the like objects to invoke and just get the data and do whatever computation they need to. If I'm going to operate on stuff that's on the inside of a rectangle, like area, do I have height times width scattered all over the universe? Or do I have an area inside the rectangle that does heighten width?

At the limit, now I don't care that the rectangle has heighten width. That's hidden from the rest of the world. Like I can represent the rectangle with two corners. or I can represent the rectangle as a top left, a height, and a width. To the rest of the world, it doesn't matter as long as they both respond to area. So now I can come up with another representation and another representation, and the rest of the world doesn't have to care. If I've moved the computation where the data lives. Yes, and that means you can have looser coupling.

Correct. Understood. It was a good lesson. Yeah, yeah, yeah. And even today, because everything that we do is under the hood, almost everything we do as objects, or a lot of it is object-oriented. And I don't think we think about these. Yeah, I see a lot of criticism of programs written in object-oriented languages

that aren't criticisms of object-oriented programming or design. So after Apple, you moved to a company called MassPAR, and the thing that I notice here is unit testing. This was the place where, as I understand, you came up. with something called S unit. While I was at TechTronics, I got interested in testing. At that point, testing was a sociological divide. If you got A's and B's in computer science school, you got the program.

And if you got C's, you had to be a tester. So it really was like a status. I'm not going to test. I'm one of these guys, not one of those. But I got interested in how would you automatically test programs? how would you get a sense of confidence in what you were doing? So I tend to be an anxious person, and the more complicated my programs were,

the more I had to be anxious about. The more experience I had with what kind of bugs could possibly exist, the more anxious I got. And I thought there was just some way to kind of quell this without pills. That would be great. I tried out a bunch of different approaches to writing automated tests. At that point, in addition to this, this status divide, there was a tool divide. You had testing tools, which would have their own

kind of language in some way to connect with the program that was under test. So I tried this and that and the other thing. It was actually after MassPAR that I think is all ancient history. So we'd have to go, you know, dig through the archaeological layers. I started consulting and I was going to tell a client that they should write tests. I was going to fly out to to Chicago the next day, but I didn't have any way for them to write tests. So out of these five or six experiments that I'd done, I synthesized test case, test suite, and test result. That was the, it was like three classes and 12 methods, but it was a framework where

you could write tests that would execute isolated from each other, fully automatic, and give you a roll up of the results of it. So this was pretty much a unit testing framework for small talk. It was written in, yeah, the first version was written in small talk. So MassPAR was a Silicon Valley startup venture funded, intended to build an entire new architecture, which was SIMD, single instruction, multiple data. So we would have a torus of processing elements up to 16,000. So you have 16,000 and they're connected in a toroidal grid.

So you could talk to the processing elements in the left, right, up, down, and diagonally. And it looks very much like the Nvidia architecture now. But this was way back when, and it was just too early. So three years of that building programming environments for high performance computing. So the intention was to get the kind of performance you'd get out of a cray at that time. But for a tenth of cost. And they needed a programming environment. So we built a programming environment in Small Talk.

They did some really cool stuff. You could single step a Fortran program and build a performance profile at the same time. No way. So you built a runtime that allow you to do also. in small talk to intrepred, for example, program programs and run them? No, we had a standard compiler, an optimizing compiler, but because we had, we controlled the operating system,

we could build really low level probes to collect performance profiling data. So we could get line level profiles for these Fortrend programs running on 16,000 processors and great gobs of data. That's awesome. When you're going from not just like years going lower level, you know, like building infrastructure that runs programs. But then I want to go back to S-S-unit. So the concept of S-unit, these concept be a particular test case, what was it, the test case? Test suite and test result.

This really became sticky because then there was J-Unit, which you later created with Eric Gamma. and there's a whole sweet N-unit for, I think that was for dot-net, Xunit.net, all of them took over some of these ideas and a lot of modern unit testing frameworks are built on some of these ideas. Why do you think it was so sticky and why do you think it wasn't created beforehand? So beforehand, because of this social divide between programmers and testers, There was a lot of incentive for the testers to have their own language. This is my tool.

I know how to run it. I'm going to run it. And it was very adversarial at that time too. And kind of patronizing. Like you're a programmer, you can't be trusted to test. You know, you'll just say it works fine. I'm going to be the adult supervision, you know, and sometimes the programmers really did act that way. So, you know, hard to argue with.

But I think that encouraged this idea that a testing tool is its own world. The inspired decision to use the same language to test as you're testing. It was a natural decision because I was in small talk and you should be able to represent anything in small talk. So, you know, and I was just used to, how do I represent this as objects? Sounds like small talk as a language has been early to a lot of things. I sense a lot of innovation coming from small talk because it was one of the first languages that did have objects, but it was a very simple language. So you needed to build a lot of things, which then led to representing a lot of things, to talking about them, design patterns. And now also, you know, being able to write your test environment or being forced to do so if you wanted to do that.

Well, there was an ethos that went along with small talk. So if you didn't like the tools, if you're running the debugger and the debugger doesn't have some feature that you really need right now, you just pop on the stack, implement the feature that you want, and then get back to whatever it was you were doing. That was just a natural thing because there was never this huge gap. You know, imagine today I'm using C compiler and I realize, oh, I wish C had this new feature. we're embarking on a multi-year project to go and like huge barrier to entry to go to the next level. And in small talk, by design, for example, you have pop up menus and you can see all of the options right there. That's a deliberate pedagogical choice. It says, okay, well, you know about cut and paste, but you don't know the other things that you can do right here.

So the menu doesn't just give you cut and paste. It gives you all the things that you can do as a way to encourage you to learn about them. Because eventually you're going to, I see this format item here. And I said, well, what does that do? So it was very much part of the small talk ethos that the system would teach you as you kept using it. So, yeah, it was very natural to build the testing tool in the language. And of course, you have to kind of bastardize the language a bit. Here I've got this class for some test case, and I have a method, which is one of the test cases,

and it starts with T-E-S-T, which is kind of magic, you know, and this is getting squidgy. And then when you execute it, you create one of these objects. You send it set up because you don't, you know, may have to build some stuff. And then you send it the test T-E-S-T-S-T-something or other, and it executes that one thing. And then you, then assuming, well, then regardless, you run the tear down from that. So it's not, it looks like the syntax is the same as the language. The representation of the tests, you kind of borrow from the representation of just any kind of code. And then you interpret it yourself.

So it's, it's in the language, but it's not really in the language. the same time. But people don't think about that. They just think, I subclass this. I give a method with the annotation of test or starts with TST and then it just starts working and that's fine. I want to jump to a few years later from to 1996. You start to work at a project at Chrysler and this is where you met Martin Fowler. What was this project? I'd actually met Martin Fowler a little bit before that. So as early as the first Uppsla conferences, the question of how do we manage projects with objects differently than we manage projects with the previous generation of tools? The previous generation of tools definitely gave you many fewer options for change.

You'd still have to change code, but it was just a lot harder compared to working with object oriented programs. So what is the methodology? We had the structured analysis, structured design. what is the methodology for objects and how should it be different? That was the million dollar question at the original 86 Upps law. By the time 94-95 rolled around, we were starting to get a clue what that would look like. There were, I think, the rational and unified process or the things that would go into the rational unified process already existed by that time, which was Brady Booch was involved in that.

Brady Booch, Yvara, James Rumbaw, Evar Yacobson. So people were coming up with some kinds of answers. Ward had come up with his own answer called episodes, written as a pattern language, because we were like, you know, I don't have a big bag of tricks. I have to keep using them over again, and the same is true turns out of everybody.

So you can find that episode, on Ward's C2 site. It's really interesting to compare that because I borrowed heavily from that. I borrowed from everything else that I had seen and experienced. But at that point, I'd been, when did I leave Massfar? 92. So I had been an independent consultant for four years at that point. And there were a couple of workshops held in Snowberg.

I don't know why we picked Snowbird, but somebody else did, about this methodology question. And I met Martin at the first one of those that I attended. And his introduction was, it's just the classic Martin introduction. He said, I am the only person here I've never heard of. And he was already doing some great work on analysis patterns at the time, which I knew about. So I was excited to meet him. get to this Chrysler project.

The project's important for Y2K, but it's not clear that it's going to be finished in time. Martin was already there as a consultant. I had met Ron Jeffries doing small talky stuff. I don't remember exactly how we met. But long story short, I came in as, you know, lead consultant or something, restarting that project in a very different development style.

And for that style, I took everything that I knew that was useful and cranked it up to 11 and discarded all the stuff that I couldn't prove we needed. So that was the value system behind this new style of development. Martin and I would visit there periodically. Ron was there full time. I was originally brought in as a performance consultant because I knew a lot about small talk performance. And they were using a database called Gemstone, which it was small talk objects, small talk semantics, but coupled with persistence, transactions, indexes, all that database, good stuff.

But it wasn't going fast enough. So I said, well, where's the test case that makes sure that I don't break something if I make some changes? And I said, well, actually, it's not computing the right answers yet. And I said, well, then I can make it go really fast. And they didn't like that answer very much. Anyway, most change I've ever seen over the course of one week. At the end of which, everybody was exhausted. They've been working very long hours.

I said, send everybody away for two weeks. Tell them to get some rest. We'll come back. We'll throw away all the code that we've written so far and we'll restart. And we restarted on this three week cadence. Every three weeks, we will. we would have more test cases specified by Marie, the payroll expert, would be working. And then we'd start another three-week segment and another and another another.

Now, it turns out those 11s that we turned everything to, there were several matches beyond that. But it was just that was the most intensely, we could imagine replanning, integration, deployment, refactoring and so on. The ideas that went into that was the synthesis of all these experiences that I'd had. And then this was from Ward when the two of you started to pair and pass the keyboard and decide on all the different things that you're going to do, your experience with tests as a concept of that it doesn't need to be the testing team that does it themselves, but you can do it yourself in your own language, which was just new.

And so all of these ideas just all came together. Yeah. And then when did you give it a name? It started going well. At first, I was like, I was excited. I was scared. I was excited. Then it started going really well.

So like the project started to go visibly well. Yeah, yeah, after my least six weeks. And then I was happy to be telling my friends about it, this new style of working that we're doing here at Chrysler, this new style of working we're doing here at Chrysler, this new They got kind of old to say that over and over again. So now I'm back with the Csaurus trying to figure out what are the words. I thought we were really on to something that was going to be big. So I wanted to protect it.

Apologies to Grady, who's a good friend now. But I didn't want Grady Boots to ever say that he was doing this thing. So I had to pick, I had to pick a moniker that was unattractive enough that somebody would try and steal it. And this is about the point at which, extreme sports. You're now this punk again. Yeah. Well, yeah, I still am. But I'm just an older punk now.

Yeah, yeah, but a little bit of thumb the nose at the establishment. Extreme sports were there. I kind of like the analogy with extreme sports because you don't just hop on a snowboard at the top of some avalanche and the first time. No, you have to be supremely prepared. You have to have done all of your research. And then if you have these outstanding skills, then you accomplish things. And training and all that. Right.

That seem impossible and are impossible if you haven't done all the prep. So it's accurate. It's edgy. It's that word extreme and hence extreme programming was born. So that's the extreme part. Extreme we had, I knew that a bunch of people wouldn't like it, but that's okay. I started out calling it development, which I still kind of like because there's more to delivering value with software than programming. but the methodologies

at that time treated programming as this clerical task we'll draw these diagrams and these diagrams and build this thing and the 14 ways to visualize this and then there's some programming and then we'll draw some more diagrams and I thought programming

sitting fingers on keyboard staring at code that's where I do my learning because that's where you can no longer fool yourself that you actually understand. Either you compute the correct value or you don't compute the correct value. So I wanted to elevate that moment of reality meets program, and that's where the programming comes from. Now, from very early days, I also called it XP as a way of separating from the downside

of both of those words, extreme and programming. So we can just call it XP and it's more of a generic thing. Not long after that, Microsoft releases Windows XP. And there's an alternate universe in which I sued them and succeeded. And there's another alternate universe in which I sued them and failed and bankrupted myself. And my children all starved to death. Right, right? Because this was right around the year, late 90s. And XP came out, yes, soon after, I think, 2000 or 2001,

and something like that. When did XP extreme programming, how we recall, started to become big. Was it as you gave it a name and you started telling people or then there was your book, which came out in the year 2000?

I remember the first talk about XP I gave. I had some flyers to hand out. So I think it was at an oopsla on a panel or something like that. And I talked some about XP. And afterwards, people were, give me a copy.

No, no, the reaction to it was just tugging on my shirt wanting a piece of this thing. And I think the XP had exquisite timing in that the dot com, the upside, not the bomb, but the upside of it was just starting to hit. They looked at other methodologies that would say, you know, very carefully prepare, do this analysis document, do this design document. do this design document, then a bunch of coding, then a bunch of testing. They could tell that's never going to work in a world that's changing as fast as the

internet wave starting to crest, starting to come into, you know, this super hyper growth. On the other hand, we know that this cowboy style of just, you know, you have the Jolt Cola, rest in peace, Jolt Cola, cowboy, you have a bunch of people. programmers, they do incomprehensible stuff. They don't talk to anybody. You just slide pizza under the door and then you get the code out. That's not going to work either. Here's this thing that looks like it's kind of in between the two. There's discipline to it. There's iteration to it. There's transparency to it. You have ways of steering what goes on. You have ways of tuning the process. You have all these tests to make sure that stuff actually works. You have frequent alignment between people, whether it's, business people and technology people or technology people with each other. Okay, I can see how this could work. And so they could see the internet is exploding and I can use XP to take advantage of that opportunity in a way that I can't.

I don't, there wasn't really another alternative to it. Basically, XP was giving you a way to move pretty fast and nimble, but also have a sense of stability, not just going wild while with your tests there. you had the iterations, the planning, the learning. And then when did TDD come along? Because there was a book that you wrote that came out, I think, two years later, test driven development by example. And how did it relate to XP?

So TDD was an earlier, test driven development, was an earlier rediscovery for me. Remember, I was a kid, I read all these books. I remember one of the books my dad brought home, and I still haven't found a copy of it, said, here's how you program. This was back in the days of tape to tape. So you'd have an input tape, you know, like time cards, and then you put it through the payroll program,

which would write an output tape, which was like dollars for checks, dollars for withholding, et cetera, et cetera. Yeah. So it was always, and then really back in the day. Really back in the day. And you'd have these long strings of this. And it's actually functional programming because you can't change the input tape.

But operating payroll or operating accounts payable or operating inventory was a process of, I take these tapes, I feed them into this program. I take the output of that, feed them into this program and blah, blah, blah, blah, blah, blah, blah. And then you'd get- Really manual, like actually. Physically pulling a tape off and moving it over. Yeah. And so it said, here's how you write one of the,

programs is you take an input tape, an actual input tape that you need to process, and you manually type in the output tape you expect that to generate. You say, okay, well, this number of hours should, I should have a record in the output that like this. I see where we're going with this. You're defining the output. You're- Before you start on the program.

Yeah. So first you need to know what do I expect. How can I validate it? Correct. I had read that as a kid, didn't understand. dittly squat, but it's back in the back here someplace. I wrote S unit for the first, started using it, gave it to Hal Hildegbrand, one of the smartest programmers.

I knew I didn't figure he would need it. He used it. He loved it. So I knew I was on to something with, with this testing framework. And then I was just kind of farting around and remembered this typing in the output. tape first and mapped that onto the testing that I was doing with S unit and went, well, if I followed that pattern, I would write the test before I wrote the code. And I can remember laughing out loud because it was such a stupid idea. Why would you write a test that you know is going to fail?

You don't even have the classes defined yet. You don't have the methods defined yet. It's just, it's going to fail a bunch of different ways before it could possibly succeed. Cool. Let's try it and see what happens. So I used stack as my first example. So I have a stack new and I push something and I pop and I should get the same thing back. Okay. And then I went to program it and no. Okay. Well, that's easy to satisfy that. What's the next one? No, you push two things and you get them back in the right order. okay and this and uh blah dupe pop top is empty and finished where's the anxiety oh just gone oh for the first time wow i can't imagine another test case that wouldn't pass so i'm really i'm finished so i'm really i'm finished and I feel great.

I feel finished and I am finished. Wow. Going from, this is a stupid idea, let's try it. Absolutely. No, I met a comment.

Always try your stupid ideas. If you can do it cheaply and reversibly, jumping off a bridge. This is not a reversible decision. Not talking about that. I'm talking about stuff like this where you're just like, here's a stupid idea. 99 times out of 100, it'll fail.

But that one time, you won't have any competition because nobody else is stupid enough to try this idea. Part of this punk attitude, I don't care what you think about this, has enabled me to just try lots and lots of stupid ideas. And most of them you don't see. But there had been a string of them, which worked out way better than they would have expected to work out. Well, and then a bunch of other people try these ideas as well. you know, like I think TDD is a good example where there was a time where shortly after you wrote the book about it as well. It was a super popular book. I still remember I think I had a copy as well back in the late 2000s. People were like doing, you know, group exercises, developers were developing

accordingly. Over time, it probably dropped, I would say in the 2010s I saw fewer and few people doing it and it almost went out of cell completely. And now with agents, the idea is back because it turns out it might take more time what not, but agents, agents can do that, but it's a, it's pretty useful for them to test themselves. It costs tokens in the short run, but it can save them in the long run because one of the classic genie mistakes is stuff doesn't work. So how do you, how do you pull in the reins a little bit? And why did TDD go out of fashion? I think there's a big part of it is I work on something for a while and then I

switch to something else. That was true of patterns. It was true of J unit. It was true of TDD. True of XP. I just move on to the next thing. So I moved on to the next thing. TD's out there.

And then there were people who used it as a moral cudgel. Like you should be, if you're not using. using TDD you're not professional. And that's just such bullshit. People can write very good software with a wide variety of workflows. Now there's advantages and disadvantages to different workflows. The sweet spot of TDD is this combination of discovery and realization. I kind of know where I want to go.

I don't know exactly I'm going to get there. But I do know the first step. So I take the first step and that teaches me something. something which lets me take the next step and that teaches me something. If you can just go implement, implement, implement, implement, fine. There's other workflows that are fine. If you just want to sit there and go learn, learn, learn, learn, learn, learn, I don't think that works very well, but you certainly don't need TDD. It's when you have this rapid alternation between I do a thing, I learn a thing, I learn a thing, I do a thing, I learn a thing, I do a thing, I learn a thing, I do a thing.

That's where TDD is really powerful. But it's not a moral decision. It's a practical decision. Test urban development is one of Kent's most lasting contributions to how software is written and shipped. And today, with the genetic development, it's more important than ever. If you work with agents, your job is no longer writing code. It's specifying and testing it. This is where I need to mention our presenting sponsor, Antisys.

Antisysis is the most effective method of verifying a genetic code today. Let me explain how it works. Antisicis runs your whole system in a hostile system. simulation. By doing so, it finds every bug before your users do. And because the simulation is fully deterministic, antisticism doesn't only find bugs, it gives you a perfect reproduction of every issue. I know this sounds closer science fiction, but it's actually hardcore engineering under the hood. Jane Street, Fly.I.O. and the etc. community ship agent written code with full confidence because they know it's been verified by Enticisysesis. To see more case studies and details, head to

antisicis.com slash pragmatic. That's antithesis.com slash pragmatic. Kent has spent his career building the primitives that the rest of us now take for granted, unit testing, design patterns, refactoring. And building on solid primitives is exactly what our season sponsor WorkOS is all about. If you're building any SaaS, especially an AI product, sooner rather than later, you'll need to get around building enterprise features, things like auth for apps and agents. Workerwas handles it. S.S.O. Skim, fine-grade authorization, built for how agents actually operate. The fastest growing AI companies, Anthropic, Open AI Cursor, perplexer,

City already trust WorkWest to solve these problems. Check out WorkOAS.com. And with this, let's get back to Kent and where the Agile Manifesto came from. I wanted to talk about the one thing that you're also known for. I think that 17 people wrote, but you're the first one listed, the Agile Manifesto. Can you take me back to what happened in Snowbird? What was the industry like and what made all of you come together? There were a bunch of people.

Remember, we were talking about what is. the methodology for objects and you had kind of this dominant rational unified process which i say is neither rational nor unified nor a process but it's a separate mostly i did that to tweak people's noses but that was the adult way to do development and there were a bunch of us who if you talk to grady if you talk to jim and you talk to evar how they would apply it is actually looks a lot like the way that I would develop. But it doesn't matter what you would do. What matters is what the people who read the stuff that you write would do. And it was being used in a very waterfall style, a bunch of analysis, a bunch of design, bunch of implementation, separate testing, disaster, over and over and over again.

So a bunch of us looked at that and in our own ways, in our own sequence of time said, no, we shouldn't do this. You should do something else. And we started making enough noise that we started getting attacked by the rational unified process people. Well, you don't want to do that. You want to do my thing. And here, I'll sell you tool for millions of dollars to help you do it. I can understand why they would attack. But we started realizing, okay, if we're all going in this similar kind of directions, scrum, feature-driven development, we had to come together. We had a meeting in Norway where we got together, gave a presentation.

This is towards the end of the time I was living in Europe. I lived in Switzerland for two years, 97 and 99. So in 99, we flew up to the tip of Norway and took the Hurtigrude Gru. Ferry, which I practiced saying, and I'm sure I still butchered it, took this ferry down to Bergen, and it was light all day, all night, bucket list item. Definitely take this if you ever get a chance because the scenery is just absolutely spectacular. But we were meeting and talking about, do we have enough in common that we could actually do stuff together? The sense of that meeting was, yes, we should do something together, but there's still a lot of

friction and there's a lot of divergence. You're talking about people with some healthy egos. Strong opinions. Me, not the smallest among them. So when we got back, Jim Highsmith and Alistair Covern convened another meeting at Snowbird, same place that we'd been having these kind of methodology kind of meetings for a while. And so we all went there and other people have told the details of the meeting.

I'm not going to be able to recall them precisely enough. So find one of those recountings of this. But it was not going well. For me personally, I had a nasty sinus infection and I was on some heavy-duty drug. So I don't really remember much of the meeting in general, but I knew that things weren't going very well. Because there's all these people and they, I want my stuff in. No, I want my stuff in.

And that contradicts your stuff. So we all, we took a break. We walked out. And Martin and Jim, Highsmith, stayed behind. When we came in from the break, there was the basics of the manifesto. You know, that format, we value these things, but we value these things. more and the four specific items that was that was all in place and then the and that was just a magic moment that I had nothing to do with and then we came up with the principles and I remember the

the only word in there that's mine is the word daily when it talks about daily interaction with users I don't think I had another thing in there but it came time to publish it what order the names go Like, it was alphabetical, wasn't it? Absolutely alphabetical. So, so when people say, oh, you're a signatory, I say, no, I'm the first signatory alphabetically. And then what was the impact of the Agile Manifesto? Oh, instant.

Instant. People were so excited. Again, were now the rumblings of the dot bomb. Dot com. It was still going up. I think so. It was towards the end. But definitely towards.

the end. But people were still looking for like, how do we do this? How do we do this stuff? How do we build software quickly, cheap, reliably? Everyone's searching for that. With, with optionality. With optionality. Because when things are uncertain is exactly when options give you the most value. And we had a story about how you could preserve optionality. All of us in our own separate ways. That was another case. So, actually, XP was the first time I had people tugging on my shirt. J unit was another one, which was S unit. I had S unit.

Eric was using, Eric Gamma was using this new language Java. We were flying to America. He was going to show me Java. I was going to show him S unit. So we developed J unit testing itself in itself on the flight from Vienna to Washington Dolos. Wow. And when we landed.

On the plane, no internet. No internet. Two and a half hours of battery. Like the clock is ticking. Yeah, no power adapter in the seat. Oh, it was like horse-driven computing. So we landed and we gave Jay Unit to Fowler, who was at that Uppsla. And the next day, I hear you have a Java testing framework.

Can I get a copy? So we made floppy disks, three and a half a few. finch diskettes and we were handing them out as fast as we could because there was so much demand for it. So that was the second time I've been through that kind of a demand product market fit call. Yeah, yeah, exactly, product market fit. And then Agile Manifesto was the next version of that where people were just really excited about it. Beautiful piece of marketing to have the original signatories and then if you wanted to sign it, you could sign it for a while, I think.

close it after a while because they got too many people. Right. But that meant that people felt invested. They were already bought in. They'd already attached their names to this thing. It's interesting, right? How being invested, being able to contribute or feel your contributing, it can make a difference. It has made a difference.

And for agile, for sure. So one piece of follow up is that word agile, part of the argument. Yeah, argument. was around what are we going to call this thing? And somebody suggested agile. I don't remember who, but probably somebody does. And I objected. And what I don't like about it,

it didn't like about it then and still don't like about it, is it's not defensible. Nobody's going to say I'm not agile. Oh, no, I prefer rigid development. Oh, I prefer inflexible development. No, everybody's going to say that they're agile, which extreme doesn't have. have that problem. If you work hard at your skills at being able to pair and being able to design

incrementally and being able to test thoroughly and build tools and make that investment, now you say, okay, I'm an extreme programmer. If you haven't made that investment, you're never going to say that you're an extreme programmer if you're not, but you're going to say you're agile, even if you're definitely not. So that was my objection back then and that certainly played out. word does not only doesn't mean anything anymore, it means something negative. Okay. Can we talk about that? Sure. Of the afterlife of agile. And some of the capital, you know, the capital A version, there's a whole industry that was grown that initially was meant to do good things, but it turned into a snake oil industry. And in many ways, we now have

scaled agile frameworks that are sold for massive amounts for huge companies, which, you you know, bogged them down with even more bureaucracy you can imagine. How did you see this being played out? And did you expect Agile to grow this big into both a commercial story and then all of these, like a snake oily part? I was certainly afraid that that was going to happen at the time that we put it together. The Agile Manifesto is the intersection of the ideas of the people in the room. I think there's a lot more the software development than is contained in the math.

manifest them. And I've written books and books and books about what I think those things are. Without the foundation of technical skills, you can have the best intentions of we're going to be able to replan and we're going to be able to implement in any, you know, we have a set of features and we can implement them in any order and we can add new features anytime we want and the both. You can say you're going to do that. But if you don't have the technology, Chops to write efficiently write reliable software in bits and pieces, design in bits and pieces to preserve and enhance optionality, to write your own tools when you need to do that. Those are things are technically difficult. It's like putting somebody at the top of the

avalanche on a snowboard for the first time. Well, there's a certain kind of agility as you fall down the mountain and break your body into multiple parts. But this is not really what we're talking about. You need that foundation. And there were people who were willing to say, no, don't worry about that. This is easy. You can do this. Anybody can do this. Twice the work and half the time. From my perspective, that's just a lie. Can you get twice the work done in half the time. Yes, absolutely. Is it going to be a lot of hard work gaining the skills, which aren't taught in computer science school, aren't frequently modeled in your first employer, you're going to have to work hard to gain the skills to be able to do twice the work and half the time. In the, the genie

world is just playing this out again, oh, everybody can be a programmer. Yeah, but everybody can't be the same program. Yeah. It seems like there's a pattern where when there is a new technology or a new methodology in this case, but I guess it's interchangeable. That's a technology. It's a technology that a group of people, a group of highly trained people can get really good results with it. And then they publish it and they share. This is working for us. Here's the results. There's a bigger industry going around that saying what you just said, that anyone can get these results and we will sell it to you, we'll show it to you. And of course, by the, the time you realize, for example, a company, like a large bank realizes that it's not really

working, they're heavily invested, and maybe they're actually getting some minor results, just not the same. And then I guess you can argue of like, this is the whole point of snake oil, right? Like snake oil, it does something, just not what it was advertised. Let's talk about what happened after 2001. So there was a big dot-com bus. Can you take us back to what it was like being in the middle? You were in, were you in silver? Were you in silver? Valley at that point? 87 to 97. We lived in the Santa Cruz Mountains above Silicon Valley.

Much of that time I commuted to work. Then we moved to Switzerland, 97 to 99. Then in the last part of when we were living in Boulder Creek in the Santa Cruz Mountains, we had bought acreage near my grandmother in southern Oregon. So we bought eight hectares of just trees and started developing power well, road, and so on. Went to Switzerland. Oh, we built the office and we had a trailer and then we went to Switzerland. And we came back.

So I was living in rural southern Oregon at that time. And the industry just went through this massive boom, which there are similarities, as I'm I'm talking with people with the current boom whenever you're working in AI right now. And then there was a sudden bust that, again, I've learned it from the history books or like reading back news, but apparently it was sudden. It was shocking. How did you see it? What happened in the industry? What were your friends working as programmers observe or how were they impacted?

It was horrible. For me, personally, the turning point was 9-11. I had eight months booked solid work at very high rates, higher rates than I can charge now, even with inflation. And the day after 9-11, everyone canceled. I was also finishing the house that we were building. So we were about to come up on some big bills to finish the house at the same time that all of my income disappeared. It's overnight. Overnight.

Wow. So things had already been bad. There were big bankruptcies and the Pets.com and whatever. And that was already happening. And then 9-11 just shut down everything. That was a big shock for me. And I ended up burning out pretty thoroughly, severe depression. I had a really important lesson to learn about bad.

boundaries. So up until that time, remember, periodically I had people tugging on my shirt. Yeah. You're a three really big pot of market fits where people are after you. Patterns even before that was also like that. But you were a star. I was, yeah, I was feeling, yeah. And I would get these messages. Somebody would say, oh, would J. Unit saved my life. XP was fantastic. And I love it and you're a genius and blah, blah. of all. And I'd feel really good. And I didn't get a message like that. Then I started getting messages. XP ruined my life.

I lost my job. My wife left me. I can't see my kids. I'm living on the streets. You, ma-rah, mar, mar, ma-ma-ma-ma. And then I would feel really bad. And the way I think about it now is that there's the way people perceive you and there's the way you perceive yourself.

and then there's what's really true, which is somewhere different than either of those. When people are giving you a bunch of feedback that you're more awesome than you think you are, that just stretches your head. So you see this in celebrities periodically. There'll be somebody super famous and then their head explodes. And that's that gap between how people see you and how you see yourself. And what I had to learn was the reason that people come to me with those out of proportion responses is because that's what they need.

They need a hero or they need a villain. And their need for a hero or a villain has nothing to do with me. If it wasn't me, they'd be contacting you. They'd be contacting somebody else. It really doesn't have anything to do about me. But that recalibration where I'm like, I'm trying to convince myself that I really am this awesome. No, I get feedback that I'm not. That was a serious reset for me.

So I went through a bunch of mental health problems, couldn't work, couldn't program at all. I started over with Sudoku. And eventually I could do Sudoku's uneasy. and then eventually I could do them on medium. And then I started on crossword puzzles. Wow. And then eventually I got to a programming problem. I was doing a bunch of stuff with Eclipse when it was new.

I got to a programming problem and I nailed it. And I went, oh, this is still fun. I can still do this. but yeah kind of a lost decade from 2002 let's say to to 2011

when I joined Facebook so you really went from being on close to the peak of the industry or the professional you know like mountain if you will to just I guess just finding your way

yep do you think something somewhere might have happened was it not for this sudden crash or being a dust, the sudden or was it just the intensity of everything just being pulled out of under your feet? What do you think it was? I think that people are coming to me with these expectations that I know I can't meet. That it's going to blow up somehow eventually. For sure, you can't just live the rest of your life like that. And that's what

the classic midlife crisis is, is the masks that used to wear. work that felt like they used to work. You realize, oh, they're not going to work going forward. I have to be myself. And actually, they've never worked. I was just fooling myself that they had worked. Yeah, I think that's, it's going to come, it's at 35 or 40 or 45. And mine was it, 42. But then you, in 2011, you got into Facebook. And I'm really in, by this story because at this time, Facebook was seven years old, which meant that the median age was probably like 24 at the company. And there you are an industry legend. Again, you've, you've had all these contributions, TDXB knowing how to build efficient software. Facebook is building efficient software in a different way. And now you're showing up when you're 50 with these people half your age. I assume you could have gone back to consulting and do what you've done before. I was trying to. to do the same thing. So I needed the money for sure. Trying to do the same things as a consultant that I'd done before and there was no zero interest out there. I had college to pay for.

I have five kids and I knew I was going to have two tuitions for four years in a row. I needed some stability and income. problem with book book publishing doesn't make much money yeah except in a rare cases in the guy well in in the rare cases in my case where amazon self-publishing has been invented yeah and and people buy your books in bulk but outside of that even for uh yeah it doesn't yeah i love teasing you because you're so successful i can i know i know that even if you can't take it you have to take it I am speaking here. And now here on this podcast.

So I needed some stability, number one. But number two, these people were doing nothing that was in my books. And they were running a stable site. It's not perfect. But at this crazy scale, it was stable and not kind of unprecedented. They were expanding users. and growth was expanding dramatically, and they were innovating all at the same time.

So how in the world are these, like this is a bumblebee, it can't fly according to my theories. I want to find out what's going on in there. So at that point, I'm still very curious about methodology and how people get along and software development sort of in the societal scale, but I also needed the money.

So I joined, and I think, I think I was the first, or one of the first remote engineers. There were about 2,000 employees total, 700 engineers at that time. And I just wanted to parse. How does it work that they have scale, growth, and innovation at the same time? Because I'd never seen anybody do all three. You'd see people do one of those. Two was rare, and all three was unprecedented. And apparently they weren't too interested in. No. In the prior art. Can you tell that story about your TDD class? I think you told it like many,

many years ago somewhere else. Yeah, absolutely. So I get there and I'm nervous. Like, you know, how am I going to contribute? I don't want to just,

you know, be here for a week and then get kicked out. And so there was going to be a hackathon. And hackathons often came with classes. And so there was a sign up sheet for classes and I thought, all right, I'll give a TDD class because after all, you know, you wrote the book. I wrote the best seller.

I invent, you know, blah, blah, blah, blah. And they clearly need it. I could see because nobody's doing it. Very few unit tests at that time. Which just shocked me. How can this be? So I said, I put on the sign up sheet, TD class for me from the Kent back. Just before my class was one on Argentinian tango.

and just after my class was one on advanced Excel techniques. When the time came for the classes, the Argentinian tango class was full. The advanced Excel class was full, and no one, not one, not even like a pity sign up, zero people had signed up for my TD class. So these engineers clearly felt like they had it already dialed in and they didn't need anything from this old guy.

I decided, you know what, I'm just going to forget everything that I think I know about software engineering. And I'm going to try to do things. I'm just sort of monkey see monkey do. I'm going to copy what I see people doing and get feedback and see if I can learn to develop in this different style as quickly enough. Can I relearn software engineering fast enough not to get fired? and I ended up staying there for seven years. And what did you learn? What made it work?

Because again, going back there, what Facebook did from the outside would have made no sense. They didn't have tests. At the time, they were running this massive site, somehow keeping it working. Oh, and they had young engineers who didn't have a decade or two of experience to know what mistakes to avoid. Mostly young engineers. Mostly. So they, we had some very senior people with. great leadership skills.

Uh-huh. Who could model it? Many layers of feedback were built into the system. So we had developer machines that ran the site. So if you wanted to change the color from blue to green, you could do it on your developer machine. You could check up. There was a monon-repo-ish thing.

Yeah. And so you could just change anything and see the, because it was Ph.B, you could see the results of that change in seconds. So that gave you one level of feedback. Then you had code review, which gave you another level of feedback. You could roll out internally, more frequently, and everybody was using Facebook for all kinds of stuff, personal and internal business stuff. So whatever feature you'd developed, people would start using it immediately. So you'd get another round of feedback.

Then we had this phased rollout process. where you'd start rolling your stuff out. If there was a problem, the blast radius would be limited to a few million people. Not like automatic rollback based on signals. Yeah, not the whole thing. Chuck Rossi's deployment team also was another level of feedback. You had stars. They would secretly give you a number of stars.

And if you were three stars, they wouldn't look at your stuff. But if you were one star, you just couldn't get your stuff pushed. So that was another round of feedback. Then you deploy stuff and you look at the results, like the observability, early observability stuff. So you get more feedback about what you're doing. So feedback comes in layers like a filter. And if you get enough different layers. Swiss cheese.

It's the bad stuff sticks and the good stuff still goes through. Yeah. So the Swiss cheese model, even though there's holes everywhere. As long as they don't line it. up for six layers of cheese, then you're good. And unit tests, would unit tests have been better? Maybe. I wrote unit test for the first feature I rolled out. And I still caused a site event because there was some other coupled code that I didn't find. Side of the meaning and outage. Yeah, yeah. Not a bad enough one to go through a incident review,

which is another, another layer of that where every Friday, the most senior people would get to together and anybody who'd caused an incident would come in and explain, here's the timeline of what happened. Here's what we learned. Here's what we need to do to avoid this ever happening again. And if you went into incident review and you explained it that way, you were fine. If you went into incident review and said, well, ops did this and somebody else did that and blah, blah, blah, blah, you could literally get walked to the door. That was another level of feedback that made sure that the same. mistakes didn't happen again.

And that was taken seriously. What I know and what many people know is, well, Facebook, for a long time, they did not do unit tests for most things. In fact, I think if someone tried to push, they would often just delete it in code review. And, you know, that sounds bad at itself, especially at a time this was the early 2010s where testing was considered really best practice or baseline. But I think what people missed is all these other layers that most places did not have.

My understanding is that to this date, Facebook, the website and mobile apps, rollout infrastructure is probably the most advanced in the world in how it automatically collects signals and it does the auto rollout and the auto rollbacks, which just does not exist in 99.9.9% of places because they don't have their scale or their opportunities or even their business, right? Because I guess outages are just, it's a bit different when the utility company goes down versus when Facebook might go down the impact? Yes, and while I was there. So by the time I left, 2017, Facebook is a very different place than when I joined.

Over the first couple of years, Facebook became much more like a utility. The big site events, the big negative incidents, the notable ones would get names. And so there was one called the call the cops, Sev. And it was the first time that people called 911 when Facebook went down. Wow. It was like, oh, crap. We need to take this even more seriously than we've been taking it. Okay.

Because we're social infrastructure and people just expect it to absolutely work. And what was it like inside Facebook, how the engineering culture, how engineers work compared to the rest of the industry? Because now you were now in this bubble, which worked very differently. There was very little planning. There were no deadlines as such. Zuck would say, I want to increase the resolution of photos, you know, by a factor of four. And the engineers would say, well, we can't do that because blah, blah, blah, but he'd say, yeah, I understand. Still want to see the photos looking better.

And then people would go and do it. And it would take as long as it would take or you'd work on it for a while. and if it just couldn't for whatever reason, then you'd switch to something else. Early on, I had lunch with somebody who'd come from Microsoft and said the thing about Facebook is, if you're at Microsoft and you have a good problem to solve, you will defend that problem tooth and nail

because there aren't enough problems to go around. And at Facebook, if you're solving a problem and somebody else starts solving it, you just go on to the next thing because there's always some other trash fire burning someplace else. And that's certainly no longer true at Facebook. It's opportunity starved. Then it was opportunity rich.

I accidentally saved $5 million a year during my boot camp. No way. I was looking at the photos code, which at that time was a single PHP file that I printed it out and taped it all together. It was 18 pages. That was photos. And it was the biggest photos site in the world at the time. And I looked at it and I thought, man, there's just, there's something wrong here.

We were very careful to reduce the number of round trips between the front end code and the cache or even worse databases. And so I looked at it and I thought, oh, there's something. I realized, oh, yeah, this can be made more parallel. So I made that switch. And a week later, the photos manager came to me and said, oh, I'm no, I'm not. noticed that the demand on the photos machines suddenly dropped when we rolled your stuff out. And they can recommission enough servers to save $5 million a year. And I was just farting around.

You know, so there was like the gold rush and there's just gold nuggets sitting on the ground and you just pick them up. Not true today. And even by the time that I left, it was no longer true in that same kind of sense. But you could just be a programmer and do programmer stuff. and you had enormous leverage, which was part of the magic of it. At that time, this is pre-IPO, the middle management, middle engineering management, like first and second level of engineering management,

all had generational wealth in vested options, but had to go public. So that tier was very focused on global optimization, not local optimization. not local optimization. They would give up, you know, you talk to some team and I'm like, well, we could really use you, but I think you really should go here because that's what's going to make my stock options go up the most. Yeah. Which is crazy behavior. Once you get into this scarcity desert kind of mindset, like nobody's going to act that way.

But at that point, that was, it was extremely novel. I collected a whole series of this. I found this manuscript the other day, how Facebook works. there were a bunch of policies that I'd never seen before, one of which was 50-50 goals. So six-month performance review cycle, at the beginning of six months, you'd say, here are the thing, here are my goals.

And when you reviewed those with your manager, if you'd accomplished half of the goals, you get A-plus. If you accomplished everything you set out to accomplish, people, you know, you're sandbagging. You're not trying hard enough. You're not risking enough. You didn't learn. anything over the course of the six months. If you accomplished none of your goals, you were just

out. So engineers and engineering managers would get fired at them much sooner than I'd ever seen anywhere before, which creates anxiety. But it also, like you knew you didn't have to protect yourself from slackers because everybody else was under the same kind of pressure. And you you were all trying to make the world more open and connected. Now, it turns out the world can be too open and connected, but that's a separate set of it. Yeah, but it feels like you were there during the golden years. Now it's morale is terrible with all the engineers are being assigned without asking them to do data labeling. It's all turning into very different culture, but I guess it just shows that places do change.

But it seemed that was a time where Facebook was growing. The mission was very interesting. there were, as you said, more, it was opportunity rich. And you were coaching engineers there. What did you learn about folks who are already, I guess, pretty standout if they got into Facebook? How, in what ways could you help them or did you help them? So about a year in, I've been working on a C++ project, infrastructure for the Facebook Messenger product, which had come out, become very successful, and outgrown its infrastructure.

needed support. And I was not a good C++ programmer. And so I was not going to stand out there. I had six months to turn stuff around. And in that, the missing years, I kept body and soul together by doing coaching, remote coaching. And so I knew I'd had, I don't know, hundreds of hours, maybe thousands of hours of coaching interaction. And one of my friends at Facebook, an old timer named Peter Dimov, said, talked about this coaching stuff. Let me just start doing that. And Facebook was very much, you're an engineer, you feel like doing a thing, you do the thing. If it doesn't work out, you take the consequences. If it does work out, you get the rewards. So I thought, all right, I'm a coach now. So I hung out my shingle.

And I found my first three students and started with daily one hour conversation. It turns out to be way too much for three weeks or four weeks or something. And two of the students worked out well and one of them got fired. But yeah, they told other people so people would come to me and ask for this coaching thing, which evolved into a program called Good to Great. And the idea was I'll talk with programmers who are good, but have kind of stalled. You know, there's this punctuated equilibrium that happens where people get better. And then they gather experiences without growing much.

And they need a little kick to get them up to the next. And so that's the good to great part. And I was coaching people one-on-one. I'd coach six people at a time, which is exhausting. But I was also matching up other senior engineers with junior engineers for coaching. And then we would have the meta conversation of coaching the coaches tell me about something that happened this week that was a you didn't know how to react to or is difficult. We'd all talk. I brought in a storytelling consultant to do.

an offsite. I hired Aaron O'Rourke was my administrator because it's not my strong suit, kind of lining stuff up. And she worked with HR to analyze the program and discovered that the people who'd been my students were twice as likely to get promoted in the year following coaching than a cohort that was the same-ish. didn't get coaching. So it really worked to to accelerate the career progression of the people. I didn't handle the politics of it very well. So this was this was learning and development outside of the learning and development organization. And I didn't understand that that was going to be an issue. So by the time I left, there were big fans of good to great, but there were

also people who didn't like the fact that it was around. So I ended up coaching probably 200 people individually. I would write classes that I would give and then I'd teach other people then to give that thousands more of engineers went through it. And just before I left, I went to an offsite with the top 1% of Facebook engineers. And out of the 100 plus people, 100-ish people there, 10 of them were former students of mine who had gotten promoted to that level. So I felt really good about how that all worked out. That was a kind of back to Ward. That was a kind of interaction that I was able to have with Ward.

It wasn't, it wasn't, it's not always pleasant. It's not a pat you on the head and you're going to be fine. It's a, it's a don't like, no, you're screwing this up. go try this thing, tell me how that works. But you didn't try the thing, oh, you don't want to work on this? Okay, we're done. Quite uncompromising, I say coaches are there to identify and induce productive discomfort. But the coaching program as a whole, by the time I left, I had great, great grand students.

I'd coach people who became coaches, who coached people who became coaches who now we're coaching. I think there's an element to that, a way of learning in that kind of style that just can't be duplicated. So when Dario says, we're going to eliminate software engineering, you don't understand what software engineers do. We're going to transform some of the activities that go into software engineering. Absolutely. I'm having a blast. But the, uh, the, the, this idea that we're code monkeys, requirements and jolt call in code out. Come on. To be honest, I do sense that Dario has a disdain for developers, software engineer,

should I say? Or I've never seen an indication that he likes them or that he was one. No, he clearly wasn't one. This is fine. You can be like a physics background or something like that. This is fine. And you can say, I'm going to. replace your job to me.

I don't consider that disrespectful, that's ignorant. By the way, can we talk about now? Sure. We bring this up every, you brought this up multiple times in our discussions. People awfully want to replace us developers and we should probably reflect a little bit on that. You've had time to reflect, why, why does this keep coming back? We're kind of assholes sometime.

I mean, that's the, that is the long and the short of it. My perspective is someone on the spectrum. who's been an engineer for a long time, whose dad was an engineer, whose grandfather was a geek, you know, in his own, in his radio kind of way. So I come by this all honestly. We don't necessarily have good emotional regulation skills, don't have natural empathy. That's why I play poker, by the way. So I get feedback when I don't have good empathy. We oftentimes are more direct than other people can easily handle. Yeah, and the business setting, yeah.

I'm just telling the truth or I was just asking a question. Those are the most hideous things that I say. Because, okay, yeah, you were just asking a question, but you're being an asshole asking that question. And I didn't realize it, but I was because that's how people react. So I don't expect anybody to cut me any slack. There are people who say, well, it's up to the rest of the world. to adapt to the ways that I'm weird.

It's just not. Because I mean, it's not going to happen. So learning empathy, learning how to read body language, learning how to read tone of voice. This is not natural skills, but they're skills, they're learnable.

I'll never be as good at them as my partner who's social genius, but I can be not horrible at those kind of skills. things like belligerence that's a common social strategy for people like me and has been a social strategy of my there's some disagreement between us and the way I resolve it is you know how long is it's going to take four weeks has to be done in two weeks yeah that's an invitation to have a conversation when I say four weeks and you say no it has to be two weeks I don't have to shrink and say, okay, try and get it done.

I also don't have to say, yeah, go to yourself, check ass. Neither of those responses help. Say, all right, well, let me, let me understand your needs. Not an easy task for me, but I can do it. I have a little checklist in the first Terminator movie where he's got the little pull-down menu of responses. Yeah. It feels like that oftentimes.

times. But it's better to have the pull-down menu of responses than to do something that alienates the other person and ends the conversation before it's actually finished. I think it's those kinds of things. It behooves us to learn how to communicate in a style that other people can actually listen, which is why I bring in analogies from the finance world, from sports, from history, from every place I can find in a desperate, for an attempt to understand other people and help them to understand my perspective and what that brings to the situation in a way that they can actually comprehend it. Jumping to the present times, where now for a couple of years, we've had AI LLMs,

but now we just call it AI, as you call it the genie. Yeah. And it grants wishes, but it's not actually what you want. And it has some interesting characteristics. I'm wondering, how do you think this will change individual developers work and also teams, companies, tech companies are building software? What are you seeing so far? We talked a lot about how, what software engineering really is.

We talked about the understanding, the communication, the learning as you are coding. It seems that that is definitely shrinking, if not being taken away. That's a choice. But I'll finish your question. Just looking across the industry. Yes. And it also feels that there's an analogy which, what you said when interfaces were out, that people were overdoing the interfaces.

And it feels it's like this. We have these AI agents or genies, as we call it. And people are using it everywhere and they're going mad and forgetting some of the sensible stuff. Yeah. Oh, what an open ending question. So one of the things is that the pace of development is definitely. accelerated. One thing I wonder, the pace of business hasn't accelerated, though. And that mismatch is going to become more and more apparent. So I was at a client, they were showing, they were

spending $2 million a year on some SaaS product. Somebody vibe coded a replacement for it that was better for their uses and didn't cost $2 million a year. How is that vendor, going to reply to that. Back in the olden times, two years ago, they'd have years to respond to, yeah, we have this add-on. It costs $2 million a year, but people don't really like it.

And eventually they're going to find a replacement. We have five years to respond to that or three years to respond to that. Now they've got, we have this add-on, we've been able to charge for it. That's going to go away in a month. On their side, could they code up a replacement that was better? Yeah, they could code up.

They're seeing the same kind of acceleration to everybody else's. But is the need for a replacement going to go through their customer service to marketing to sales, the business development, to the product organization, da, blah, blah, blah, blah, blah, that chain is designed to take five years. And now they have a month. or they're going to be losing big chunks of revenue. This is an AI's fault. This is just an acceleration and their business process is just not prepared to respond in time. Because my personal definition of Agile is responds in time.

And they're not prepared to deal with the new pace. Like you're driving a tractor and all of a sudden you're in a race car. Still wheels, still an engine. But are your skills prepared to steer that car? Not how fast can it go, but how fast can you get from point A to point B on a windy mountain road? You're used to driving a tractor and now you're in a Ferrari. It's not the car's fault. But that's a trend that I expect to play out, that we're going to see companies fail.

because they don't respond in time. They've been fat and happy, kind of newspapers with, another analogy is newspapers with classified ads. Classified ads paid for reporters and paper print, you know, stuff printed on paper

and taken around everybody's houses and then classified ads went away and journalism had to respond and it's responded well in some ways, but poorly in others and were less served by local journalism than we were before all this happened. Okay, so now we have people who've been able to rely on switching costs to protect their profits, and the switching costs just dropped to zero. Their profits are going to drop to zero, and some people aren't going to survive that change.

Some people will. The flip side, so you're paying for some service, you think, ah, I could vibe code something better. And so you do, but you only solve this much of the problem. It's the part of the iceberg. You can see that. You can vibe code the part of the iceberg that you can see. So I'll talk my own book. I was at Gusto for three years, does small business payroll.

Somebody said, oh, I just asked Claude, I have this many hours. at this rate, I'm in this tax bracket, what should my paycheck be? And it tells me all the numbers. I don't need gusto anymore. I'm just like, oh, you have no idea. Go ahead. Run your own payroll for a quarter and then figure out what all of the reports you need to submit to the various tax agencies and different states. And I live in this one, but I work in that one. And the company's based here and now what should the number like there's so much that goes on to correctly compliantly execute payroll that isn't gross pay net pay so we're going to see people get into those where they're like well i vibe code the tip of the iceberg i throw away the rest of the

iceberg and now i'm in trouble because now i don't know what to do now i get to these downstream problems that I didn't even know existed. So we're going to see on the on the side of the the vibe coding replacers, we're going to see that kind of naivety play out. And what about for software engineers? Because a lot of the identity for engineers was around being able to craft code, caring about the craft, being able to visualize a lot of these things. And these tools are getting really good at doing a bunch of that stuff.

What advice do you give to these folks on, okay, well, there's this new technology change. If you'd like to stay top of the game software engineer, what activities can you do? What mentality change should you do? So my inspirational motto is nobody knows. So people come to me and say, well, how does TDD apply in the augmented coding world? I said, nobody knows. It's not just that I don't know, is nobody knows. The big lesson I learned at Facebook was about that there are three different phase states of a product of software development, this exploration phase where you've got to try a bunch of different things because you can't predict.

Then something takes off, and we've talked about a bunch of those examples from my career. and the discipline of riding that rocket up once it's been lit is very different than the discipline, and it is a discipline of exploring the space. So while you're expanding, you focus very intently, and it can be, and it might even be unsustainable,

but it doesn't last very long. And then there's another, you get to extracting value from that to feed the next set of explorations. This is it 3X, right? Right, explore. This is yet another model that you came off sometime in 2016, 17? Yes, 15, 16.

I finally figured out, figured out. I felt that I understood how Facebook had been able to be large, growing, and innovative at the same time. And it was by treating projects at different phases in a completely different styles. So explore? Explore is you're just looking for something. and you can't predict. So you have to try as many, it's a numbers game. You try as many uncorrelated experiments as you can for the cheapest price.

Then you expand. And then something takes off. And then you're in this expansion phase where instead of trying a little bit of everything, you focus on the one thing that's working and you discard everything else and you overcome obstacle after obstacle after obstacle. And then you get to a certain size. and now you can predict growth. And you can say you can write a, if we roll out our product in a new country,

we've done five countries already, here's the playlist. And you know how to do that. That's that extract phase. You've reached economies of scale. You can make small tweaks and it makes a big difference. You have a long lifespan also. So how you write code, how you manage projects, who you hire, how many people, what the org structure is,

is completely different in the three phases. For 20 years, we've been up in that extractistan. There's been a playbook. It's evolved a little bit. But, you know, we have too many bugs in production. Here's the three things you can try. Oh, you know, we need to accelerate development. Here's the things you can.

People sometimes didn't do the things, but the playbook existed. And to be a senior engineer meant that you knew the playbook. And the more you knew the playbook, the more effective you could be. If you knew, oh, well, I also know how to scale back ends. You know, I know about item potency and, you know, what advantages that brings if I implement it and so on. Nobody knows now. That playbook has been wiped clean and people whose identity is, I know the playbook.

are now terrified. Who am I? Now, it turns out that the skill of writing a playbook is completely different than the skill of applying a playbook. That stuff that we did in the days of objects, that was writing a playbook. That was that explorer part of the curve. It's not that there isn't a way to be effective when you don't have a playbook. It's just that it's a different game. And the people who don't feel safe without a playbook need to turn their heads around just like, well, nobody knows.

It's not like there's some secret playbook for genie-based development that, you know, if only I paid a million dollars, I could have it. It just doesn't exist. When we get glimpses of it, it changes next week. Like small changes to the inputs cause large changes to the. the outputs. So we're all back in the Explorer stand in this where we just the more things we can try, the better. I'll get these questions. Oh, I think we should debub, blah, blah, instead of writing one test at a time, maybe we should, we should write a bunch of tests at a time. Do you think that would work? Nobody knows. Try it. And tell us how it goes. If more people are trying

more things in community and communicating like I did this thing. Here, I added this markdown file and it had this effect. Somebody else says, well, I added it and made things worse. Okay, well, what's different about your have to have that conversation? That's what's going to result in the playbook. The Agile Manifesto date 2002, right? 2001. 2001. The first Upsla, 1986. It took 15 years to write that manifesto, which is why when I see manifestos today, I'm just like too soon.

Not a bad idea. Would love to have one. It's just too soon. It took 15 years for the technical change of object-oriented programming to come before we could say, here are the consequences of it. Here's how in a simple way

we can express how to effectively use this technology that we've been using day in and day out for 15 years. The genie comes along. People are like, well, what's the new manifesto? It's just not manifesto time yet. As closing, what do you find exciting looking ahead with AI agents, with genies, with all this change, with this clean state that we're in? What gives you energy? This is home base for me. the writing of the playbook.

I just love that. I'm a tree shaker, not the jellymaker. So I love shaking the tree. I love getting stuff started. I have a very wide range of projects. So I have a project called Arlo, which is an object-oriented database. I have several fundamental data structures. I wanted to see if I could write code that was library quality.

code for a language I didn't know. It turns out, yeah, I can. So I built a B plus tree that's faster than rusts B tree for some operations. Wow. Wow, yes. But also, I'm not a Rust expert. Like, what could a Rust expert do with these same tools? And why didn't they write it?

I don't know. But I'm building little bits and pieces of apps for stuff that I care about. I use the genie for business planning because like you, I have a newsletter. Unlike you, my newsletter is kind of small, but it's pretty big. I'm doing okay. Now, how do I turn that into a sustainable business? Also, I hired a business partner to help with that. So I'm doing a lot of writing, reflecting on my experiences.

I'm trying everything. If there's a secret sauce to what I'm doing, it's not being afraid to start over. And your whole career shows this from the very early days, TDXV3X, Heidi first, genie. Yeah. So if you look on my GitHub, you'll see Project, Project 2, Project 3, Project 4, New Project, New Project 2, New Project 3, New Project.

I'll take it, I'll push it a certain amount, and then the genie runs out of gap, runs itself out of options. It can't make further forward progress. And so I'll wipe it away, start over. I won't try and tweak. I'll start over and say, all right, well, if I implement things in a different order, if I implement with this markdown file, or if I implement it with this commit hook, we collectively need to try absolutely everything. And some of those ideas are going to be sound stupid and are going to work out great.

Some of the stupid sounding ideas are also going to be disasters. But if we're willing to start over, then it doesn't matter. We're not really risking that much. That creative impulse is what's come back to me with the genie, this idea that I can go. I wonder what a B plus tree looks like in go. Here's an alternative to the B plus tree, this adaptive rate, Street. What does that look like? I can find out. I sit down with a genie. I can work it out. And then there's this artifact that wasn't there before that's there now because of my imagination

and my work. And I had gotten fed up with the stupid minutia of programming. Oh, for that, you need to have the version 7.1 of the upgrade the thing, which then causes something else to break, which causes something else to break, which means that I can't use version 7.1. I have to... I just hated that. Getting emotionally invested, having an idea, getting emotionally invested,

getting ways in and realize I can't do this for no good reason. I hated that. And that kind of blockage just doesn't happen to me now. And, oh, so it's... This is hog heaven. I've got 40 years worth of ideas. is this would be cool. Oh, it's too big. That suddenly are back in play. And I'm having so much fun, making things that are real.

I can see it on your sharing it as well. Kent, this was awesome, especially doing it finally in person. Yeah, it was great. Great to be able to sit down with you in your home country. Here we are. This was a special episode for me, recorded in Budapest, Hungary, right before craft conference 2026. It was the first getting to hear Kent walk through his entire career, start to present, in a way he's never done in a podcast before. One thing I think back to is how Kent said we're accumulating code faster than we're accumulating trust. Kent is so good at summarizing very true things like this. When you struggle through understanding the domain, representing code, and write tests that prove that you got it right, you end up trusting your program. And when you do that work alongside other people, you build trust with these people too.

Kent's point is that none of this happens when you just prompt an AI or as a genie he calls it. and you get back the code that works and AI says it's all done. I also loved how consistent Kent has been across 50 years. Whether it's small talk, design patterns, TDD or AI today, his instincts are the same. Try the stupid idea and don't be afraid to throw it all away and start over. As he put it, he's a tree shaker, not a jellymaker. And Kent's tree shaker impulses right back on and is trying stupid things with AI. Finally, I appreciate how grounded Kent is.

People kept asking him what the new manifesto for AI development is, and his answer is that is too soon. The Agile Manifesto took 15 years of doing object-oriented programming before people like Kent could summarize lessons. With AI, things are still changing quickly, and Kent is honest when he says that right now, nobody knows what is working. Do check out the show notes below for how Kent and me both thought that McKinsey did not know what they're talking about when they want to measure software engineering productivity. Also, check the show notes for related to the pragmatic engineer deep dives on topics like tech depth, software craftsmanship, TDD, and others. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube.

A special thank you if you also leave a rating on the show. Thank you and see you the next one.