0:00 Scott There are human needs that used to be met that are no longer being met and we're choosing for that to be true. Everybody, and welcome to another edition of this week's episode of How Many CTOs Does It Take to Screw in a Lightbulb? My name is Scott Borad and my trusty co-host.
0:36 Brad Brad Hefta-Gaub.
0:37 Scott And Brad, we have got a very special guest with us today,
0:40 Brad We
0:40 Scott none
0:41 Brad do.
0:41 Scott other than Mr. Kent Beck, who is, I don't know, in our circles amongst many people famous.
0:49 Kent I
0:49 Scott I
0:49 Kent think so.
0:49 Scott would say, Kent, welcome to the show. Thank you so much, Scott and Brad. My kids call me micro famous.
0:57 Kent Micro famous.
0:58 Scott There's
0:58 Kent That's fun.
0:58 Scott a small number of people for whom I'm notable, but it's not like a Brad Pitt kind of thing.
1:07 Kent I think there's probably some advantages to not being Brad Pitt famous.
1:12 Scott But you can go to restaurants.
1:15 Kent What's up with one example? But I think Brad Pitt could play you in a movie.
1:20 Scott I think it'd be a stretch for him. I'm
1:24 Kent Well,
1:25 Scott not going to say which direction I'm going to leave that you have you and your wonderful listeners can fill in the blanks on that one.
1:33 Kent okay, Kent, we've got a lot of questions and so many things to talk about, but for people who don't know that you're micro famous, perhaps you could give them the bio, the background so they know what has brought about your micro fame.
1:47 Scott Sure. I'm my name is Kent Beck. I have been programming since I was 12, and I'm now 65, so that's a long, long time.
1:58 Kent Mm-hmm.
1:59 Scott I'm best known probably for patterns for software development, JUnit and its copiers, test-driven development, which followed... After I had a testing framework, I was messing around as I do and found the JUnit workflow, extreme programming. I am the first signatory of the Agile Manifesto alphabetically.
2:28 Kent Is that how it worked, by the way?
2:30 Scott Yep, yeah.
2:31 Kent It wasn't who rushed as quickly to the front of the room to sign it as they could?
2:36 Scott No, no, no, no, because that would have resulted in deaths.
2:41 Kent There was a lot of excitement to sign it.
2:43 Scott We'll go with that, yes. While I was at Facebook, I came up with this 3x framework about how risk changes and development needs to change along with it.
2:56 Kent Hmm
2:56 Scott I'm currently, I published. Finally published after 18 years, a book on software design called Tidy First, question mark. Notes to aspiring authors never put punctuation in the title of a book.
3:12 Kent Oh, there must be an important backstory to that.
3:15 Scott Anytime you say, have you read Tidy First, question mark, question mark?
3:21 Kent People wonder, right?
3:23 Scott Yeah,
3:24 Kent I
3:24 Scott just don't.
3:24 Kent get it. Is it spelled out or is it just the... It's
3:26 Scott The
3:26 Kent the punctuation
3:26 Scott punctuation. It's
3:27 Kent mark
3:27 Scott just the punctuation.
3:29 Kent That's
3:29 Scott There you go. Hence, don't put punctuation in book titles. And most recently, I've been doing a lot of augmented development.
3:38 Kent Ooh, I
3:39 Scott Genie, you know, call it a genie because it grants your wishes, but it is not what you wanted.
3:45 Kent Augmented development. I love it. I
3:47 Scott love So
3:47 Kent it.
3:48 Scott that's my model of it is this exoskeleton for my brain.
3:53 Kent Yeah.
3:53 Scott So I can lift heavy objects that I couldn't have lifted just by myself. And sometimes it works that way. And sometimes it tries to grab the wheel to mix the metaphor further. Yeah.
4:08 Kent Oh, we're getting right into it. Okay, I want to ask about tidy up and I want to ask about what you're doing today. Actually, let's what you're doing today, but I want to go back just to the beginning. I think it was 53 years ago. So we had Uncle Bob on here and he talked to us about his first computer, which is a three bit computer, if I recall. Is that right, Brad? Yep. Do you remember, how did you get started in this whole thing or get addicted to this drug or however you want to describe it?
4:36 Scott Yeah. Well, my dad was an engineer, started out as an electrical engineer and became a computer programmer. We moved, the family moved to Silicon Valley before it was Silicon Valley. So in 1960, it was still mostly fruit orchards. And my dad was working in aerospace. And when I showed, he'd bring home books about computing. And I would just be endlessly fascinated by these books. I didn't really understand. What I was reading, like
5:09 Kent Mm-hmm.
5:10 Scott I still have the Burroughs 6700 instruction set manual here, which I can remember just being fascinated by. And it's still really interesting, but not very practical. And when I showed interest, he brought home a programmable calculator. And this was a machine weighed about 65 pounds, this giant thing that sat there and had a row of Nixie tubes and a Nixie tube was a it's an incandescent light bulb with 10 filaments shaped in the shapes of the numbers and the filaments are stacked up on each other. And so the first program I wrote would just count up and down and because they.
5:57 Scott the filaments were stacked up the it would go back and forth and like visibly recede and then come towards you and that was the first program that I ever wrote it was the the machine had I think 99 instructions you could have a program with 99 instructions and they were it's kind of assembly language ish And there was some encoding that would show up on these Nixie tubes on the front of it. So that was my first experience actually programming a computer instead of just reading about it.
6:34 Kent That's pretty cool.
6:35 Scott Yeah.
6:36 Kent That sounds like visually a neat thing to look at.
6:39 Scott Yeah.
6:41 Kent Yeah. You don't have it hiding in the back of your office, do you? Like Bob
6:44 Scott Oh,
6:44 Kent hid his
6:44 Scott no,
6:45 Kent little
6:45 Scott no, no.
6:45 Kent three-bit computer out and started cranking in front of us.
6:49 Scott Yeah, no, no. Several moves ago, I got rid of all my entire history of computing.
6:58 Kent This is a little bit of a detour. When Paul Allen was still alive, he funded something up here in Seattle called the Living Computer Museum. Did you ever get a chance to go to that?
7:09 Scott No, I haven't been there.
7:11 Kent It's since closed, unfortunately. He's passed away and then the pandemic happened. But they had all these working computers all the way back to, I don't know how far they went back actually, but it was pretty cool to see. There's a couple of floors of like they had technicians there that got all these old machines working and you could use them. There's another computer, the History of Computer Museum that's down in the Bay Area. Yeah, Computer History Museum.
7:36 Scott At what used to be Moffitt Field, where I was a high school intern working on a CDC 6600, analyzing
7:45 Kent Nice.
7:46 Scott data from the Pioneer Venus probe.
7:49 Kent Okay, so fast forward to about... The first time you came into my life, Kent, was with extreme programming and maybe about, I don't know, 1999 or 2000. Was that when you started talking about that?
8:00 Scott That's when the book came out.
8:02 Kent That's when the book came out and test driven development kind of came into my life around that. And it for me, it resonated and it still does. It makes a lot of sense. And it seems to be I'm curious to know in this new AI world that we got. we got going on it's still how do you how do you how do you see what you the kind of principles that we were all sort of taking in there how we how do we apply them to what as you said the genie is doing okay
8:28 Scott Well, the first part of the answer is nobody knows. So anybody speaking confidently about this is how you do eugenic development will be charitable and will say that they're overly confident.
8:45 Kent Okay.
8:45 Scott And if you did know, today you wouldn't know tomorrow. And
8:51 Kent Got
8:51 Scott that's
8:51 Kent it.
8:52 Scott an aspect of these kinds of technological revolutions. A lot of people say, oh, nothing like this has ever happened in the history of computing, and it's just not true. Over and over, we've had the ground shift out from under us, continue shifting for a while, and then eventually solidify. Now, you know, I'm my own person, so maybe this time is different, but every time people have said this time is different, it's not. It's not been different. So
9:17 Kent Yep.
9:17 Scott here we are. And it's an exciting time. But I also don't see any reason. that like options pricing's changed or net present value is changed or human beings have changed in some fundamental way so the forces that shape development haven't changed the tools have you know the Heisenberg's requirements that as soon as you give somebody the software they ask for they want something different Just
9:52 Kent I
9:52 Scott always.
9:52 Kent was literally just in a call with one of my fractional CTO clients this morning where I was basically imploring the engineering lead to be like, okay, you need to start building the thing that the product owner just specified. We need to take it out of their hands for a second and build the thing they asked for so that we could show them what they asked for. for so that they can tell us that wasn't what I want right
10:21 Scott Right.
10:21 Kent like like they're not gonna know the things that they don't want or that they do want until you give them something enough that they can actually play with to start to reason about it and criticize their own desires you know like
10:36 Scott And our terror of ambiguity leads us to pretend like that's not true. But I think it's good news. We can show people what they don't want much, much sooner than we used to be able to so that we can get on that path towards narrowing in on something that they do want, which always, if we do it right, opens up vistas for what we can do next. Like that gesture, that arc, some vague need, some delivery, disappointment. delivery, satisfaction, the world opens up. That arc hasn't changed at all. It's just shorter than it used to be. If we're thinking about how we need to develop now, we still need to center around that arc.
11:27 Kent Yeah. You use the term exoskeleton and you use the term augmented and I assume that you were talking about this new agentic world, this AI world. Yeah. And as soon as you said that, I thought to myself, that's how it, I think I agree, that's how it feels to me. It feels like as a builder, you're just able to build that much faster that, and that just helps. flush out the ideas like flush out or flush out whichever one we want to describe it as but it helps us it helps us really explore the idea space so much faster so that we can get to the ideas that matter
12:07 Scott And I have a bit of a problem with agents as a metaphor. Something I've noticed is at the end of a day of augmented development, I will be, it's a complicated emotional moment. I will be amazed at some of the leaps forward. I'll be excited about what I can do tomorrow, sometimes a little too excited when I wake up. I now I know the prompt that I want to issue that's not healthy. I'll be exhausted because I've gone I've covered so much more ground than I would usually cover in that similar amount of time than I'm used to.
12:56 Scott I'll also feel a little hollow. And this is something I just like in last week is the first time I started talking about this. There are a bunch of human needs that are no longer being met, that were met by coding that are no longer being met. It's easy to say, well, we have coding and it produces code and now we have faster coding and it produces more code, more better. But that was only one of the things that coding did for us as human beings, either individually as a relationship geek to geek or relationship with people downstream of our decisions. And one of those is a sense of competence. So there's this progression from you. There's some problem.
13:44 Scott There's a struggle. What's going on here? You know, we have a bug to fix. What's going on? I don't understand it. Then there's this moment of insight, which is profoundly satisfying. And then a solution. And that arc brings us a sense of competence. The more times you go through that, the more... confident you feel and like yeah bring on you know let me whatever tomorrow brings i'll be able to handle it and when we outsource the struggle and the insight and the solution when we take that outside of ourselves i no longer have that sense of like i did this it's it's like um it's it's like uh
14:33 Scott remote control weightlifting you know lift lift lift okay but i'm not getting any stronger the weight may be going up and down but the weight going up and down is not the point the point is getting stronger and and there are other human needs that are addressed by lifting heavy things It's not just that your body gets stronger, which it does, except if you lift too much and then it doesn't, but that's a separate kind of issue. But you also have this sense of like a progression. Oh, I'm stronger today than I was yesterday. And that feels good. Also a sense of.
15:20 Scott of confidence like oh you know if I run into something that's heavy and I need to lift it I can lift it oh and that feels good to walk in the world with a with a sense of like I'm a strong person not I'm a weak helpless person well the same thing is is true of coding the way we used to do it met our need for accumulating a sense of competence in the world and
15:47 Kent Mm-hmm.
15:47 Scott now it doesn't and that's a choice and part of that choice is that choice of the of the word agent or the metaphor of agent that we've outsourced our agency and now we don't have a sense of agency anymore and But it's not a necessary condition of the technology. You know, we picked up this tech. Sorry, I'm going on a bit of a rant
16:10 Kent No,
16:10 Scott here. I'm
16:11 Kent it's great.
16:11 Scott just going to go with it because I feel like it. We've picked up this shiny technology and we are amazed at what it's capable of doing. I remember the first time my friend Keith Adams explained LLMs to me, this next token prediction thing. And then he said. And it can write really good code. And I said, no, no. Like, how can that mechanism possibly balance parentheses? Just to pick a random example that'll clearly be impossible. Well, it turns out it can balance parentheses and mixture vectors and chain of thought. It can do. much more than we expected it to do. So that's cool. And I understand that as a technologist,
16:56 Scott as that kid obsessing about the Motorola 6800 instruction set encoding, I can understand the fascination with it, but enough. There are human needs that used to be met that are no longer being met and we're choosing for that to be true.
17:18 Kent Are you saying, Kent, I just want to double click on something. You started this particular rant, to use your own term, with saying that by picking the word agent. we, and I think what you're saying, I feel like the thread you're pulling on is we call them agents, therefore we took away our agency.
17:40 Scott Mm hmm.
17:41 Kent Okay. Are you saying that?
17:43 Scott There's another I don't know. And I don't know what the metaphor is. I could go to chat GPT. And actually I did this to say, okay, you know, here's my complaint with agent and blah, blah, blah. And give me five alternatives and blah. And it spewed out a bunch of stuff. And then I I had, again, that sense of hollowness because I hadn't personally struggled with finding the metaphor that fits for me.
18:08 Kent Yeah. Interesting. Well, that's part of what I was trying to better understand. By sort of anthropomorphizing them and sort of treating them that way, is that the core of what you think is or is it more the because there's plenty of people who are making the case that it's, you know, the strength of being how to become a strong, competent engineer means you have to have the friction, the friction of trying to solve the problems. And so. And certainly one way to interpret your stance on this is, hey, we've intentionally removed the friction here and that will have these downstream effects.
18:51 Scott Yeah, absolutely. And I believe there's another way. I don't know what it looks like. If I did, I'd be working on it this minute. But there's definitely another way. And this goes back to my roots in small talk. You know, small talk was the language I most fell in love with. And it was it was started. Small talk is a computer support for the creative spirit in everyone. That's the like, wow.
19:23 Kent Yeah.
19:23 Scott And I believed that and I worked towards it and I'm still working towards it. Agents, agents are. You know, if you tried to come up with that same kind of phrase, it's like agents make programming easy or something. And I don't want like.
19:41 Kent I feel like when I look at the advertising that OpenAI and others are doing, they're actually going after a similar kind of mission or motto, right? I think you said the computer support for the creativity in everyone. That's at least that they're. Presenting it as.
19:59 Scott Now anyone can do it.
20:01 Brad now anyone can do this or
20:02 Scott Yeah,
20:05 Brad make your make whatever you want to make right you know it isn't always about just code it's about a lot of stuff
20:11 Kent Well, I would agree if I weren't if I wasn't using their tools every day and
20:17 Scott right.
20:19 Brad practice
20:20 Kent and and and there's a big difference between. This tool will help you be more creative, and this tool will remove the struggle.
20:32 Scott Yeah. Yeah.
20:32 Kent Huge difference.
20:34 Brad Right. Yes. One's a catalyst. The other is something else.
20:38 Kent I went down this rabbit hole. What's the difference between toil and struggle? Toil is work that you have to do to reach your goals but leaves you unchanged. Struggle is work that you do that transforms you in the process. And I want... programming tools that support me through the struggle. They don't try and remove the struggle. They support me. Okay, here's an interesting decision. This is a trade-off. If we allocate the memory like this, then this is going to happen. If we allocate the memory like that, then that's going to happen. I don't know. It's not clear which direction to go. What do you want to do, boss?
21:24 Scott Yeah.
21:24 Kent That's the tool I want. And then I can say, huh, well, you know, write a simulator and what's going to give us a differential diagnosis or how do we, what observability do we need to insert in here? That's what I want. I don't want it to say. Pat me on the head and say, oh, poor little poor little grandma.
21:49 Scott Yeah, I think that's a fair point. I think that it is interesting and I wonder if it is a way of us coaching our engineers, coaching ourselves as engineers to engage with the tool. in the manner that you're describing, right? Like I can tell my tool, like, I want you to come to me with all of the questions that you want me to answer for you. I want to, you know, so it's like, you know, I've been a big advocate of like the plan mode, you know, well, I ask it to do something and it's, it's, this, it is interesting to me that I, I spend a lot of time. with the tools. I'm going to try not to call them agents in your presence,
22:35 Scott Kent.
22:36 Kent Jeannie. Jeannie is a really good word.
22:38 Scott I spent a lot of time with the genies and a lot of that time, I agree with your assessment that I feel both excited and energized and quite exhausted afterwards because I spend, I feel like I spent a lot more time thinking through a lot more hard problems than I would in a normal day of the old way. In a normal day of the old way, my hard problems might stump me for a couple days. And when I showed up at the standup for two days in a row going, I'm still working on this hard problem, right? My colleagues looked around going, some of them thought. well it shouldn't have been that hard right you
23:22 Brad Right.
23:22 Scott must be doing something wrong or they think or they give me some sort of like you know an empathetic you know look in the eye of like yeah that's oh wow you've been stuck on this for a couple days brad well i'm glad we assigned it to you like because that one must be a hard problem and then when you got to the end of those two days of being stuck by that hard problem or maybe more days or even just a couple hours you you i i agree with you that there was this moment of like like man I solved it like wow that was a hard problem and now today I feel like a lot of those problems are coming at me so much faster and I'm spending my time now to be fair I I have my career has been up and down the ladder insofar as I still write code today, but then I've also, you know, managed, you know, teams of 200 engineers. So I was the VP that was above multiple directors above multiple, you know, engineering managers.
24:19 Scott And sometimes today I feel much more like I'm in that executive role where I've got this this team of these. anthropomorphize genies that are out there and they're only coming to me with like the really hard problems or i'm spending my time thinking really hard about oh what did they all do let me let me let me they now need to give me reports that i can then reason about like what did you actually do down there team of genies you know
24:48 Kent Right. So what would the development tool look like that didn't alienate you? You from the product of your work
24:56 Brad Can I answer that question with a question?
24:58 Kent Sure.
24:59 Brad Do you, this is for both of you, really, you know this concept of manage your time and maker time.
25:05 Kent Yeah
25:05 Brad Do you feel like when you're doing augmented coding, as you call it, that you miss out on that state of flow? So I've had that experience in the past, right, where you just you come up with the solution, Brad, after two days of stand up and you sit down and the next three hours at the computer, it just comes out and it gets done. Right. And is that missing from this experience? Is that the piece that's missing?
25:35 Kent It's not the only piece, but it's certainly a piece that's missing. The slow, incredibly slow latency. of the current set of tools is the kind of thing I'm talking about. Somebody said, well, if we let the genie chew on this for 10 minutes, we can give you a good answer. Nobody said, well, what are the other consequences of going away for 10 minutes? I would much rather have the genie come back once a minute. or once every 30 seconds, do the work in smaller chunks. Even if that costs whatever, tokens, electricity,
26:22 Kent whatever, the trade-off I want is one that serves my needs, and my needs is... You know, I want sub-second response.
26:31 Brad Yeah.
26:31 Kent So what does the genie look like that's giving me sub-second response? Okay, so that doesn't fit the LLM model. Well, boo-hoo.
26:41 Brad Does the genie have to come back as fast as a pairing partner would come back, as fast as a human if you and I were coding together? Is that really what we have to get to?
26:51 Kent Yeah, that seems that's that certainly seems like the rhythm that we've all been our brains have been evolved over many, many years to
26:59 Scott Yeah.
27:00 Kent deal with. So, yeah, that's what I that's what I want. And if you said, oh, well,
27:05 Scott You
27:05 Kent but.
27:05 Scott want the extreme programming pair programmer genie that's sitting next to you and you're typing in the editor and it's typing in the editor and you're doing the classic day one of extreme programming.
27:19 Kent I don't think these are people. And I don't want to think of them as people. So I'm careful with my language when I pick. If they can't say no, then I'm not paraprogramming. I think that it's my, so I'm still struggling with the metaphor. And there is a really good metaphor, but nobody knows it, which is the Emmanuel Ansys. So if you're a composer and, you know, your your brain is out in the galaxy and sometimes you just need somebody who knows about composition, like they may be a Ph.D. composing. graduate but just not at your level to finish the things that you start and to and to organize work and to remind you of things uh and and that's the through many years in the arts there's been this role of somebody with domain experience it's not us so a servant is kind of kind of close
28:27 Kent Um, but the servants don't necessarily know how to do the things that the, the employer knows how to do. And this is a different, different relationship. It's the junior composer. I want the junior programmer. I want, I want to be able to say things at quite a high level. Like I'm not sure that I don't feel confident that this software is reliable in production. Oh, scurry, scurry, scurry. Here's evidence that it is or here's evidence that it's not. And here's what I learned in the process. And here's a decision that you made two days ago, two weeks ago, two months ago that led to this vulnerability appearing.
29:18 Kent That's the relationship that I want. I want support. I don't want somebody to outsource at my agency.
29:26 Scott You don't want it to bring it's necessarily it's yeah, it's a tough call, right? You don't want it to you want it to you want it to say no to you, you want it to push back, you want it to bring you data, you want it to be an expert at bringing you data. But you also don't want it to sort of work on its own agenda. Right.
29:48 Brad Correct.
29:49 Scott Yeah.
29:49 Kent No, no, it's my agenda.
29:51 Scott Yeah. I mean, I'll answer your question, Scott, as maker versus manager. I 100% think I've pivoted into manager mode. It's all manager mode. I told you this like six months ago that I think it's like every developer using AI coding tools should start thinking of themselves as engineering managers who are managing these other things that are. processing. Now, I hear you loud and clear, Kent, that that has side effects, right? But no doubt in my mind, the way these tools have been presented and bundled and sold to us, it's you're in manager mode. And I'm constantly thinking about the fact that, you know, much like as the, you know, kind of like.
30:36 Scott As you go up those levels of engineering management, when you went from just being the tech lead to being maybe the engineering manager of multiple pods that had different tech leads, then you're the director of it's got multiple engineering managers. You know, in that mindset, you're constantly sort of task shifting between like, I'm going to go look at some strategy now. I'm going to go look at the team that is, you know, let me go double check the board of the team that is working on critical component A. You know, let me, oh, I'm seeing something in that dashboard. Let me go talk to that engineering manager and say, what's going on here? This critical component is, you know, we need this, you know, whatever. Or how's your team doing? Or I'm seeing like these increased error rates on your service that you own, right? And you're kind of in this constantly bouncing around.
31:22 Scott And I feel like today that's. My biggest frustration with the tools right now, I say this out loud and I'm like, wow, I can't believe I'm going to say this out loud. My biggest frustration with the tools right now is it doesn't allow me to task switch quickly enough between all the different things that I've got going on while still being able to maintain my cognitive load, right? And so that's why I walk away tired is because I'm. and task switching all the time and i think you're right kent that it's because these things are kind of packaged as a they go off and work for 10 minutes it's like
31:59 Kent It reminds me back when I used to have to wait 10 minutes for my C++ compiler to run, right? And what did I do? I got distracted, you know, and God forbid I have two-factor authentication on my phone because next thing I know I've lost 30 minutes on TikTok reels, you know? And Yep. so like that, that like waiting 10 minutes. Mm-mm. I agree with you. That's like, that just makes me want to be either like I get distracted and do something completely useless or I try to pick up yet another task that is going to be more productive and now I'm just context switching after context switching after context switching.
32:35 Brad Or I sit and I'm kind of bored and
32:38 Kent Yes, you're bored.
32:39 Brad in none of those cases you get that. human soul fulfilling condition that you get when you've overcome the struggle and finally get into the flow state and the answer just comes out of you right
32:54 Kent Yeah. So the cycle that I see going is people say, well, if we're autonomous longer, we can get more done. And our. Human needs are being less and less met the longer the feedback loop is. But we wait longer, we get more done, we wait longer, we get more done. That cycle is running. As opposed to saying, what is the human cycle? What is that feedback time? What kinds of things? How can... How much work can we pack into a second? Let's optimize for that. Let's just say, all right, I'm going to be primarily waiting on the human.
33:45 Kent So my maximum response time is one second. How much work can we pack into that? It's a little like test suites. You know, if you have a big piece of software and it grows for a long time, the test suite gets longer and longer and longer. But you can still ask the question, how much confidence can I generate in one second of running my test suite? Oh, well, if that was true, I'd have to have more unit tests and I'd have to sort the tests by likelihood of failure and blah, blah, blah. And then in a second. Can I get 80% of the way there, 20% of the way there, 99% of the way there? Like if I'm almost guaranteed that if a test is going to fail, it'll fail in the first second,
34:32 Kent then I don't have to run the two-hour test suite. I can just run it for one second, but it's a different mindset to say, how much confidence can I pack into a second? How much? agentic genie-enabled work can I accomplish in one second? How much, you know, and then attention has these cut-off points. If it's a second long, if it's, you know, and gamers talk about the critical 100 milliseconds. You know, so in 100 milliseconds, what can you get done in one second? What can you get done in 10 seconds? What can you get done in 10 minutes? What can you get done? And if if instead of saying, well,
35:20 Kent if it goes longer, we'll get more done. We said, no, here's the time budget. What can we accomplish here? How are the tools going to come out? Nobody knows because nobody's tried it, but I think you'd end up with a very different workflow, a very different emotional experience, a very different intellectual experience using a tool that was built with those constraints as opposed to the set of constraints that everybody seems to be chasing after right now.
35:51 Brad Well, I think, yeah, you're, I mean, I'm really. Love how you're talking about the human experience of the programmer, and nobody's talking about that except for maybe you. They're just talking about how can we get more faster.
36:06 Kent And with fewer people, with less judgment, with less domain understanding.
36:14 Brad I'm curious to know earlier when we were talking, you talked about, hey, there have been previous transformations of how technology worked. Was there the same experience for the previous times was the human condition considered or was it the same experience where the humans were just alone for the ride and then had to adapt again to the technology?
36:35 Kent Well, I think there's a there's a natural arc to it. It starts with micro when microprocessors came out. OK, the geeks love their computers. Then the mini computer came out and you could see it, you know, didn't have to be in a special room. That was really cool. But then microprocessors came out. mind-boggling this is a whole computer are you kidding me oh I love this thing we can put these everywhere oh but there's these limitations to them but we could use it for this and we could use it for that and we can't quite use it for this yet but if only the clock rate went up or we had more RAM we could and so it was very much
37:22 Kent we have there's this thing and it's revolutionary and changes your vision for what's possible but we're gonna uh we're gonna just like technically what's possible let's just do whatever whatever we can and then you do something and then you realize no there's eight other things i could also do and it's exciting and then The manufacturers would come out with another machine that was, you know, the clock rate went up by two megahertz, almost said gigahertz. Wow. I haven't had to say megahertz in a long time, apparently. You know, the clock rate would go up or the, you know, now we can have an 8K RAM board. How are we ever going to fill that?
38:10 Kent And it was driven
38:11 Scott No
38:11 Kent by
38:11 Scott one will
38:12 Kent the
38:12 Scott need
38:12 Kent cost.
38:12 Scott more than no one will ever need more than 640
38:15 Kent No,
38:15 Scott kilobytes of
38:15 Kent of
38:15 Scott memory
38:16 Kent course not. So that cycle and experience of the as a geek, the emotional experience of that was driven by the technology and what it was capable. And then eventually you say, OK, OK, OK, but what what should we be using it for? Just because you can doesn't mean you should. What of all these things does it really make a difference for? And what of them does it not matter? What of them is it actually counter to human experience? And then the human experience comes to the fore. And that's what I'm calling for. Okay, we picked up this cool, shiny object and we're like, well, what can this do?
39:06 Kent And I can wear it like this and I can wear it like that and maybe up down on the back of my head. What like, okay, fine. Enough. Enough. It's time to think about how people feel at the end of a day of using this. Yeah. How people's relationships. with other makers are affected by these tools and how they can be enhanced? My relationship as a programmer to people who use my programs, how can that be enhanced by these tools? Not just blindly going down the faster, bigger, more. But like how how do people feel about this and and
39:51 Brad Mm-hmm.
39:51 Kent the rhetoric of all programming jobs are going away is just that's a clear sign that somebody.
39:59 Scott lost the plot that they're so enamored of this thing that they've built a little like the uh the ancient greek story of narcissus they're just so enamored of this thing that they can't see anything else no these things are here to to meet human needs
40:22 Brad Wow, tell us what you really think, Kent.
40:25 Scott Yeah. Ken, I want to pivot for a second and ask about something you just said, because it reminded me of a tweet and a blog post maybe you wrote about a year ago that really caught my eye. That probably caught a lot of people's eye. It was something along the lines of 90% of what I know has become useless, but the other 10% is a million times more valuable. Thousand X. My question for you is, you talked about all the programmer jobs are going down. What do you actually
40:52 Kent do? What do you actually think is going to happen to the profession, the people in the industry, the jobs? Because
40:58 Scott Absolutely.
40:58 Kent there's lots of people out there asking that question right now.
41:00 Scott Absolutely. And nobody knows for sure. There are some basic principles that we can use to have. I'm not going to say confident, confident guesses. We can acknowledge that they're guesses, but we can have some confidence in them directionally. So Jeevan's paradox is something that I think about a lot, which was Jeevan's was this, I guess you'd call him an economist who noticed that England had gone through the early steam engines. made consume so much coal that England was was going to run out of coal and that drove a lot of like James Watt to improve the efficiency of steam engines
41:55 Scott Which should reduce the consumption of coal, right? Only makes sense. And that's not what happened. What happened is the consumption of coal went up. Now, fortunately, the steam engines were being used to pump out coal mines, so they didn't actually run out of coal. But when you make something, when you make a scarce resource cheaper. Or when your use of some scarce resource is more efficient, you'll end up consuming more of that resource. And I believe like directionally, I don't see anything about the current state of the world that leads me to any different conclusion that the demand for programming will go up so much that even if we're more productive and that's a whole nother rant, the misuse of the P word.
42:41 Scott um that that there'll be more demand for programmers not less and the analogy i use is imagine you're a carpenter now i should look up when it actually happened you see your first power saw and you think oh that's it carpentry's over you know i spend days and days just sawing stuff and now the same thing gets done in minutes and Yeah. Carpentry is over and I need to find another profession. Like, no. Carpenters just got much more effective. They could spend their time doing. making more highly leveraged decisions making greater use of their skills not less use of their skills and so that's how it feels to me when i talk i uh i keynoted the splash conference yesterday and a bunch of students in the audience and my heart goes out to them but also what an awesome time to be a geek like you don't you don't know what the job's going to be
43:47 Scott But you know that the highly leveraged, Brad, those kind of decisions you were talking about that just that come up more frequently now, you have way more leverage to your skills than you had before.
44:02 Brad Yeah.
44:02 Scott And I think the natural consequence of that is a greater demand. Now, this is not to say I listen to a wide variety of podcasts. And so I'll listen to some Doomer podcast, you know, where Jeannie's going to turn us all into gray goo kind of thing. And I think, what is anybody even going to pay me to do in two years? I have no idea. So it's not that I escaped the existential angst of the zeitgeist, but in principle. I think this is going to lead to a much greater demand for the kind of skills that we built.
44:48 Scott Now, there's another question, which is if you don't have to go through the struggle of learning how to code, like, how do you build your skills? So I published two books about communicating with human beings through code. You know, how would you write code so that other people could read and understand your intentions? And those books are just out the window.
45:13 Brad Yeah.
45:17 Scott Nobody cares at that level. But it doesn't mean that the need to communicate to other human beings is gone. It just means that the medium has changed. Did they answer your question, Scott?
45:27 Kent It did answer. I think you touched on a key piece, which is I'm so glad you brought up the students just coming out of school. We don't know what these jobs are going to be like. And I think probably the biggest thing that's changing about it is if you want to have your if you're starting your career and you want to have 30 or 40 years in this industry, we're at a phase where you have to be really excited sort of about. getting in the mud and figuring it out if what you were excited about was like well this is a good paying job and i'm pretty good at it and i got a degree in it so now i can go like get employed you're probably not going to do very well if you're a person who thinks it's pretty fast just like you were saying about like you know The microprocess right if you're if you think it's pretty fascinating and you think it's kind of fun to go try to figure out how to make it work
46:15 Kent You're probably gonna have a long long future with it as I would think
46:19 Brad Yeah, you guys remain curious. You got to be curious.
46:22 Scott Yeah, I'm not actually worried about the kids. And I'm not worried about this senior developer, you know, who's got a brain full of ideas that they've just not been able to execute on because it's been too much work. They're going to be fine. They're going to have a field day. The people in the middle, as you say, the people who are just trying to cash a good paycheck. either you're going to have to up your game or you're going to have a hard time remaining employed. That certainly seems true to me.
46:56 Kent Okay, before we wrap up, I have to ask one more question because you put a landmine out there that I can't bridge with us pushing that button.
47:03 Scott Sure.
47:03 Kent The misuse of the P word.
47:07 Scott Productivity. Oh, gosh. Productivity is defined as the ratio of output to input. Full stop and a story. The question is always what are the units, you
47:22 Brad Yeah.
47:24 Scott know, and story points per per, you know, per discounted hour like nobody cares. I was reading a blog post by somebody that I follow closely because I think they're on top of stuff and they said they said counting lines of code is stupid. Everybody knows that. But it's impressive. That the genie can churn out that many lines of code. And I'm like, no, no,
47:48 Brad Yeah.
47:48 Scott it's not. It's absolutely not impressive. If it could churn out more understandable code that was shorter, that was more foolproof, that embedded more options than what I can do, that would be impressive.
48:07 Brad Yeah, I had two, I had, I've had at least a couple of folks in my career that I've worked with as peers who had a couple gems I feel about like that concept. The first one was. This guy I worked with for years who his whole like his whole passion was he wanted his git line deletions to always be more than his git line additions. and he would of course he would game the system as much as he could like if somebody had added a module he'd be the first person to volunteer to take that module out once it was once it was deemed you know no longer necessary but he was just like he just wore that like more negative lines than positive lines it's just such a strong badge of honor and then another another really genius engineer that i worked with for years um one of the one of the one of the smartest engineers i've ever worked with
49:00 Brad I just remember him saying once, there aren't bugs in the lines I didn't write.
49:05 Scott Yeah.
49:05 Kent Yeah.
49:07 Scott But you see code coming out thousands of lines and you're thinking, well, and we've all had this experience coming across big chunks of code and you're like, this could be replaced by. You know, this microservice could be a SQL call kind
49:29 Brad Right.
49:29 Scott of thing and you do it and are you going to be impressed that somebody wrote the microservice and wired it in and made it observable or you're going to be impressed that you avoided the need for it entirely and the genie is way biased towards. churning out all that code which is what gives me coming back to an earlier theme it gives me hope that the genie can actually do something useful in a second because it does stuff that's really not useful in 10 minutes
50:03 Kent Mm-hmm.
50:05 Scott So what if it, you know, maybe don't.
50:08 Kent Can I come back to the units question?
50:09 Scott Sure.
50:10 Kent I've developed a hypothesis on one of the units that's better than lines, that I think is better than lines of code. And it's not much better, but it's just that I have for the last few years just been centering around deployment frequency. How often are you changing the thing? I'm going to just assume that roughly the size of changes kind of works out to an average. a bunch of them but just how often is you or your team making improving making changes they might not be improvements but theoretically they're improvements to the system that that is the best unit everyone wants to try to connect it to some sort of value or revenue which is very tricky that that's the best metric that I've I think it's it's the best one I've got So what do you think about that?
50:54 Scott Yeah, two responses. One is the only units that everybody agrees on is dollars.
51:00 Kent That's right.
51:02 Scott Or there can be some kind of mission statement, if it's not a commercial thing, there can be a kind of mission statement. And then you can say, then the units is whatever the units of that mission are. The problem is it's really difficult to attribute. either improvement or degradation to a single person so i don't know you know brad you're fired scott you did 70 brad you only did 30 bye-bye you're off the island so why you would want to do that i don't i don't know I mean, if somebody's really dogging it, everybody knows that they're dogging it. So but anyway.
51:44 Brad You don't need to necessarily need the metric to be able to remember,
51:47 Scott Right.
51:48 Brad identify
51:48 Scott Right.
51:48 Brad that. Yeah.
51:49 Scott The unit. So unit, the only units that that matter in a in a. The
51:55 Brad In capitalist
51:55 Scott thing that everybody
51:55 Brad society?
51:56 Scott agrees on is dollars, and people don't want to talk about that. And then I had a second point, and now I'm trying to remember it.
52:06 Kent Well, let me, while you're trying to think of that second point, I have not been thinking about deployment frequency in terms of like evaluating an engineer. Oh,
52:13 Scott Yes.
52:13 Kent let's get your thought before it goes away.
52:15 Scott So I did this thought experiment and a few prototypes that people have. have been remarkably to me unwilling to follow up on it's called limbo and it's called limbo because the song asks how low can you go so imagine the three of us are working on some code base and i extract some helper function from some big glop of code there's no reason that that can't be reflected In that moment in the code base that you two are working on, I haven't broken anything. You know, it's automated refactoring, guaranteed not to break anything, gets distributed instantly to you. So, but how about production?
53:02 Scott Sure, why not? Why do you want your local version to diverge from production at all if it's safe? So
53:11 Kent Hmm.
53:11 Scott limbo asks that question. What if what if each developer was pushing to to production thousands of times a day, not just not just 10, like any any wuss can do 10. Come on, let's let's crank it up. I have experimented with this with small teams on small projects, but I can't get anybody to try it at any kind of scale. Not even for a week's workshop or something. So I think that's possible. Now, there's definitely a tension with the genie. The genie wants to do things in big glops, right?
53:50 Kent Mm
53:50 Scott It wants to write a bunch of code and then write a bunch of tests. And there's some evidence that that may be the most efficient way to use the current round of tools. in terms of tokens electricity dollars whatever so i don't know if this idea would work for the augmented development almost said agentic and i don't want agentic remembering that uh i don't know if this would work for augmented development but the genie would have to have a very different workflow Like, let me do something that's pretty, pretty, it's certain to be safe, has to be certain to be safe. If you're pushing everything to production all the time, you have to be a million percent safe.
54:41 Scott or and reversible because sometimes you're going to make mistakes um so it's progress has got to be broken up into smaller much smaller chunks many more much smaller chunks than it used to be in uh in g piles phrase i can't see why that's not the future but it doesn't seem to be the way everybody else is going
55:06 Brad Yeah, everybody's bragging about how much they can one shot. and
55:09 Scott Yeah,
55:09 Brad you're arguing for the exact opposite of that yeah
55:11 Scott correct.
55:12 Brad yeah and
55:14 Scott Yeah. How many shots can you take?
55:16 Kent Because that's what we just tried to do for like 30 years is do smaller and smaller bits.
55:20 Scott Yeah.
55:20 Brad oh yeah there's no doubt in my mind that like the whole like there's this massive tension of like everybody's like one shot big huge things like bragging about the entire app was built with a single prompt and The fact that what we learned is that we don't really know what we want and we know that if we do it in smaller pieces, we're going to have we know we're going to have more predictability and more and higher quality. And so it's just like this like, wait, how are we like why are we running away from all the things that we've learned over the last 30 plus years about how to write software better?
55:55 Scott If the scope is small enough. One shot can actually work. Last week I taught a software design course, a day-long workshop in Copenhagen. And I build lots of little one-off tools. Let me visualize this. visualize with that or you know here's a 3d thing or blah blah so you know problems come up and I want some specialized information and the genie is wonderful at coming up with these one-off visualizations so I built a visualizer for the call graph of a b-tree implementation that I did
56:41 Scott And so I showed it, they demoed it to the class. Yeah, that looks interesting. And I thought, wow, I wish I could distribute this. But, oh, you know, distributing software and making sure that it works and then installs and blah, blah. I thought, wait a minute, I came up with this with the genie. I went to the genie, I said, write a prompt that will result in the tool that you just built. Out came whatever, 200 lines of stuff. And then I said to the students, here, run this locally on whatever agent you're using.
57:27 Scott uh whatever code base you're using whatever language you're using and uh tell me if you end up with the same kind of thing and there there was each one was a little bit different so i call these tool seeds because it's like giving you an apple seed instead of giving you the whole tree you're going to plant it in your soil with your light with your rainfall and it's going to grow different in every other place but we don't have to like the the genie is so good at helping me understand the code if I if that's how I use it but it's not good at all at sharing that understanding with other people look so this is along those lines of how can I connect more
58:15 Scott by leveraging the strengths of the technology that we have and distribute that to other people and then get the benefits. So now this GitHub repo's got 10 tools in it, you know, not a gigantic success, but it's something where people can go and like, oh, this proved useful. All right, well, let me look at the... look at the description of it and see if that matches the kind of problem that I'm having and then I can have a tool you know with the IDEs was a big revolution And every once in a while, there would be just the tool that you needed to solve your problem. And it was a magic to find that, you know, you dig into the details of the debugger and you really understand the difference between step into and step over and you get the right and you get
59:13 Brad You're
59:13 Scott the function
59:13 Brad speaking Scott's
59:13 Scott keys.
59:14 Brad language.
59:14 Scott So, yeah. And that that moment was just magical. It was like this is going to be a really. Really hard problem. Oh no, it's actually easy. The genie can give us more of those instead of taking away the need for them entirely.
59:32 Brad Yeah.
59:34 Kent I think if I could go back to my happiest time in this whole career of mine is when I got to use the debugger. You're inside it. You're like living in the matrix. It's amazing. It is the best. I loved it. I haven't used a debugger in a long time.
59:47 Scott One of the things about TDD, though, is you just, if you're really living with TDD line by line, just, you
59:59 Kent Yeah.
59:59 Scott know. love me a debugger absolutely and and worked on building them and whatever but I just stopped needing the debugger entirely because it tests
1:00:10 Brad You don't need it as much.
1:00:10 Scott would fail like oh that's what's wrong
1:00:14 Kent Right.
1:00:14 Scott Yeah, that's right.
1:00:15 Kent Right. Right. You don't get you don't even get to the debugger because your your tests stop you from getting to that point because it's right.
1:00:22 Scott It's a different approach to debugging, right? Yeah. Well, every once in a while there's something that you didn't think to test or didn't know how to test for and then, yeah, you have to get deep into it and look at the whole call stack and where are the variables and what's the. What's the data flow? How does data flow in this thing? And are there shared pointers? And that is a moment where you're trying to hold the state of the computer in your mind. And when it works, it feels glorious.
1:01:00 Kent Kent, I have a, let's try to kind of. Go back to this question of like, what do we do with this? And to your point that we can't really know how this is going to play out, we can we have some educated guesses, but we're not going to know for sure what and this tension of like we're losing the friction that's going to cause us to not be good at understanding this. You know, the folks that are in the middle to describe your your. point earlier. What kind of advice would you give to CTOs or engineering managers as they try to work through this tension with their teams of engineers, some of whom are, some of those engineers are pushing back saying,
1:01:45 Kent I don't want to do this at all. I'm not going to do this. It sucks the joy out of my job or it's not as good as me. And then others that are fully embracing it, maybe embracing it in a really curious and, you know. a way that I think you're kind of encouraging people if they are going to use it the augmentation to use it and then you have others that are embracing it but just YOLOing I just feel like we've got this like mix of this population and how what advice are you given how should we handle that
1:02:18 Scott So step one is to make sure that you have skin in the game. that you're not telling people to do something that you're not doing yourself and
1:02:27 Kent Oh, for sure. Yeah, yeah. That's good advice for lots of management.
1:02:30 Scott yeah yeah absolutely and and it's it's easy to come up with reasons why you can't do that and this is fundamentally a trust problem you say you need to use these tools people don't trust that you have their best interests at heart With a certain amount of validation, right? Use these augmented development tools. Oh, you're now more productive. Okay, half of you are fired.
1:03:02 Kent Right.
1:03:03 Scott Wait a minute. Why did I like I should have said no. I really should have said no. Now maybe I would have been fired anyway for saying no, but If I'm going to get fired anyway, then why am I even doing this? So making sure that as a leader that you're walking the walk, number one. Number two, remember that if these tools were so fantastic for the people you're asking to use them, they would be choosing to use them. So if they're not, there's reasons. And then third, I go back to the technology adoption curve,
1:03:50 Scott this innovators, early adopters, early majority, late majority. There's just going to be this curve.
1:04:02 Kent Yeah.
1:04:03 Scott There will be laggards. There will be early people. Um, and so saying day one, everybody has to use it, period, just ignores human psychology. People, people are terrified and they're going to act terrified and they need to understand that they're safe, which requires first that they actually be safe. and then have that communicated to them and then if all of that's true there's still going to be a curve there will be people who just want the new shiny and that's cool and the tribe needs those people because we got to find new sets of resources and then there'll be people who look at the new shiny and go uh-huh uh
1:05:00 Scott If I use this thing, I could gain this leverage and accomplish, there's a deer right outside my door. This is life in the country. Yeah, get out of here. Oh, just chewing up the landscaping. The second group of people will say, OK, I have I have goals outside of this technology that could be achieved with this technology. And then they'll do that and then they'll tell their friends with similar kind of motivations. And then comes the chasm and then there's this early majority who who want to they want to do things better.
1:05:45 Scott But they're quite afraid. And so the message to each of these groups is quite different. And this model, the crossing the chasm model actually originally came out of the adoption of hybrid seeds in
1:06:04 Kent Hmm.
1:06:04 Scott the 40s where There were corn farmers, these hybrid seeds came out, they're definitely more productive, and yet they took 10, 15 years to be adopted widely. And it went through these very predictable stages. There were farmers who just loved trying the new thing, and then there were farmers who wanted to try the new thing. to increase profitability and then there was this early majority who they didn't want to be behind and then they're late majority who doesn't mind being behind but if everybody else is doing I'll do it too that that dynamic is is going to exist in any kind of adoption and so you need to move through the stages you can't jump
1:06:57 Scott So be aware, find your pioneers, your whatever you want to the innovators, find those innovators, give them a lot of support, find the people who want to solve business problems with the technology, they don't just care about the technology. Once the innovators have done their thing. and then make it safe for that early majority. Like that's the bulk of the transition to
1:07:26 Kent Yep,
1:07:27 Scott do that. But recognize that you got to go through these phases and you can't jump right to it. My heart goes out to executives now because their boards are saying, no, everybody has to use it right now and we have to fire half of everybody. Like it's an impossible set of constraints that is, as we would say in engineering and... An over-constrained situation. There's no solution. If everybody has to use it and we're going to fire half of everybody and people aren't going to use it if they feel unsafe and firing
1:07:57 Kent Yeah.
1:07:57 Scott half of everybody makes them feel unsafe, like catch
1:08:02 Kent Yeah.
1:08:02 Scott 22. There's no way out of this.
1:08:05 Kent Yeah.
1:08:06 Scott But this is such an own goal. It does not have to be this way.
1:08:11 Kent I love it. I mean, I don't love that challenge, but I love that we got. We got you here and you've given us some wisdom. And I think I love that you've kind of summarized it as this has this is we've been here before. This is the way innovation happens, whether it's hybridized seeds or whether it's the genie in the bottle of augmented development. And we're going to have to go through that process. And it's not something that we can rush and it takes trust. And it takes real usefulness. And if people really use it and they trust that it's useful to them and they trust that it isn't going to harm them, then they'll adopt it eventually.
1:08:54 Scott Yeah.
1:08:55 Kent I love it.
1:08:57 Scott Well, Kent, thank you so much for taking some time out of your day. Scott, Brad, absolutely my pleasure.
1:09:02 Kent Yeah,
1:09:02 Scott Now
1:09:02 Kent it was great
1:09:03 Scott go get
1:09:03 Kent chatting with you.
1:09:04 Scott that deer now. All right. I'll chase it off. No problem.
1:09:08 Kent What do we say, Scott? We say smash that subscribe button, rate, review, tell your mom, and we'll see you next week, Brad. See you next week.
1:09:17 Scott All right.
1:09:18 Kent Thanks again, Kent. Bye-bye. This episode of the How Many CTOs Does It Take podcast was produced and edited by Safran Heptacow. Our theme song was AI generated by Brad. Please follow us on all the social media platforms at HowManyCTOsPod. You can find us on YouTube, LinkedIn, Instagram. I am Facebook Reds X, TikTok, and Patreon, or at our website at HowManyCto'sPod.com. And remember to rate, review, and subscribe on the podcast platform of your choice. Thanks for listening.
