# AI Acceleration, Engineering Trust, and Adaptive Strategy

**Podcast:** The Pragmatic Engineer Podcast
**Published:** 2026-07-01

## Transcript

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 story is 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, Kent'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 TrueLegends was shaped by the industry and shaped 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 Antisys.
If you work with agents, your job is no longer just writing code, it's specifying and testing it.
And antithesis 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 the team likes to say it, they're all puffin.
TurboPuffer offers a full set of search tools, vector search, full text search, attribute filtering, regex, and more in one API.
It's built on object storage as a sole 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 represent it 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 act of 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, woo, 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.
Huh, not my natural strong suit.
To...
convinced, 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 right 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 a lot more popular, XP, TDD, a bunch of other just small refactorings and so on.
But going back, how did it all start?
How did you have your first contact with...
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 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 the size of this table.
Probably weighed 65 or 70 pounds.
Yeah.
Yeah.
It was.
65 pounds.
And it had, it had Nixie tubes.
Nixie tube is, this is before seven segment LEDs because LEDs hadn't been invented.
You'd have a, an incandescent light bulb with 10 filaments in the shape of the numbers.
And my first program was, 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 0 1 2 3 4 5 6 7 8 9 so i i just wrote a program that would count up and down because i loved watching this go back and forth and back and forth and back for hours i could just 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 spectrum-y kind of kid, I would obsessively read these books.
And I found one of them lately during a move, the Burroughs B6700 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.
It founded 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.
The one that your dad brought home?
So no, the like handheld calculators.
Okay, so the big tabletop calculators was one thing.
But then...
There were these little calculators.
I remember my dad buying an HP 35 for $400, which is, 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, you know, make sure that I stack everything.
And then you go plus, plus, plus, and that would.
pop stuff off the stack.
And then the HP 45 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 8008 and the 6800.
And my dad and I soldered together our first 6800-based.
machine.
Then we were programming in assembly language.
Then out came basic.
Then this was about 70s.
Yeah.
Yeah.
So so that was really I was spending a lot of time working on that machine.
Again, I wouldn't say I understood it at a 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.
So they already had a 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 play guitar.
Let me see what I can do.
Next thing I knew, I was a music student.
Wow.
So I'd been playing.
I started playing guitar when I was eight, kind of the end of the folk boom.
Mrs.
Card had a summer school class.
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 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.
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.
Why did you have a hard time?
What was your master's thesis on?
It was on 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 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.
So, but you completed it.
I did complete it.
It is important to complete things 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 Tektronix came down to give a presentation about the programming environment work they were doing.
Tektronix was...
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 them questions they couldn't answer.
And so they invited me out to dinner.
which led to an interview, which led to a job.
Tektronix was an interesting one because this is where you met Ward Cunningham, right?
Yeah.
So Tektronix had invested early in this crazy object-oriented programming language called Smalltalk and was trying to make a commercial go of it.
And I got there and looked at the research that had been presented down in 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 hit?
What pulled you in?
What is the language like?
There's a beautiful paper called The Design Principles Behind Small Talk by Dan Ingalls.
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 Smalltalk 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 Smalltalk, 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.
What I found beautiful was that the language pushed its own mechanisms to the absolute limit.
So everything is an object in Smalltalk, 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 defined.
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 does how to 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, you know, the 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, 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 generation of languages.
Cobalt, Fortran-C, Algol, 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.
We're like inside of the industry.
This was a thing.
Use objects or small talk and do more with less programmers, cheaper, the works.
Yeah.
And to a degree, it was true.
People would come in.
So Tektronix built a workstation.
There weren't workstations.
Tektronix built a workstation and started to sell it with Smalltalk bundled in it.
And technical people, but in different domains, like chemical engineers or structural engineers or hydraulic engineers, would come in and show us the systems they built with Smalltalk.
And on the surface, they looked.
fantastic.
They solved it.
And oh, they were so happy and 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 to 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 and 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 Smalltalk and Techtronics selling machines that come with Smalltalk 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, Smalltalk's 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 Smalltalk.
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 Smalltalk.
There'd be some code, you'd 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 doesn'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 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.
Now, while at Tektronix, you worked with Ward Cunningham, 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 Smalltalk and Ward had written some Smalltalk code.
We knew each other.
There were probably 60 people, 80 people in the labs.
So we knew each other by sight.
I had learned a bunch about Smalltalk working on my own projects.
I was working on programming language for Prolog 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 Prologue's unification mechanism worked.
And I guess for those who don't know, Prologue is this, the curative language is a very different way of thinking.
No variables, I think.
No, no, it's got variables.
No variables is FP, Bacchus.
Oh, this is FP, sorry.
But it does have some funky stuff.
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 Smalltalk do this.
Because the universe of...
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.
He also had a gift 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, 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 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?
And 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 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 Monday morning we'd have a coffee and we'd talk about 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.
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 this 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.
Eh, 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 HotDraw.
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 HotDraw.
Yes.
Absolutely.
And this reminds me, 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 87 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 hand.
And it just, this is so hot.
We were just really excited about it.
Oh, that's why 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 this two and a half D 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.
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 handle, 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 have figures in figures.
And do I understand that you actually had a physical cazarus?
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 did programmers in general have people that you knew that they also have the satarsis?
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 words, your vocabulary will start to grow, therefore making you a better programmer 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 at 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 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 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 and 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.
Yes.
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 Tektronix.
Some programmers were writing software for some test engineers, and it just, it 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 1200 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 and 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 Ward had come up with.
And we talked about Christopher Alexander and 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 panes.
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 panes 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 Smalltalk programmers would look at that and go, OK, 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 at 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 flyby architect on teams who, you know, is very senior person has built a lot of stuff and the team is struggling.
They call him 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 don't have 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 Tectonics, you worked at Apple.
I only realize 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 Smalltalk was going up like a rocket at that time.
Xerox had developed Smalltalk.
It handed it to four, I think, companies to see, can you also implement it or is this something special?
So HP, Apple, Tektronix, and blanking on the fourth one.
HP really didn't do anything with it, but Apple and Tektronix 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 Tektronix.
I learned a lot.
You know, 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.
Those 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 Smalltalk project, which ended up going nowhere because it really didn't make sense.
Smalltalk 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.
Yeah, 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 the 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.
Correct.
So we talked about the decline of small talk.
I'm sensing around this time, as personal computers started spreading, it seems like it just remained a niche, right?
No, it was quite strong at that time.
It was growing fast.
Lots of people.
like relative to the previous year we're using it.
A company had spun out of Xerox called Park Place, which was selling small talk 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 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 the 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 Tesler 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 Ingalls 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.
I moved to the Alan Kay's Playground project.
Now, I was horribly ineffective.
Ended up getting fired from that job.
No way.
Yeah, 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, no, 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 OOPSLA conference, which we probably should have mentioned earlier.
There was this conference and it was.
the hottest conference and everybody who 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 UPSLA.
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, 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 Responsibility 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, 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, yeah, which is, you know, I've, I don't know if I've met anybody else who describes their experience of programming in the same kind of way, but, 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 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 da-ba-ba-ba, da-ba-ba-ba-ba.
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-oriented 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 to 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 designing object-oriented 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 computation move to where the data is.
So like if you have a rich object with the lots of data inside of it, for example, you want the computations to move there.
So you want the 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.
Yeah.
Do I have height times width?
scattered all over the universe?
Or do I have an area inside the rectangle that does height and width?
At the limit, now I don't care that the rectangle has height and 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's a good lesson.
Yeah.
And even today, because everything that we do is under the hood of almost everything we do as objects.
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 noticed here is unit testing.
This was the place where, as I understand, you came up with something called S-Unit while I was at Tektronix.
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 status divide, there was a tool divide.
You had testing tools, which would have their own kind of language, and 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 Mass Par 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 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 Smalltalk, right?
Yeah, the first version was written in Smalltalk.
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 your 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 the cost.
And they needed a programming environment, so we built a programming environment in Smalltalk that 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 this in small talk to interpret, 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 Fortran programs running on 16,000 processors and great gobs of data.
That's awesome.
Like when you're going from not just like you're just going lower level, you know, like building infrastructure that runs programs.
But then I want to go back to S-Unit.
So the concept of S-Unit, these concepts you put together, test case, what was it?
The test case?
Test suite and test result.
This really became sticky because then there was JUnit, which you later created with Eric Gamma.
And there's a whole suite NUnit, or I think that was for .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 Smalltalk and you should be able to represent anything in Smalltalk.
So, you know, and I was just used to how do I represent this as objects?
Sounds like Smalltalk as a language has been early to a lot of things.
I sense a lot of innovation coming from Smalltalk 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 if you are being forced to do so if you wanted to do it.
Well, there was an ethos that went along with Smalltalk.
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 realized, 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 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 this 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, 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 know, you know, may have to build some stuff.
And then you send it the test test something or other.
And it executes that one thing.
And then you then assuming, well, then regardless, you run the teardown 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 in the language, but it's not really in the language at the same time.
But people don't think about that.
They just think, I subclassed this.
I give a method with the annotation of test or with starts with TST and then it just starts working and that's fine.
I want to jump to a few years later from 1996.
You start to work on 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 OOPSLA conferences, the question of how do we manage projects?
with objects differently than we manage projects with the previous generation.
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 we had the structured analysis, structured design.
What is the methodology for for objects?
And how should it be different?
That was the million dollar question at the original 86 Hoops 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, Ivar.
James Rumbaugh, Ivar Jakobsen.
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 and over again.
And the same is true, it turns out, of everybody.
So you can find that episodes on.
uh wards c2 site it's really interesting to compare that because i 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 mass bar 92 so i had been an independent consultant for four years at that point and there were a couple of workshops uh held in snowbird 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 projects.
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.
Smalltalk Performance, and they were using a database called Gemstone, which it was Smalltalk Objects, Smalltalk 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 they 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'd 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 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 and another.
Now, it turns out those 11s that we turned everything to, there were several notches 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 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, after my like 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 style.
It got kind of old to say that over and over again.
So now I'm.
Back with the Cesaris, trying to figure out what are the words.
I thought we were really onto 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 Booch to ever say that he was doing this thing.
So 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.
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 downsides 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, something like that.
When did XP, Xtreme Programming, I recall, start 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, then a bunch of coding, then a bunch of testing.
They could tell it'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 Joel Cola, rest in peace, Joel Cola, cowboy, you have a bunch of 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.
But basically XP was giving you a way to move pretty fast and nimble, but also have.
a sense of stability, not just going wild, wild.
You had 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.
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, 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 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 these 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, I should have a record in the output that like this.
I see where we're going with this.
You're defining the output.
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.
Diddly squat.
But it's back in the back here someplace.
I wrote S-Unit for the first.
Started using it.
Gave it to Hal Hildebrand, 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 onto something 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.
I 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 it.
I should get the same thing back.
Okay.
And then I went to program it.
No.
Okay.
Well, that's easy to satisfy that.
What's the next one?
Oh, you push two things and you get them back in the right order.
Okay.
And this, and, uh, 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 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 made a comment.
Always try your stupid ideas.
If you can do it cheaply and reversibly, jumping off a bridge.
It's 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'd 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 tried 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 fewer people doing it.
And it almost went out of style completely.
And now with agents, the idea is back because it turns out it might take more time with all but agents.
Agents can do that, but 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 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 JUnit.
It was true of TDD.
It was true of XP.
I just move on to the next thing.
So I moved on to the next thing.
TDD is out there.
And then there were people who used it as a moral cudgel.
Like you should be, if you're not 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, 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, 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 do a thing, I learn a thing, I do a thing, I learn a thing.
That's where TDD is really powerful.
But it's not a moral decision.
It's a practical decision.
Test-driven 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, Antithesis.
Antithesis is the most effective method of verifying a genetic code today.
Let me explain how it works.
Antithesis runs your whole system in a hostile simulation.
By doing so, it finds every bug before your users do.
And because the simulation is fully deterministic, Antithesis doesn't only find bugs, it gives you a perfect reproduction of every issue.
I know this sounds closer to science fiction, but it's actually hardcore engineering under the hood.
Jane Street, Fly.io and the etcd community ship agent written code with full confidence because they know it's been verified by Antisysys.
To see more case studies and details, head to antisysys.com slash pragmatic.
That's antisysys.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 seasoned 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.
WorkOS handles it.
SSO, SCIM, fine-grade authorization built for how agents actually operate.
The fastest-growing AI companies, Entropic, OpenAI, Cursor, Perplexity, already trust WorkOS to solve these problems.
Check out WorkOS.com.
And with this, let's get back to Kent and where the Agile Manifesto came from.
I want to talk about the one thing that you're also very 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 Ivar, how they would apply it is actually looks a lot like the way that I would develop.
But 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.
Bunch of analysis, bunch of design, bunch of implementation, separate testing, disaster over and over and over again.
So a bunch of us looked at that in our own ways, in our own sequence of time.
Said, no, we shouldn't do this.
We 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 to 99.
So in 99, we flew up to the tip of Norway and took the Hurtigruten 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 uh when we got back jim highsmith and alistair coburn uh 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 um 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 drugs.
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.
And 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, the, the, that format, we value these things, but we value these things more.
And the four specific items, that was all in place.
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 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 when it came time to publish it, what order do the names go?
It was alphabetical, wasn't it?
Absolutely alphabetical.
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, we're 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 a, 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 optionality.
With optionality, yeah.
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 XP was the first time I had people tugging on my shirt.
JUnit 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 Dulles.
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 a horse driven computing.
So we landed and we gave J unit to Fowler who was at that OOPSLA.
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 inch 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 they closed 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 you're contributing, it can make a difference.
It has made a difference.
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, I 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 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.
That word does not only doesn't mean anything anymore, it means something negative.
Can we talk about that 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 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 parts.
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 to software development than is contained in the manifesto.
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.
You can say you're going to do that, but if you don't have the technical 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, no, no, don't worry about that.
This is easy.
You can do this.
Anybody can do this.
Twice the work in 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.
And the genie world is just playing this out again.
Well, everybody can be a programmer.
Yeah, but everybody can't be the same programmer.
Yeah.
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, yeah.
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's 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 time you realize it, 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?
Were you in Silicon 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 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.
Overnight?
Overnight.
Wow.
So things had already been bad.
There were big bankruptcies and the pets.com and whatever that was already happening.
And then 9-11 just sh**.
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 boundaries.
So up until that time, remember, periodically I had people tugging on my shirt.
You're at three really big part of market fits where people are after you.
Patterns even before that was also like that.
Well, you were a star.
I was, yeah, I was feeling, yeah.
And I would get these messages.
Somebody would say, oh, JUnit saved my life.
XP was fantastic and I love it and you're a genius and blah, blah, blah.
And I'd feel really good when 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.
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 Sudokus on easy.
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 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 similar might have happened?
Was it not for this sudden crash or being at 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.
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 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 a, 35 or 40 or 45 and mine was at 42.
But then you, in 2011, you got into Facebook.
And I'm really intrigued 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 had all these contributions, TDD, XP, 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 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 in income.
Problem with?
Book publishing doesn't make much money.
Yeah, except in rare cases, Gergai.
Well, in the rare cases, in my case, where Amazon self-publishing has been invented.
Yeah.
And people buy your books in bulk.
But outside of that, even for, yeah, it doesn't.
Yeah, I love teasing you because you're so successful.
I know that even if you can't take it, you have to take it.
I am so good 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 us.
stable site.
It's not perfect, but at this crazy scale, it was stable and 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 was the first or one of the first remote engineers.
There were about 2000 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 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.
So there was going to be a hackathon and hackathons often came with classes.
And so there was a signup 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 book.
I invent, you know, blah, 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 signup sheet, TDD 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 TDD class.
So these engineers clearly felt like they had it already dialed in and they didn't need anything from this old guy.
So 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, 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 we had some very senior people with great leadership skills.
Aha.
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 out, there was a Monorepo-ish thing.
Yeah.
And so you could just change anything and see the, because it was PHP, 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 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 too.
a few million people not like automatic rollback yeah based on signals yeah not the whole thing chuck rossi's um 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'd 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 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 up for six layers of cheese then then you're good and Unit tests, would unit tests have been better?
Maybe.
I wrote unit tests 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.
Site event meaning an outage.
Yeah, yeah.
Not a bad enough one to go through an incident review, which is another layer of that where every Friday the most senior people would get 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, 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 that sounds bad in 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, you know, outages are just, it's a bit different when a 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 was 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 of 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, 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 some, 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, ops noticed that the demand on the photos machines Suddenly dropped when we rolled your stuff out.
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.
That's 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.
They would give up.
You know, you talk to some team and they're 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 had accomplished half of the goals, you get A+.
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 accomplish none of your goals, you were just out.
So engineers and engineering managers would get fired at a 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 were all trying to work, make the world more open and connected.
Now, it turns out the world can be too open and connected, but that's a separate setting.
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, 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, kind of 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 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, you talked about this coaching stuff.
Why don't you 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.
Started with daily one-hour conversation, which 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 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 but 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 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 I 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 it.
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.
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 coached people who became coaches who coached people who become coaches who now were coaching.
I think there's an element to that, a way of learning in that kind of style that just can't be duplicated.
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 this idea that we're code monkeys, requirements and jolt-colla in, code out.
Come on.
To be honest, I do sense that Dario has a disdain for developers, software engineers, 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, 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 does this keep coming back?
Because we're kind of assholes sometimes.
I mean, 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 in 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, OK, 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 mine.
There's some disagreement between us and the way I resolve it is, you know, how long is this 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, I'll try and get it done.
I also don't have to say, yeah, go to yourself, jackass.
Neither of those responses help.
Say, all right, well, let me understand your needs.
Not an easy task for me, but I can do it.
I have a little checklist.
You know, the first Terminator movie.
Where he's got the little pull-down menu of responses.
Yeah.
It feels like that oftentimes.
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...
the finance world, from sports, from history, from every place I can find in a desperate 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, or as you call it, the genie.
Yeah.
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?
Talked a lot about how, what software engineering really is.
We talked about the understanding, the communication, the...
the learning as you are coding.
And it seems that that is definitely shrinking if not being taken away.
That's a choice.
But I'll let you finish your question.
Just looking across the industry.
Yes.
And it also feels that there's this 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-ended 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 everybody else is.
But is the need for a replacement going to go through their customer service to...
marketing to sales, to business development, to the product organization, 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 isn't AI's fault.
This is just an acceleration and their business process is just not prepared to respond in time.
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, and 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.
I'll talk my own book.
I was at Gusto for three years, does small business payroll.
Somebody said, well, 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 in 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 side of 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 say, nobody knows.
It's not just that I don't know.
It's nobody knows.
The big lesson I learned at Facebook was about that there are three different phase states 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 writing 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.
There's another, you get to extracting value from that to feed the next set of explorations.
This is 3X, right?
3X, right.
Explore, expand, expand.
This is yet another model that you came up 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 style.
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.
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 extractive stand.
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 do.
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 backends.
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 explore 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 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, instead of writing one test at a time, maybe 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.
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, yeah.
2001.
The first oops law, 1986.
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.
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 jelly maker.
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 Rust's 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.
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 us from the very early days, TDD, XP, 3X, Heidi first, Jeannie.
Yeah.
So if you look on my GitHub, you'll see project, project two, project three, project four, new project, new project two.
New project three, new project.
I'll take it, I'll push it a certain amount, and then the genie runs out of, 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 radix tree.
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 a 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 so it's this is hog heaven.
I've got 40 years worth of ideas.
This would be cool.
It's too big.
This 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 a 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 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 the 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 jelly maker.
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 pragmatic engineering deep dives on topics like tech depth, software craftsmanship, TDD, and others.
If you've enjoyed this podcast, please do subscribe to 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 in the next one.