Architecture, AI agents, and product empathy with Robert C. Martin Transcript, AI Summary & Key Points

00:01 Hello everybody. It's your friend Kent C Dods here and I'm here with um our uncle Bob. How are you doing, Robert? >> I am well, thank you. >> Just I'm thrilled to have you on here. Um so um I actually when I was just getting into software development, the first um book that anybody recommended was Clean Code. I'm sure you hear that a lot. Um but uh yeah that was the first programming book that I ever read aside from a textbook or something but uh yeah so um been um an admirer of yours for many many years and I'm just

00:35 thrilled that you're uh joining us for this podcast. >> It's good to be here. >> Well um great. So for for those of uh who don't know um that you're like one of the original authors and signers of the agile manifesto and behind solid principles of course clean code and everything there's so many things um but uh for the context of our conversation uh why don't you give us a little bit of your background and history uh and uh so that we all understand where you come from in the realm of software >> heavens I've been a a

01:07 programmer since I was 12 years old and that was in 1964. >> Wow. Wow. My mother bought me a little plastic computer and you programmed it by slipping little plastic tubes onto pegs and then you would cycle a machine. In in essence it was a a threebit uh six andgate finite state machine. But it was magic as far as I was concerned and that was the moment I became a programmer and kind of del dove into the whole thing.

01:34 I learned you know assembly language on PDP8s. I learned forrren and cobalt without a machine to ever use. Right. Just reading the book and writing the programs I could not execute them. >> Wow. >> And eventually became, you know, a professional programmer over the years. [laughter] I've I've worked on just about every kind of system there is to work on.

01:56 But you know really early stuff assembly language, machine language, lots of hexadesimal and binary and eventually got into higher level languages like C and C++ and eventually Java and nowadays if I write code at all I write it in closure although I'm not writing a lot of code nowadays since the agent that for me. Yeah, I actually um often you'll hear people say if you want job security, go learn um cobalt and then go work at a at a a bank or something.

02:31 And I was thinking about that and I thought, you know, I I'll bet you the AI a coding agents could write Cobalt pretty well. You could probably do okay. >> If Y2K were happening today, there would be no Cobalt uh consultants getting hired. be able to take care of that problem very easily. >> That is remarkable. Now all of us listening know like yes of course AI agents have just taken the world by storm.

03:00 There are probably some people listening who are sick of hearing that but the the fact remains that uh our our software industry has changed considerably in just the last five years. Um, >> I'm curious though since you have so much experience developing software over the years. Um, and not not just like the low-level, okay, I'm doing machine code zeros and ones and then assembly, but like architecturally and building systems.

03:24 I'm curious what in your experience has drastically changed and then more importantly for us in our conversation, what has stayed the same and what do you expect will continue to to stay the same over the years? So uh from a design and architecture level nothing has changed and nothing has changed in 40 or 50 years. Um software is one of these very interesting disciplines where things at the bottom change really fast.

03:51 the languages and the machines and and you know disciplines and people talking about oh you do this and then frameworks and all that and then you get above a certain level and you're into the high high level design and architecture realm and all those rules have been exactly the same for for 40 50 60 years right we want to break things up into modules we want to control the dependencies between those modules we want to encapsulate information all those rules are the same so um I wrote a book a while ago clean

04:23 architecture and in that book that was the essential point the first point I made right is that in the years that I have been doing this the thing that has remained constant regardless of platform environment language regardless of anything else the rules of software design and architecture have remained perfectly constant and they still do. That is so interesting to me because I and I agree with you.

04:54 I this is one of the reasons why I'm I'm doing this podcast and and I pivoted over to epic product.engineer uh now as well is that I feel like the um the principles of software development uh that were valuable 50 years ago will continue to be valuable. And in fact, uh, I wrote a blog post titled The Last Software Engineer, which a lot of people took issue with as like could there possibly ever be one?

05:18 But it's more of a metaphor of thinking if that were the case, what is the last useful thing that the last software engineer could do that would still be a useful uh, uniquely human thing. And my my decision around that was the systems design and architecture. Um, and so that's why I feel like that's the most durable skill. Does that resonate with you?

05:40 I see you nodding. Yeah, it certainly does. I mean, the the history of our industry has been this this rising tide. Uh, and above the tide, everything stays the same. Below the tide, everything changes. So, at first it was, you know, we were all programming in binary, literally, right? I mean, people literally started programming by punching holes in paper tape, manually.

06:03 Punching holes in paper tape. And then eventually, oh, well, we don't have to do that anymore. Now, we can just type numbers at the keyboard. and oh now we don't have to do that we could actually type pneummonic instructions and then oh maybe we could write in forran or c. So there's this level that has been rising and it it's just the level of ugly horrible stuff that people have to do to get these computers to work and and we've been rising above that.

06:31 We've been getting that level higher and higher. So nowadays we don't even have to worry about syntax. >> That is now gone. We don't have to think about syntax anymore. But there's still plenty of stuff above that line. [laughter] >> You know, this is really interesting because I I've talked to several guests who have said, "No, I'm I'm very much looking at the code all of the time."

06:55 And um I I will often uh say like if you're working on like a medical device of some kind or something yet like I really hope that you're still very much in the code. Um but I'm I'm curious how long that will remain true and and curious about your perspective on that. If I uh may just the way that I think that things are going to go eventually is that we we won't necessarily be reviewing the code and instead we'll be reviewing the system and there will be some mechanism by which um we we kind of view the system we tell

07:27 an a coding agent how we want that system changed or how we want um to implement something within the context of that system the primitives available and then what we're reviewing is not necessarily the code but the change in the system And we just need to come up with a good representation for that system whether that be diagrams or whatever. But um that's kind of what my view of the future will be is much less looking at the actual code implementation of the system and more the system itself.

07:54 What do you think about that and what where do you think things are going to go? >> If we are going to get the benefit from these agents, we are going to have to walk away from the code. There's there's no there's no other way around it. Code is the slow part for humans. Humans working in code is slow. Now, by the way, this is not anything unusual, right?

08:16 We had to walk away from the binary and then we had to walk away from the assembly language, right? We've we've always had to walk away from the lowest level details and happily we walk away from those things. And now we're going to walk away from the code. What I do now is I I very purposely do not look at the code. as tempting as it is, you know, because you know, I really like to code, but as tempting as it is, I purposely avoid looking at it until the job is done.

08:46 Then I might do a few spot checks, but I'm not really that interested in the code anymore. I'm still very interested in module structure. So, I look at the module structure. I will I will have my agents develop tools that will show me the module structure on the screen that will allow me to drill down. you know, I can click on a module and see those subm modules below it and click on those and see them the code below that.

09:11 Um, all of those are interesting things to do. The agents are masters at allowing you to interrogate the structure of the system. You can compose really interesting questions about the the dependency between the modules and how the modules are allocated and how the data flows between those modules. You can pose those questions to the agents and the agents will come back to you with a very nice report of how this all works and what the dependencies are and then you can point at something in the middle of that, you know,

09:46 with your keyboard. You can say, "Oh, I don't like that third data flow you just showed me. You've got to fix that." And then the agent will see, "Oh, of course you're right." And then it will go in and it will fix it. So there's this um this lovely ability now to see into the code without looking at the code, getting the agents to look in for you and come back with uh a a short summary of of what's going on so that you can make adjustments.

10:14 And it's just wonderful. >> Oh, I I completely agree and uh um I I love this take. uh this is exactly how I've been operating but the one of the uh things that I'm concerned about is most of the code that I've been writing recently has um one user it's just me or or uh I do have uh projects that I like I sell and there are people who use them um and not not a few but but still I'm not working at a big scale I'm not building uh medical devices or airplane you know software or whatever my systems are considerably smaller

10:53 smaller than many systems uh that I've worked on in the past and many others. So I wonder if this is uh if my workflow is just a a result of my size of my system. Um what are the types of systems that you're working on and are you finding this approach apply like will apply well to um bigger and more important systems? >> I'm very much in the same boat you are.

11:17 You know I'm doing little tools, little things, little fun little little side projects. I've got one project for a nearby flight school. I help them maintain a a status board, things like that. Um, so I'm not I'm not in the realm of huge systems anymore. On the other hand, even when I was in the realm of huge systems, the rules haven't changed. A a huge system is a bunch of little systems all tied together.

11:44 And the rules for tying those little systems into a big system are still the same. and they are outside of the realm of the agents. The agents can't do that stuff. You can't tell the agent to to make you a massive air airport control system. They're not going to do that. You would have to build all the individual modules. You would have to tie them all together.

12:09 So the systems engineering is still completely human with with the exception that you can start to ask the agents about the system structure. You can talk to them about brainstorming. You can pose certain models and have them run simulations. Those are very interesting things that you can do with the agents that we never had the the power to do before.

12:33 You know, I I used to have to write special code to simulate a system before I would commit to a system design. Now I can get the agents to do that for me and I can explore all kinds of whatif options because for the agent it's a trivial task whereas for me it would have been three or four days worth of work. So I I don't I'm not too worried about the highlevel system stuff.

12:57 I think if we can manage the agents at the local module level, the the single executable or the or the very simple low-level system level, then the big systems will take care of themselves because that's a solved problem. We've been dealing with that now for decades. >> Yeah. you know the uh uh in times past you would have uh you know the technical fellow or or the the person kind of higher at the top who is orchestrating all of the work of these various teams to put together a large system a large product and that

13:34 individual very rarely looked into the code and so it's it's like the the implementers underneath that person have just turned into uh AI agents and um and the benefit of course being that um anytime the systems designer needed to understand something, they'd either have to look into the code themselves manually or they'd have to wait for the implementer to wake up to explain what's going on.

13:57 And now we don't really have to do that anymore. Um I am curious though uh that person um probably worked hard to create a system in which the u people actually doing the implementation uh would be successful and proactive and all of that. Um, and a lot of that, uh, in your history came from clean code and just telling, hey everybody, you've got to be reading this and applying these principles.

14:25 Um, and since you are rarely looking at the code, um, I I kind of have two questions. First, how much do you care about clean code in that context? Um, like the specific insulated like are these all black boxes and you're okay with what however it looks inside as long as the boundaries are okay. uh or like are are you um executing specific strategies to make sure that the agents are following um proper you know clean code principles?

14:54 >> Well, certainly the latter. So, so yes, I'm definitely still concerned about the cleanliness of the code that has shifted a little bit. Cleanliness in uh cleanliness for humans is a little bit different from cleanliness for agents. So for example, when I when I'm writing code for humans, when I'm writing code for myself, I try to limit the cyclomatic complexity of a function to four.

15:22 And if you read the clean code book, I don't put it in those terms. I just say, you know, keep your functions really short. Uh but that's that's what I'm after. I want the these really tight little functions. For agents, I let that go to maybe six. The agents seem perfectly capable of of internalizing a relatively not a very complex function, but a relatively complex function, right?

15:46 They can deal with a couple of indents. So, I relax that rule a little. Um, comments. I I made a big deal about comments in the clean code book, mostly because people write stupid comments and then nobody wants to ever read them anyway, and they turn them into gray on their screen. uh the agents read the comments they write and they maintain them. If the comments's wrong, they will fix the comments.

16:12 So, so the comments take on a different kind of purpose. The agents actually use the comments for what comments should be used for. So, I allow them to write whatever comments they want. I don't put any restrictions on them at all. I am not interested in the syntax of the code, but I am very interested in the functions. I want to know what the function structure is.

16:39 I want to know what the names of the functions are. I want to know to some extent how many arguments they're passing. I don't want to see, you know, 50 arguments in a function. I' I'd be, you know, I used to say it three. That was my limit when it was humans writing the code. Uh with agents, I'll give them a little more leeway. uh but I'm still looking at that level.

17:00 I'm looking at function structure, module structure, names of functions, sizes of functions. You know, I will do spot checks on the code where I'll I'll scroll it past my screen. I'll just go scroll scroll scroll. And as I'm doing that, I'm just looking at the function names and the sizes of the functions and just making sure that they're not doing something outlandishly stupid.

17:24 And usually they don't. Now I I constrain that with a lot of tools. So the agents must run tools that measure these things and then they must correct them. And one of the tools I run is a cyclomatic complexity checker. It it's actually a more little more uh interesting. It's called crap which which stands for um geez. Let's see if I remember that. Um um something about um antiatterns.

17:55 I can't Oh, crisp critical risk antiatterns or some some dumb name like that. This is a tool that was invented in right around the turn of the millennium, right around 2000, 2005, something like that. And what it does is it mixes test coverage with cyclatic complexity. If you have a module that is tightly covered, then uh the the the metric will simply return the cyclatic complexity.

18:25 On the other hand, if you have a module that is not well covered, then the cyclatic complexity gets cubed or squared or some they've got some formula and and it just drives the the uh the crap number very high. So what I'll have is the agents will run crap over the over the system that will enumerate all the functions and it'll give them scores and then I tell them reduce these all below six and that they sit there and they'll work and they say oh well I've got to get it below six.

18:56 Why is it so high? Well it's cuz it's not covered. Well then I need to write tests to cover it. Oh now it's covered but it's still 12. Oh I need to split it apart. And it's just fun to watch the agents do this, right? They're doing all these things that I would have done, but they're doing it at much faster speed. And then in the end, the end I've got this nice module with nice tight little functions, nicely named, really covered with tests.

19:23 It's it's great. And that's just one of the tools I use. >> Yeah, I think the uh these tools like this is what we call closing the agent loop, right? just let the agent know what it needs to do and and how to check its work and and uh the these are really valuable tools. But I I wonder um aside from the tools um how how much of the um the way that you use agents today do you expect um to continue?

19:49 And um like do you see those particular uh approaches being uh a durable thing that u you can continue to do or do you see agents uh continuing to evolve to the point where you don't need to worry about that side so much and you can focus on other things? >> I haven't seen any indication that the agents are getting any sense of goodness at all. it it um and and it's hard for me to come up with the word.

20:23 Michael Feathers used to use the word design sense. It's some kind of innate thing in a human where a human will look at a design and go something wrong with that. Um I I don't see that happening with the agents. You can you can ask an agent to critique something and it will come back with a very cogent critique. It'll say, "Oh, well, it's got this weakness and it's got this strength."

20:43 I have never seen an agent apply that kind of judgment when they're writing code. >> It's like they completely ignore that. They they've apparently got the discernment power, but they don't use it. And I I believe that's because they're completely uh unself. They have no they have no concern for the future. They don't have a future uh from their point of view, right?

21:11 Their minds do not look into the future and say, "Oh, I'm going to have to deal with this later. They're not worried about consequences. When you give them a task, they focus deep and everything else is outside of their of their mind." And so I'm I I haven't seen them adopt that kind of critical critical nature on their own product. Now, will they? Well, maybe.

21:34 I don't know. We'd we'd have to um see that happen. But there's another another issue with the agents, which is that they've got this um really weird short-term memory problem. The context window fills up and then they just start to lose their minds and they'll hallucinate and they'll go off into crazy crazy directions. So, so you have to you have to just sit and watch them all the time and make sure they're not going off into La La Land somewhere.

22:07 So maybe maybe you know in another two or three or four years these problems will get better but so far they haven't. >> Yeah. Yeah. I you mentioned design sense and I'd like to dive into that a little bit. Um because I do feel like I and I agree with you that this is kind of a uniquely human thing even as you were describing just like scrolling past all of the code like I do the same thing and and you can just you you see the shape of the code and you know right >> so this is why you know people who young people who

22:41 are getting into the field should spend their first three years writing code. They shouldn't agents at all. agents are power tools and young people with power tools tend to lose fingers. >> We I'd like to chat with I'll I'll make a note of that. I want to talk about that. Loop back on that one. But um uh with design sense, I want to know um if if there is a way for a human to develop that better in themselves.

23:08 So like this is a uniquely human thing, but how can you develop a better design sense? What what actions can a person take to be better at this? >> Yeah. Work at it for 20 30 years and make a lot of mistakes. >> Yeah, >> that's kind of the way you do it. I mean, you can you can work under people who have worked for 20 or 30 years. And then they can tell you, you know, when I tried this when I was your age, son.

23:34 [laughter] That's that's kind of the way it has to be done, right? That there you can write books about this. I've written books about it. Lots of people have written books and articles. But to really internalize it, you have to you have to experience the cost. >> That is and that's a that's a really it's an unsatisfactory answer. The truth sometimes is.

23:58 Um but uh but I I would say that um there are some activities that you can do like over the course of 25 years if if you're just um doing the same uh who is it Scott Hansselman um has I don't know if he's quoting somebody but he told me that uh have you had 25 years of experience or have you had one year of experience 25 times um and so there are certainly certain activities that you can do that can increase um the impact of that experience that you're having.

24:30 Is there any specific thing that you could recommend? >> No one in software has had the same 25 years of experience. >> That's fair. That's fair. >> The domain has just changed way too much. So, what can you do? Yeah, you can read. Um you can um study. You can talk to people who have been around the block a few times. uh you can uh make sure you never adopt the attitude that everything is new now and everything that was before is irrelevant.

25:00 Don't adopt that attitude or else you'll just have to relive all the old mistakes. And then the other thing you can do and and I think you're doing this as well is play. Get that machine, put your hands on that machine and just play. Play. Make it do X. Make it do Y. It doesn't even matter what they are, right? Dumb some dumb tool, some dumb game, doesn't matter.

25:25 You know, invent a Star Trek game. Who cares? Nobody's ever going to see it. Just you. And let yourself make mistakes. Try things. Do all, you know, this is the sculptor, right? Who's sculpting with clay and then he goes, "Oh, that didn't work." And then try that didn't work. That's the kind of stuff you have to do if you want to develop this design sense, right?

25:47 as well as, you know, talking with everybody else and reading and studying, but the real benefit comes when your hands are on the >> Yeah, I I think that it it uh we this comes up again and again on the podcast. It's curiosity and trying new things and uh having new experiences. Uh like doing the same regular thing over and over is not going to get you there.

26:13 >> Uh okay, so let's get back to the new software engineers using agents. Um Yeah. >> So, I I've got what is probably a bad analogy for this. Um, and so you can tell me why this analogy is bad, but um I wasn't there when syntax highlighting became a thing for software developers. But I imagine that uh when when it did, the new software developers in in the world would like this is just the way things are.

26:41 I'm going to develop software the way everybody else is. And there were probably some uh software engineers at that time who maybe they were resistant to syntax highlighting and they were just telling the new ones that don't use it. It's a crutch like it's a it's a useless well it's not useless but like you should really understand the code first before you use this crutch.

27:00 So what is wrong with my analogy there? >> Um so what's wrong with the analogy? Um, let me put this into different words. The the analogy I would make, not the syntax highlighting. Syntax highlighting is just useful and it it unbburdens you of an obvious chore. the um and and and the the loss of your uh loss. It's not really a loss, but the fact that you are no longer going to do that chore anymore has no effect on your ability to assess the quality of the product.

27:46 Right? The fact that that you know you you half type a a word and it just finishes it for you. a little IntelliSense or or the fact that you don't have to un you don't have to put m underscore in front of your member names anymore because because the tool is now putting it in a different color that has no impact at all on the actual quality of the structure, right?

28:09 But not knowing the code definitely does. If you can't do the little trick that you you and I were talking about where you're scrolling by the screen and looking at the structure of the functions, if you can't do that, well then you've got then you've lost something. You've lost some kind of sense of the structure of the code. We have been doing this kind of stuff for a very long time.

28:32 There's always this fear, right? like, oh gosh, if we're all going to be using C, then we're going to lose the we're going to lose the innate detail of the the assembly language and the machines and the the new programmers coming out, they'll never know what these machines really are. And there's a certain amount of truth to that. Although, if you're a C programmer, uh you're not going to lose the the quality of the product by just looking at C and forgetting about assembly language.

29:02 There is a certain amount of wisdom involved with a programmer investigating assembly language for a weekend to convince themselves that they never want to code in that anymore. Uh and so that they can understand what these machines really are. But beyond that, no, I' i'd say that the novice should not start in assembly language. In fact, assembly language is probably a better thing for someone after they've been programming for two years.

29:32 then go down there and look, oh my god, that's where this came from. I'm going back. That's that's the kind of thing um in with agents. If novices begin with agents and they never look at the code, then they're losing something that I don't think they can get back, >> right? And it's something to do with the in underlying quality of the system. It may be that one day the agents are so good and they have they have uh adopted this ability to self-critique.

30:11 That may happen. At which point we can say, "Yep, nobody has to look at the code anymore." Mm- We can just all use agents and they still have to obey all the rules of system engineering. All that stuff above the water line, they still have to get right. But the the water might get above the code level at some point. right now. I'd say it's like about here.

30:31 [laughter] >> Yeah. >> Okay. That I I that tracks that that makes sense. And and uh I I'll stop using that analogy now or or at least I'll caveat it. Um I think that that does make sense though it does make me wonder if we're saying okay new software engineers uh you need to be really deep in the code. I I think you're not quite saying don't use agents because if we say don't use agents at all then that means for like the first three years while they're just getting really good at the code it will be impossible to get

31:07 a job impossible to compete. >> It's going to be a real real interesting issue. No, I think this should all be done in school >> right and but go off on a side note here. I have found almost no use for computer science courses in university, right? Typically, people come out of school and they really don't know what the hell you like, what are the professors teaching them and then I realize that the well the professors themselves never really wrote code in anger, so they really weren't teaching them anything very

31:38 important. I I've had a number of severe disappointments along those lines. It seems to me, however, that here's a here is a place for the schools to come along and say, "All right, computer science, this is where you're going to wind up. You're going to wind up with these power tools." And these power tools are great and they're dangerous, and you can use them for little games.

32:00 We don't care if you're doing that, but in in our coursework, you are going to write code and you're going to understand what these agents are manipulating so that by the time you're using them in in real anger on real projects, you know what's going on behind the scenes. I think that's a a good place for the schools to adopt. I don't know that they will.

32:25 I I haven't had a a lot of great experience with universities, but maybe they will. I think that would be a good place for them. If not them, then I think that would be a good way for apprenticeship programs to work. >> Yeah. I actually earlier this year released a um foundational uh course uh series that is just about programming. Here's what a variable is.

32:45 here's a function and and kind of the idea is just like I you are not going to be writing these by hand and uh once you're in the industry but it is useful for you to understand these concepts so that you can build on top of that so I I agree with you and I also agree that there uh I don't know what the ceiling is and we as far as how good these agents will get and so uh even if uh I had Grady Buch on a couple weeks ago and and he said like LLMs are a dead end and we've got to go to something else which is whole

33:19 interesting conversation uh in itself but even if there is a ceiling with LLMs that what's to say we don't find a different route and take that route I I fully expect something like that to happen um but at at the current time I think it does make a lot of sense for a new programmer to really understand the code but then at the same time I if I were advising a new programmer I would recommend them learning as quickly as possible how to understand the the existing system and how to uh find ways to implement features

33:52 within that system or determine when a system needs to be expanded to accommodate new features. I think that is a really valuable skill that engineers need now. Okay. And and actually another thing you mentioned also uh with C programmers uh saying oh we're going to miss out on uh assembly and I I did write assembly actually in in school and uh we did I I wrote a zeros a machine uh program a machine code program that like would take input and then print what you typed.

34:23 That's all it took. It worked. >> Yeah. But uh but the the key here I think is that whatever level of abstraction you're working on, I think you need to understand a layer below and a layer above at least. Um that sounds like that resonates. I I feel like I've heard you say that before. >> I don't know that I've said it exactly that way, but but you do definitely need to know um the material that you're working with, right?

34:50 And if you're going to be dealing with agents, you need to know the material they're working. >> Yeah. Yeah. That that sounds pretty solid. Um, let's I I I had one other question that I wanted to ask you about with uh regards to specifically product engineering and like what what does it mean to engineer a product? Um, a lot of times when we're uh when people think about product engineering, they're thinking, oh, well, that's like just the the overlap with a product manager.

35:17 But I think that there's a a very distinct line between what is a product engineer and what what makes a product manager. Where is that line for you? >> Oh, heavens, product engineer. Um, so let me put it this way. I I worked for a guy 40 years ago and I was we were writing code that um controlled little mini computers that tested telephone lights, right?

35:51 And and you know, I was a coder and I I could control these machines and I could make them dial up a phone line and I they could run the little unit that would test the phone line and I could write the code that would do the numerical analysis and it was a beautiful geeky thing to do and all this interesting math all in assembly language and all this control stuff and you know multiple threads going through.

36:15 It was just wonderful. And my boss said, "Have you ever been in the truck with a a phone repair man?" And I said, "Well, no." And he said, "You're going." And this was a fundamental policy at this company. If you were going to be writing code on this product, you would at some point in your in the first year or two of your career, you would go out and you would spend a day with the customer.

36:42 And I'll tell you, you come back with a completely different perspective on things when when when you're riding in the truck with, you know, Jacob Smallley and he's climbing the pole and he's up there, you know, messing with the wires and he comes back back down off the pole and he tells you this story, you come back with a completely different perspective.

37:06 Um, I don't know if that's where you were going with this, but from my point of view, a product engineer lives half in the technology and half in the customer's house, >> and and knows the customer's children and knows the customer's grandmother and, you know, and knows the plumbing problems that the customer have. there's this um deeply human side to product engineering whereas on the other side it's deeply technical and a good product engineer marries the two of those so that there's a a constant now I'm getting

37:43 getting geeky here there's a constant communication flow between the two but that's that's how I would phrase that >> yeah that makes a lot of sense and I I think that part of the reason that I landed on product engineering is being the durable skills because of that human side. Um, but I do agree that there is a marriage between that technical and that human side that that needs to happen.

38:06 That's not going to happen just by the product manager. Um, that said, I do think that um the days of a coder just taking a ticket and turning it into implementation and just just doing that handoff that that that's over. We're we're done with that. And so there is I I think that all software engineers need to kind of edge their way a little closer to that product engineer line so that they can u and frankly I think that the hallmark of some of the greatest uh software engineers who who built the greatest solutions um

38:37 was their product sense and their understanding of the customer. >> Absolutely. I mean, and that that's the direction that the agents are pushing us cuz the agents are saying we can do a lot of the geeky stuff, but you've got to do a lot of the human stuff. [laughter] You know, you you can tell like you bring up an app on your phone or you bring up an app on your screen and you can tell the guy who wrote this has no idea what my problems are.

39:02 >> Yeah. >> Right. He's making me do all this stupid stuff. Don't get me started. I just had a episode with my wife trying to use some piece of software and it was just so frustrating. >> Oh man, it was probably medical software going to the hospital. Like that's always the worst. >> It's like Yeah. >> Well, >> yeah, that's a whole often I I'll use software that's like for my kids and I just like, yep, the software engineers who built this do not have kids.

39:31 I know that for a fact. [laughter] Yeah. I uh I think that's that's really valuable um for uh for folks to understand that um understanding the customer is actually it's a distinguishing characteristic that will set you apart from uh software engineers uh in of the past and and uh really even many software engineers are still kind of figuring that out.

39:54 Um, does it make you sad um that you can't just be the geeky in in the weeds technical side of things and just ignore the the product side? Uh, does that >> No, it doesn't make me sad at all because the most rewarding part of being geeky is having somebody appreciate what you just did and they they look at you said, "Oh my god, you just did something that solves my problem in an elegant and useful way."

40:23 and you have been validated. That that validates your geekiness cuz it couldn't happen. It couldn't happen without the geekiness, but it also can't happen without the connection, the human connection. >> Yeah, I I've uh definitely had people approach me with really amazing pro uh solutions that are just so technically awesome and they're just dying for validation.

40:48 And I say, "Thank you for sharing that. If I ever need this, I'll let you know." and and I never do. [laughter] That's the problem. >> Yeah. Well, there you go. >> Yeah. Uh well, hey, Bob, this has just been a pleasure to chat with you. We're reaching the end of our time together, and I wonder if there's anything that we didn't touch on that you were really hoping that we could talk uh talk with or or anything that you wanted to leave our our viewers with before we wrap up.

41:13 >> No, no, it's your show. I mean, I can talk for a million years about a million things. Well, >> then maybe I'll maybe I'll reach out to you again for a future episode. We can talk about a few more of those million things. [laughter] Um, so as as we wrap up, um, I want you to give us a homework assignment. Something like it's easy to just listen to a podcast, but um, to actually have it change you and improve you, you need to take some action.

41:40 So, what is a good action that people could take to improve their design sense? like a book they could read or some some activity they could take with their agent to improve their ability to be great product engineers. >> So, um here's what I'd like you to do. And this should this should be fairly simple. Uh I've got a little tool. It's up on GitHub.

42:01 It's github.com/unclebob swarmforge. S w a r-f. Just go there and look at that. You ought to be able to um if you read the instructions, you ought to be able to bring it down into your machine and execute it. You might have to fill it a little bit, but it's no big deal. Um this is a tool that will allow you to use agents in a coordinated way. You get the agents to talk to each other.

42:26 You can have them, you know, shuttle shuttle information back and forth or give each other tasks. Um you might you might find that useful. And then um when you're done, if you've done that, uh put a little note on the GitHub page like an issue or something like that so that I know that my product engineering is working properly. This is not something I will ever sell.

42:51 It's I it's free, but it's would be good to know that it's addressing some need. So if you find an issue, put it in the issues of the GitHub account and I would appreciate that greatly. >> I love that. Yeah, take a look at Swarm Forge. Uh, sounds like a great piece of homework. Very specific, something somebody can do and could hopefully help people and certainly help you, which would be very good.

43:16 So, uh, thank you so much. What What is the best way for people to keep follow what you're doing, keep up with what you're up to, and and follow up if they've got questions? >> The social network that I use most often is X. Um, used to be Twitter, now it's X. I don't even how you even talk about that anymore, but my handle there is uh Uncle Bob Martin.

43:39 All one word, all lowercase, and that's probably the best way. Very good. All right, thanks everybody for listening and we'll see you all in the next one. Don't forget to like, comment, subscribe, and share. And we'll yeah, see you in the next next episode. Bye everybody.