Subscribe
Share
Share
Embed
Kent Beck has spent 40 years watching and guiding engineers through their careers. He's made note of what it takes to help engineers stay sharp, stay curious, and keep building for decades. What he's learned is less about any one skill and more about adaptability itself; what it takes to be the kind of person who keeps up. Kent sitting down with geeks in front of a fire to talk about their careers, and what they're still doing to stay adaptable in today's landscape. Real stories, real engineers, real honest.
Kind: captions
Language: en
I'd like to thank Augment Code for sponsoring this first season of Still Burning. I can remember my excitement when I saw my first IDE. You could find anything, you could
change any code, and I was just so excited. But the era
of making changes to code like a watchmaker is gone. Most of the changes now are going to be made by the Genie, and Augment
Code is helping go beyond the IDE with their new intent product. Programmers stay oriented, they
keep learning, they see what's happened, they make strategic decisions, and meanwhile, agents go and do the detailed work.
The gap between an idea and a running system has never been narrower, and that's exciting. The gap between a running system
and a mature,
fully running system is the same as it ever was.
And the difference is not feature set, the difference is trust. Security, auditability, identity, the list of items a CISO
hands you before your system will run in their system. Teams try to tackle this themselves. How hard could it be? It turns out that this is both a very important problem and a very complex problem.
That's where WorkOS comes in. Single sign-on, identity providers,
role-based access management. WorkOS gives you the infrastructure to trust the systems that you're excited to have built.
Welcome to a very special edition of Still Burning, where we talk to geeks who still care and are still doing something about it. And I have a very special geek to share with you. My oldest, Bethany Andrews Beck, who's running for Congress in the 6th Congressional District of Massachusetts, and is also a high-level geek. Beth, welcome so much to Still Burning.
Thank you so much for having me.
Yeah, I've known you for a while.
Couple years.
Couple years. And so let me start with the question I always ask, which is, when did you first know that you were a geek?
So the first pun I ever made was cheese-related. Okay. And we'd gone to the refrigerator.
Forgive me for not remembering.
I mean, why would you?
(Laughs)
And I said, but that one's cheddar. And I was so proud that you laughed. And that's it. That was the start of all of this.
(Laughs)
Okay. So that's a word geekdom. Right.
How about computer geekdom?
Ooh.
Ooh. I really enjoyed a game called Widget Workshop. Yes. Where you built circuits and programs out of
sort of anthropomorphized, like a switch was a rail switch, and a timer was dropping an elephant on Mars or something.
And
piecing together programs out of fun components. And making it do the thing that you wanted it to do.
And
at what point did you know that not everybody shared these interests?
This is a sad moment of separation in the life of every geek. You think, oh, the world's this amazing place full of puzzles. And then you realize, oh, I'm kind of alone.
Well, I think for me, it was actually interesting. I met,
one of our friends' kids had some learning disabilities. And I was trying to teach him something and it wasn't working. And his brother explained, well, he always teaches,
thinks different. And
I realized that there were ways that other people interacted that were different than me. And to play, to like interact with them, you have to figure out the puzzle of
what is it that they enjoy?
What engages them? Because everybody is interesting in some way.
Now that's a level of empathy that a lot of geeks struggle to achieve. Sounds like you had that early.
People are fascinating.
Oh, God. And I think that helps. People are annoying. And I wish they'd all just... Really? Go away, yes.
Oh.
I mean, not you personally.
I appreciate that. But no, no, I
think of it as the thing that's least, or that's most human. Like the thing that makes us people is the ways in which we're different. And we all bring
something different to whatever collective endeavor we're doing. And there's always something we can't do. Like nobody can fly, right, without help. Yes. And
if you want to achieve things that you can achieve by yourself, then like my capabilities matter. But if I want to achieve something that I can't achieve alone,
then the question is what is the group of people who care about this thing? How do we
collaborate? What makes it enjoyable? What makes it rewarding?
And
it lets us do things that I would get bored if I could only accomplish the things that I can accomplish by myself.
Yeah, okay.
I think I backed into that reluctantly.
Which is probably why I write books and speak and so on, to accomplish more than I can accomplish myself.
So tell me about some of your other geek-toms. You're a multifaceted geek.
I am.
I have started, my degree is in theater. Which is very much the study of people and how do we come together and build stories and
talk about being people.
And all of the context that we bring with that. So I got to study
ancient history to modern day. What are the technologies of clothing? How does that influence what people wear and what that says about them?
It turns out there,
what shirt do I put on in the morning is a fascinating question.
Okay. If you go deep enough. It's not just whatever's on top.
Right. It doesn't have to be. It can be. It can be.
Yeah.
Yeah.
Well, I tend to go beyond the what's on top.
Yeah, yeah.
So I remember the chicken phase.
There was the chickens, yes. Actually, I was telling you with some of my references, like what made why chickens?
That's a great question.
Right. They do fit on not very much land, which helped. Yeah.
And
the roosters really were out to get me.
Yes.
Oh yeah. And so it was exciting in
like slightly terrifying. Stimulating. Like they were quite large compared to small children. Yeah. And then they were delicious.
Yes, we went through that part of the, we completed the cycle of life. Yes, yeah. All the way to dinner.
Yeah, and as a kid, there's
something really real about, like oftentimes you're watching shows about things, or you're reading books about things, or someone's telling you about things.
And the chickens are really there, and those spurs are really sharp.
So you're forced to be present in a way that you aren't if you're just viewing something on a screen. Right.
And then I met other adults who knew lots of things about chickens.
And we're delighted to share them with somebody who looked interested. Right. Because the average person is not gonna get lit up about
chickens.
But I
think one of the things that I bring is that I get really interested in a lot of things. You know, at a facet, one of my friends
leads road repair projects.
Okay.
One time we had a fascinating conversation about the way that they grind down roads before they repave them. Okay. Because he thinks a lot about how do you grind down a road before you repair them. I'm glad somebody does. Right, and I think following your interest is one of the joys of being a geek, is following your curiosity and finding that joy.
What is it that people care about? Because there's always a reason.
Like the through line of all my different interests is that there's always a reason, people do things for reasons.
And there may not be reasons I agree with, there may not be reasons we think of as noble,
there may not be reasons that anyone has thought through, but there's always something that influences you, nudges you, maybe the button's orange instead of blue, and you're more likely to click it by like 20 plus percent.
And when you think about that, then you can go about solving problems like no one's writing tests
in ways that you don't get to if you're starting, if you're not curious about why people aren't writing tests.
Okay, so we've dived right to programming.
What reasons have you found for people not writing tests? I
taught you, your first lessons in programming were to remind me to write tests,
and then you were supposed to remind me if I didn't write the tests. And then I don't know if this actually happened, but I remember it. Clearly being very, you said, do you have a test for that? And I said, oh, honey, we don't need a test for this. And then it broke later and I realized, oh, gah.
It was date printing. Okay. It was printing a date, and it turned out the format that Smalltalk had in its date printer was wrong, which is also, which I remember, because that was like the idea that somewhere down there, there's something that tells it how to print.
I also asked you what a hash function was in that, and you declined to explain hash functions to a nine-year-old.
That shows a lack of imagination on my part for sure.
I mean, you've learned some things, a couple years, I'm like, how would I?
(Laughing)
Yeah, that one still may be beyond my powers.
But that was, yeah, it was, and then I went and got a degree in theater, worked in a hospital, checking people in for a couple of years, waited tables for a bit, and then got my first programming job, and then I didn't write tests for the next seven years.
Okay, so why weren't you writing tests? This is not in a finger-wagging way.
No, no, genuinely, it
was an interesting question because I sort of knew that you were supposed to, right? And then I'm writing-- I did my best. Here I'm writing C++.
There is no testing tool, the off-the-shelf, ready to go, and the IDE that I was using at the time, which was like the free version of
Visual Studio, straight?
So very bare bones, and I didn't have any examples. This was before we had all of the stack overflow on the internet, so this is far enough ago that I was reading things from paper books. Like, later I was working in Java, and I picked up Spring from a book in Japanese, which I do not speak in any way, but all the example code is in English, so I had no context except the code snippets in this paper book to figure out how to make the thing work, right? So in ye dark ages,
how do you figure out what to test, what the format of a test is?
And it wasn't something that I had examples for. And even when I went onto my next job, which was much stronger software development practices, we have 20-year-old code base that's remarkably clean, extremely stable, 1% test coverage.
We had incredibly clean design that let you reason about the code in ways that tended to prevent the worst errors, but we just didn't have those kinds of tests. And what it turned out, part of what it was for me was learning how to write testable code first. Yes. So I learned to write testable code. And then
I, and actually remember someone coming to me and being like, "Oh, I found this feature you wrote "all while ago, and I wanted to tell you "it's beautifully laid out." It was so easy to pick up, understand. It's just, you didn't have any tests for it, but they were really easy to add.
And so I went and I looked at what Tessie wrote. And now I've got examples. And then I
was doing my very first management role ever. And I decided I was just going to like brute force this a little bit. And I started just spending time figuring out how to test this old untest like legacy code that's not written with any idea of Tess in mind. And I just started writing down all of the things I did for that. And I started doing presentations. And every time I'd say, "Well, I'm on the mobile team "and we write Tess."
And we...
It's a remarkably powerful leadership technique. It's to just pretend.
Well, it's a, like, maybe we aren't doing it right now, but we do-ish. So we hope to.
Doing that phrasing of it, if you didn't write Tess, you would feel not part of the mobile team.
Exactly. And so when you don't write a Tess, you think, "Why am I not doing it?" And then, and what happened is I would go into code reviews and instead of pointing out bugs, I would point out the Tess that was missing. So every time someone wrote a Tess, it caught a bug. And that dopamine loop is just so powerful.
Oh yeah, when you write the Tess and you predict red and it comes up red, and it's exactly the exception you predict that it would be.
And for a bunch of the
people I was working with were straight out of school. Yes. So they'd write the Tess not knowing it was gonna be, they didn't realize there was a bug there yet. And so they discover, each Tess is a discovery.
Right.
Is that a bigger rush than having the Tess pass when you think it's gonna pass?
Oh yeah. Like, oh, it worked great. That's nothing like, I think what's really exciting is when you discover something that you didn't expect to see.
Yes.
Yeah, yeah, especially if you can then look at it and go, "I'm so glad that didn't make it into production." Right,
yeah. So now how can we get the genie to get excited about writing Tess predicting red?
It's actually red, woo, it packs itself on the back.
So first it needs an endocrine system.
So genies don't have enthusiasm, excitement. Like those things are things that we give to, like I think right now, or I think of the collaboration, the thing that exists is us plus the genie. Yeah. It's not, the computer is just a lump that sits there.
And like a human brain is never gonna just sit there because we're constantly seeing things and hearing things and experience and having feeling hungry, maintaining our blood pressure, you know, avoiding passing out all of these things that our bodies do all the time. And the computer doesn't have any of that to do.
And so we are the thing that makes it excited about writing Tess.
So why is it that there's such a temptation to
make like
agents, it was gonna be this independent thing that was gonna do a bunch of work. And then we realized, oh no, it's actually in a feedback loop. And now the next version of that is looping. We just say, well, just keep doing this until you're successful. We keep trying to write ourselves or draw ourselves out of the picture. Where does that,
where's the motivation for that come from?
It's an interesting question. One thing I keep talking about is,
because one thing that comes up is like, oh, we can have medications prescribed by agents. Well, no, you can have, what you're saying is patients will prescribe their own medications as long as they use this program to do it.
And
if you skip that part, you miss that the company writing the agent isn't taking any responsibility.
Right.
Right.
They aren't saying, oh, I, like if you go to the doctor, you may not even have been complaining about blood pressure. And if your blood pressure is high, they will say you need to take this thing, right? And it's a different,
when I think there's the 10, there's a nervousness about humans. Like there's a nervousness about including humans just in things in general. We like to talk about
automated scientific things as not involving people. Objective performance reviews. Yes. Are one of my bugaboos. Because if you
don't have a subject, there is nothing judging anyone.
Right.
Right. And you can't--
Just say nothing that they're incredibly easy to gain.
Oh, right. Like also the, it's a, well, as soon as you tell people that something's objective, you can get away with making it incredibly biased and they will completely look over that because, oh, clearly it's objective. And so you get more biased systems by pretending that they are objective than admitting where subjectivity matters. And actually we don't care whether someone is objectively good at their job because we don't have a platonic ideal of a job for them to do. We have this particular job for them to do. And if they are bad at that job, it doesn't matter how good they are at some perfect job out in thought space, right? We actually have to be good at the thing that we're trying to accomplish.
And that's not an objective goal. It's the thing that's a subjective goal.
Plus the system is so complicated. There's all these feedback loops and there's lots of other people involved and there's long-term versus short-term.
And this is how you get,
you get systems that reward behaviors that you don't actually want out of all of it.
But I think that there's a tendency to avoid responsibility.
We don't wanna feel responsible for the things that are happening, especially if they're not our, we don't feel like they're our faults.
Yeah, well that hurts to be, to have consequences flow to you for something you didn't do. Right. That just triggers all of the, this is unfair.
Which is the job of management. Yeah. And it's why the transition from writing code to management is so hard for so many people is because you go, now you are responsible for things you have no control over. And the more control you try to have over them, the worse the outcomes are going to be.
Yes, which makes the, this shift to, let's just have the managers and we'll eliminate the individual contributors. That responsibility comes crashing back a hundred percent. Yeah. This reminds me of a story I read the other day where a autonomous vehicle whipped an illegal U-term right in front of a police car. And the police car pulled it over and it pulled over and they went to give the ticket and there's nobody in the car. Yeah. It's like,
somebody, it was illegal, it was unsafe. There needs to be consequences for somebody and there's just nobody to have consequences for.
Yeah.
Yeah, and if you, when we've written a set of rules for a world where only people take action and you can't erase yourself, because someone made that decision but it wasn't there and it wasn't then.
Yeah.
Sometime in the past, some programmer, let that be a constraint that could be relaxed.
And sometimes you want those, but I wrote, I was writing, when I was first writing self-driving car software back in 2008, we were doing the DARPA Grand Challenge and they would take the cars and they'd run them through an urban environment. And we had programmed ours, if you get stuck, if you can't move, relax constraints until you, you figure out how to get yourself out of it. And they had a place where they had blocked off a road with like a temporary roadblock. So our car sits there and thinks for a little while. And then the constraint it relaxed was the one that says, don't drive on sidewalks. So it just drove up on the sidewalk and drove around.
How creative.
Right.
(Both Laughing)
You could be so proud at that moment.
Right, and you're like, I understand what my software just did. And also that was not what I would have liked my software to do in that moment, right? So it
helps to have interacted with systems like
this in some ways for a very long time. Because if you just encounter it for the first time, it feels like magic. Yeah. It feels like something that usually you only get when there's a mind behind it.
And so the simplest explanation is, oh, look, I'm talking to a person. Or, oh, look, the computer is driving the car. Well, no, the software some programmer wrote at some point is driving this car.
And the software some programmer wrote under some set of incentives
created by
the organization they were in, and also the influence of what they ate that morning and whether they had a fight with their spouse. Like there's a lot that goes into it.
And venture capital.
Right, what financial arrangements where that creates incentives also.
Which other companies the board is invested in. What laws, tax, what tax laws? Like we saw when Trump cut
the amount of research and development deductions in year one that
it changed how companies were structuring their engineering departments.
And that's gonna flow through to all the downstream decisions.
And so I think in some ways,
one of my favorite shows is "The Good Place." And the conclusion of the show along the way is, the world is so complicated that we can no longer tell what the outcome of any of our decisions are. So how could you possibly know whether it's a good decision or a bad decision? And I think that that's overstating it because usually we can figure out why. It's very easy to feel like these are things we can't change.
Oh, I get to tax like, oh well. I think this is where being a geek helps because you can get around a lot of these with creativity. Whether it's cultivating a sense of resentment. Oh, they told you to do your job badly.
I think almost everybody's been asked at some point, well, how long would it take you to write if you didn't write the test? Yeah, that's, yeah. Even if the answer is
one and a half times as long as it's gonna take me when I don't have to debug all of those bugs.
But just channeling that into like doing the thing more
is a useful instinct to help people. Oh, instead of getting mad about it,
just realize it's your fingers on the keyboard and write more tests out of defiance.
I remember one of the favorite moments you told me there's a kind of
a workers strike called work to rule. Whereas if you have all these rules about exactly how you're supposed to do everything in a factory and the strike is the workers do exactly what it says in the book and nothing else. And your proposal was that we would have programmers perform one of these work to rule strikes and they had to refactor and they had to write tests and they had to integrate frequently and they had to collaborate. And the, but the problem with that as a strike technique is that you'd be so much more productive as a consequence. Right, yeah. Oh, yeah. We do know how to write good software, which is the title of a talk that we gave together. One of my highlights of my career was doing a keynote with you. And you had come up with this metaphor of the forest and the desert as a way to explain the difference.
Some people think that they're, you can write some tests, you can not write some tests and doesn't really change anything. Like it's a smooth transition and maybe it's a little worse or a little bit better.
And I think
we share an optimism that no, things really could be much better.
And we're baffled sometimes that people choose not to make, they choose worse.
Everybody can be better off.
Well, depending on what we think better is.
Yes.
And this is where having that instinct of asking why,
like what is different about this? Is there is a useful mental loop to have of, oh, the people do things that don't seem to make any sense. Okay, what's the reason? And that's how we came to the forest and desert was asking why, so you came up with this way of writing software. Yeah, and then people proceeded to not do it. Yeah.
And in fact, teams would do it. Be successful at building software and get fired.
Yep, over and over.
Over and over. Because it didn't take into account what it was that management actually wanted, which wasn't working software.
Yeah, yeah, yeah, productivity was not the point. Reliability was not the point. You can deliver those, more of those things and less of other stuff
and then you get fired.
Right.
Which is part of why I'm less
worried about our jobs than some people. I think the thing the AI agents do give managers is a sense of control.
They do exactly what they're told, ish.
Yes.
Not aspiring to mediocrity.
Yes.
They hope to rise to the level of mediocre.
Yeah, they're trying to get to average.
But they will do what you tell them to.
And you get to feel like you're in control of this set of things. But that also means that it's your fault when it doesn't work.
Yeah.
And it means that if it's not working, you don't have
collaborative levers to pull. Right. Right, one of the things I do as a developer is talk to executives and say, "Ah, if you would like more of this thing,
you're telling the developers this and so they are never going to give it to you." If you stop saying this, you can get the thing you want.
So what awakened the geek in you around politics?
A little bit, Howard Dean's campaign was the first one that spoke to the issues I was seeing. And he told the story of here is why things are the way they are and here's how they could be different.
And was talking about problems that I saw and then other people didn't seem to think were problems. And I think that's a very powerful moment.
Do you have an example?
Like student debt. Okay, this was-- Housing prices back before that was a thing. Like we were talking about it now, right? Many, many years later.
And it was partially that he was ahead of his time. So he did not have, he was telling
a story that resonated with the people who had already noticed.
But he was, if you're the first person telling a story,
your audience is gonna be a lot more limited.
And--
Well, you just sound like a whack job.
Or you just sound like a whack job, which is why you go yee-haw and then everyone makes fun of you for a while.
But the,
so that started it. And then it was really the Occupy movement because we had this very concrete problem of a lot of people were out of work. So 18% of millennials did not have jobs. And I started talking about cutting unemployment benefits after they had bailed out the banks.
And it started very simply. Someone was just like, "Hey, show up at Boston Commons tomorrow, we're all mad."
And so he showed up and there were a lot of people there. And there were some people who had some techniques or how do you get a huge group of random strangers to make a decision? And so we decided where we were gonna go. And then we started taking, we were feeding people. We passed health inspections, right? Figuring out the basic logistics of having a lot of people in one place.
Gives people something concrete to do together. Well, you're also talking about your political, like why would you spend your time being out here in the cold, in Boston? Like what brought you here? Because nobody was there because they were happy with how things were going.
Right, it was not a rave. Right, right.
And realizing that lots of people independently have similar problems.
And
then I took those same technique and there are people who have tools we can use to solve them.
So do you have examples?
Yeah, so one technique I use, I used a lot at work is the, I call it the Guild of Guilds. Because there's the idea that in tech companies you get together a bunch of people who work on similar kinds of things. Maybe they all write front end code, maybe they all interact with a particular
analytic system or work on a particular code base. And those people get together, even if they're on different teams doing different things, you get together every other week, maybe once a month, and talk about what it's like to work on this thing and are there things we could be doing better.
And the trick is to have one extra guild that is the leaders of each of those other guilds. And so then you get them together and they can talk about
what it's like leading one of these. Are you getting a lot of enthusiasm? Are you running into people just yelling at each other? Are you seeing that there's two parts of the company and they're fighting in lots of different guilds? Oh, maybe our incentives are off across the company and we would have never figured that out if it wasn't this group, if we didn't have this group. And then the magic is you make that group open and at each of your other meetings, you say, "Hey, if you're interested in how this meeting runs,
come to the Guild of Guilds because we're gonna talk about it." And whoever shows up is gonna end up leading one of these groups. Like if you are curious about how these groups work,
you will end up in charge of one.
Another form of geekdom.
Right, right. And so it's basically a way of finding the kinds of geeks who are interested in how groups of people do things together. And it creates a
way to get somebody new in so that you're never, someone doesn't quit and then the group falls apart. You always have new people who are interested and enthused and have things they wanna accomplish,
things that they're frustrated by that are motivating them to get involved. And all of that becomes the, makes it into a system that can keep going even after you leave the company.
That's something that I learned because I showed up on the first day and they said, "Hey, anyone who's interested in how this meeting just ran, the facilitation group is meeting over here." And that was a trap. And you do end up immediately with responsibility if you show up to one of the, but it was fun and it was interesting and it's a way to
build teams that can build software together really well.
Yeah, I went through a phase where I was really interested in that kind of group facilitation and I've really gotten away from it and now I'm wishing
that I had a good excuse to get back into it. Tell me this story about your friend, the preschool teacher.
My friend, the preschool teacher. So my friend was telling me about her class and she was teaching a group of kindergartner and one of them figured out how to count beyond the numbers that they had figured, learned how to count. They had learned to count to 30 and they were all counting to 30 together and they finished counting to 30 and he said, "31."
And another little kid looked over and said, "How do you know that?"
And my friend said, "You know, the first kid is smart, "but the second kid is going to go so much further, "so much faster because she wasn't just figuring "the thing out, she was asking, "how do you figure that out?" And so if anyone in the group is smart enough to figure something out, she can take it and figure out what they did and then adopt it herself.
So this is the meta geek.
Yes.
And it is in fact called meta intelligence
and is a thing that you can learn and teach and is an incredibly useful skill to pick up and is something that some kindergartners come with pre-installed and a lot of us have to practice and it means that you can go into any situation
and look at who's being successful and think about why are they being successful? What need are they addressing? Why were they able to
overcome the coefficient of friction wherever they are and start making change? Because the thing that stops us from doing better the most is just we don't think we can.
Right, people don't have that vision. Right. They don't imagine that they can. Right. And then sure enough, you can't.
Right. And sometimes there's a good reason.
Sometimes the reason quit four years ago and nobody has tried since.
And so the way that I tend to find out what stops something from happening is I try it.
And it means that you can't treat, I don't treat failure as a failure. Failure is just me figuring out what was gonna stop me. And then sometimes nothing does and that's boring. But--
(Laughing)
You fail to fail. Yeah. And then you succeed. Yeah, right. Got it. Okay, last question. What is it that keeps you up at night?
Oh. Yeah, this is a nasty question to finish on, but.
I just got started asking it and then I can't stop.
I think the thing that's so, there's a lot of possible worst case scenarios.
And I'm pretty good at thinking up worst case scenarios.
(Laughing)
And then sometimes they come true and it's,
yeah, I was certainly unfortunate. But it also means that I'm less overwhelmed than other people by what's happening. And so the case I'm most concerned about is not the robots do whatever they want. It's they do exactly what some people told them to do.
Because we know that there are people out there who don't care about the vast majority of humanity.
We know there are people who care about their own power over other people. And we are building technologies that could be a personal army, where you no longer need to collaborate with other people to commit mass atrocities. You just need enough money to do it yourself.
So bring thoughts. Thank you best so much. I appreciate it.
(Laughing)
And that's it. Thank you so much for listening.
Thank you.