Kent C. Dodds (00:01.048)
Hello everybody, it's your friend Kent C Dodds here, and I'm here with our Uncle Bob. How are you doing, Robert?

Bob (00:07.774)
I am well, thank you. Life's good.

Kent C. Dodds (00:09.63)
just so I'm thrilled to have you on here. so I actually when I was just getting into software development, the first book that anybody recommended was Clean Code. I'm sure you hear that a lot. but yeah, that was the the first programming book that I ever read. aside from textbook or something, but yeah, so been an admirer of yours for many, many years.

And I'm just thrilled that you're joining us for this podcast.

Bob (00:40.928)
No, it's good to be here.

Kent C. Dodds (00:43.352)
Well, great. So for for those of who don't know that you're like one of the original authors and signers of the Agile Manifesto and behind solid principles and of course clean code and everything. There's so many things. but for the context of our conversation, why don't you give us a little bit of your background and history and so that we all understand where you come from in the realm of software.

Bob (01:07.468)
heavens, I've been a a programmer since I was 12 years old, and that was in 1964. My mother bought me a little plastic computer, and you programmed it by slipping little plastic tubes onto pegs, and then you would cycle the machine. In essence, it was a a three-bit six AND gate finite state machine, but it was magic as far as I was concerned. And that was the moment I became a programmer. I and I kind of dealt.

Kent C. Dodds (01:13.206)
Wow, wow.

Kent C. Dodds (01:34.156)
Wow.

Bob (01:35.852)
dove into the whole thing. I learned you know assembly language on PDP eights. I learned Fortran and COBOL without a machine to ever use, right? Just reading the book and writing the programs. I could not execute them. and eventually became you know a professional programmer over the years. I've I've worked on just about every kind of system there is to work on, but you know, really early stuff assembly language, machine language, lots of hexadecimal and binary and

Kent C. Dodds (01:48.557)
Wow.

Bob (02:04.447)
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 ages are doing that for me.

Kent C. Dodds (02:21.151)
Yeah, I actually often you'll hear people say, If you want job security, go learn cobalt and then go work at a at a bank or something. And I was thinking about that and I thought, you know, I'll I'll bet you the AI aid coding agents could write COBOL pretty well. You could probably do okay.

Bob (02:41.065)
If Y two K were happening today, there would be no COBOL consultants getting hired. The agents should be able to take care of that problem very easily.

Kent C. Dodds (02:47.895)
Hmm. Yeah.

Kent C. Dodds (02:53.003)
That is remarkable. Now, s all of us listening know, like, yes, of course, AI agents have just taken the world by storm. There probably some people listening who are sick of hearing that. But but the the fact remains that our our software industry has changed considerably in just the last five years. I'm curious though, since you have so much experience developing software over the years, and not not just like the low level, okay, I'm doing machine code, zeros and ones and nano assembly, but

Bob (03:10.529)
Yep. True enough.

Kent C. Dodds (03:22.901)
like architecturally and building systems. 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?

Bob (03:38.146)
So from a design and architecture level, nothing has changed. And nothing has changed in forty or fifty years. We software is one of these very interesting disciplines where things at the bottom change really fast. The languages and the machines and and you know disciplines and people talking about 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 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 of that's all those rules are the same. So I wrote a book a a while ago, Clean 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, right?

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.

Kent C. Dodds (04:50.539)
That is so interesting to me and because s I and I agree with you. I th this is one of the reasons why I'm I'm doing this podcast and and I pivoted over to epicproduct.engineer now as well, is that I feel like the the principles of software development that were valuable 50 years ago will continue to be valuable. And in fact, 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?

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, uniquely human thing? And my my decision around that was the systems design and architecture. and so that's why I feel like that's the most durable skill. Does that resonate with you? I see you nodding.

Bob (05:41.462)
Yeah, it certainly does. I mean, the the history of our industry has been this rising tide. and up 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, punching holes in paper tape. And then eventually, well, we don't have to do that anymore. Now we can just type numbers at the keyboard and

now we don't have to do that. We could actually type mnemonic instructions. And then, maybe we could write in Fortran 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. We've been getting that level higher and higher. So nowadays we don't even have to worry about syntax.

Kent C. Dodds (06:39.723)
Bob (06:40.531)
Is now gone. We don't have to think about syntax anymore. But there's still plenty of stuff above that line.

Kent C. Dodds (06:47.745)
You know, th this is really interesting because y 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. And I I will often say, like if you're working on s like a medical device of some kind or something, yeah, like I really hope that you're still very much in the code. but I'm I'm curious how long that will remain true and I and curious about your perspective on that. If I 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 we we kind of view the system, we tell the an a coding agent how we want that system changed or how we want 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 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. what do you think about that? And what where do you think things are gonna go?

Bob (08:00.016)
If we are going to get the benefit from these agents, we are going to have to walk away from the code. 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? We had to walk away from the binary. And then we had to walk away from the assembly language, right? We've always had to walk away from the lowest level details. And happily we walk away from those things.

Kent C. Dodds (08:18.733)
Mm-hmm.

Bob (08:29.279)
And now we're going to walk away from the code. What I do now is I very purposely do not look at the code. As tempting as it is, because you know I really liked code, but as tempting as it is, I purposely avoid looking at it until the job is done, 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 the submodules below it, and click on those and see them the code below that. all of those are interesting things to do. The agents are masters at allowing you to interrogate the structure of the system.

Kent C. Dodds (08:58.261)
Hmm.

Bob (09:24.809)
You can compose really interesting questions about 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, with your keyboard. You can say, I don't like that.

third data flow you just showed me, you've got to fix that. And then the agent will say, of course, you're right. And then it will go in and it will fix it. So there's this 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 a a short summary of a of what's going on so that you can make adjustments. And it's just wonderful.

Kent C. Dodds (10:20.285)
I I completely agree. And I I love this take. this is exactly how I've been operating. But the one of the things that I'm concerned about is most of the code that I've been writing recently has one user. It's just me. Or or I do have projects that I like I sell and there are people who use them, and and not not a few, but but but still

I'm not working at a big scale. I'm not building medical devices or airplane, you know, software or whatever. My systems are considerably smaller than many systems that I've worked on in the past and many others. So I wonder if this is if my workflow is just a result of my size of my system. what are the types of systems that you're working on and are you finding this approach

apply like will apply well to bigger and more important systems.

Bob (11:15.755)
I'm very much in the same boat you are. 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. 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. 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 make you a massive airful 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. 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. 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 what if 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 high level system stuff. 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.

Kent C. Dodds (13:14.965)
Mm.

Yeah, you know, the in times past, you would have 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 individual very rarely looked into the code. And so it's it's like the the implementers underneath that person have just turned into AI agents. And and the benefit, of course, being that

Bob (13:37.057)
Yeah.

Kent C. Dodds (13:47.634)
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. And now we don't really have to do that anymore. I am curious though, that person probably worked hard to create a system in which the people actually doing the implementation would be successful and proactive productive and all of that.

Bob (13:58.327)
Yeah.

Kent C. Dodds (14:16.753)
and a lot of that in your history came from clean code and just telling, hey, everybody, you've got to be reading this and applying these principles. and since you are rarely looking at the code, I I I kind of have two questions. First, how much do you care about clean code in that context? 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? or like

Are are you executing specific strategies to make sure that the agents are following proper, you know, clean code principles?

Bob (14:54.389)
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 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.

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. 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 internalizing a relatively, not a very complex function, but a relatively complex function, right? They can deal with a couple of indents. So I relax that rule a little.

comments. I I've 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. the agents read the comments they write and they maintain them. If the comments are wrong, they will fix the comments. So so the comments take on a different kind of s 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. 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'd I'd be, you know, I used to say it three. That was my limit when it was humans writing the code. with agents, I'll give them a little more leeway. but I'm still looking at that level. 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

Bob (17:10.069)
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. 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 a little more interesting than it's called CRAAP. Which which stands for geez, let's see if I remember that. something about anti-patterns. I can't remember. crisp cr critical risk anti-patterns or some some dumb name like that. This is a tool that was invented in right around the turn of the

Kent C. Dodds (18:02.412)
Ha ha.

Bob (18:06.761)
millennia, right around 2000, 2005, something like that. And what it does is it mixes test coverage with cyclomatic complexity. If you have a module that is tightly covered, then the the the metric will simply return the cyclomatic complexity. On the other hand, if you have a module that is not well covered, then the cyclomatic complexity gets cubed or squared or some s they've got some formula.

And it just drives the 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, well, I've got to get it below six. Why is it so high? Well, it's because it's not covered. Well then I need to write tests to cover it.

now it's covered, but it's still 12. 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 a 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. It's it's great. And that's just one of the tools I use.

Kent C. Dodds (19:27.339)
Yeah, I think the these tools or like this is what we call closing the agent loop, right? You just let the agent know what it needs to do and and how to check its work and and these are really valuable tools. I I wonder, aside from the tools, how how much of the the way that you use agents today do you expect to continue and like do you see those particular

approaches being a a a durable thing that you can continue to do, or do you see agents 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?

Bob (20:09.751)
I haven't seen any indication that the agents are getting any sense of goodness at all. It it and and it's hard for me to come up with the word. 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, Mmm, something wrong with that. 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, well, it's got this weakness and it's got this strength. 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 believe that's because they're completely unself-motivated. They have no, they have no

Kent C. Dodds (20:52.077)
Hmm.

Bob (21:07.883)
Concern for the future. They don't have a future from their point of view, right? Their minds do not look into the future and say, ooh, I'm gonna 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, I don't know. We'd we'd have to see that happen. But there's another another issue with the agents, which is that they've got this 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. So maybe, maybe, you know, in another two or three or four years these problems will get better. So far they haven't.

Kent C. Dodds (22:17.077)
Yeah, yeah. I y you mentioned design sense and I'd like to dive into that a little bit. because I do feel like I 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

Bob (22:36.257)
Yeah. Yeah. Yeah. This is why, you know, people who young people who are getting into the field should spend their first three years writing code. They shouldn't touch agents at all. Agents are power tools and and young people with power tools tend to lose fingers.

Kent C. Dodds (22:53.419)
Hmm mm. We I would 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 with design sense, I want to know if if there is a way for a human to develop that better in themselves. So like it this is a uniquely human thing, but how can you develop a better design sense? What what actions can a a person take to be better at this?

Bob (23:18.785)
Yeah, work at it for twenty, thirty years and make a lot of mistakes. That's kind of the way you do it. I mean, you can you can work under people who have worked for twenty or thirty years and then they can tell you, you know, when I tried this when I was your age, son. That's that's kind of the way it has to be done, right? The y there you you can write books about this. I've written books about it. Lots of people have t written books and articles.

Kent C. Dodds (23:22.507)
Yeah, yeah.

Bob (23:47.009)
But to really internalize it, you have to s you have to experience the cost.

Kent C. Dodds (23:52.942)
Hmm. That is and that's a that's a really it's an unsatisfactory answer, the truth often sometimes is. but but I I would say that there are some activities that you can do, like over the course of 25 years, if if you're just doing the same. who is it? Scott Hanselman has I don't know if he's quoting somebody, but he told me that have you had 25 years of experience or if you had one year of experience 25 times?

Bob (23:58.392)
Yes.

Bob (24:22.591)
It's

Kent C. Dodds (24:22.919)
and so there are certainly certain activities that you can do that can increase the impact of that experience that you're having. is there any specific thing that you could recommend?

Bob (24:34.229)
No one in software has had the same 25 years of experience. The domain has just changed way too much. So what can you do? Yeah, you can read. you can study, you can talk to people who have been around the block a few times, you can make sure you never adopt the attitude that everything is new now and everything that was before is irrelevant.

Kent C. Dodds (24:40.587)
That's fair, that's fair.

Bob (25:02.155)
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 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. Doesn't even matter what they are, right? Dumb, some dumb tool, some dumb game. Doesn't matter. 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, No, that didn't work. And then let me try. that didn't work. That's the kind of stuff you have to do if you want to develop this design sense. As well as you know, talking with everybody else and reading and studying. But the real benefit comes when your hands are on the

Kent C. Dodds (25:58.166)
Yeah, I I think that it it we this comes up again and again on the podcast. It's curiosity and trying new things and having new experiences. like doing the same regular thing over and over is not gonna get you there. okay, so let's get back to the new software engineers using agents. so I I've got what is probably a bad analogy for this. and so you can tell me why this analogy is bad. But

Bob (26:18.667)
Yeah, yeah.

Kent C. Dodds (26:26.693)
I wasn't there when syntax highlighting became a thing for software developers. But I imagine that when when it did, the new software developers in in the world would like, this is just the way things are. I'm gonna develop software the way everybody else is. And there were probably some software engineers at that time who maybe they were resistant to syntax highlighting and they were just telling the new ones, 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. So what is wrong with my analogy there?

Bob (27:04.487)
so what's wrong with the analogy?

Bob (27:13.023)
me put this into different words. The analogy I would make, not the syntax highlighting. Syntax highlighting is just useful. And it unburdens you of an obvious chore. The and and and the the loss of your 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. The fact that that you know you you half-type a word and it just finishes it for you, a little IntelliSense, or or the fact that you don't have to under you don't have to put 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? 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. There's always this fear, right? Like, gosh, if we're all gonna be using C, then we're gonna lose the we're gonna lose the innate detail of.

The assembly language and the machines and 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, you're not going to lose the quality of the product by just looking at C and forgetting about assembly language. 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. and so that they can understand what these machines really are. But beyond that, no, I'd I'd say the the novice should not start an assembly language. In fact, assembly language is probably a better thing for someone after they've been programming for two years. Then go down there and look, my God, that's where this came from. I'm going back. That's that's the kind of thing. in with agents.

Kent C. Dodds (29:37.404)
Yeah.

Bob (29:42.718)
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 it they have adopted this ability to self critique. That may happen.

Kent C. Dodds (29:54.594)
Hmm.

Bob (30:12.755)
At which point we can say, yeah, nobody has to look at the code anymore. Mm-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. Yeah.

Kent C. Dodds (30:32.373)
Ha ha ha.

Kent C. Dodds (30:36.051)
Okay, that I I that tracks. That that makes sense. And and I'll I'll stop using that analogy now. Or or at least I'll caveat it. I think that that does make sense. Though it does make me wonder if we're saying, okay, new software engineers, you need to be really deep in the code. I I think you're not quite saying don't use agents, because i 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.

Bob (30:42.027)
Yeah.

Kent C. Dodds (31:05.649)
it it will be impossible to get a job, impossible to compete. b

Bob (31:09.303)
It's gonna be a real real interesting issue. No, I think this should all be done at school. Right. And but go off on a side note here. I have found almost no use for computer science courses in university. Right. T typically people come out of school and they really don't know what the hell they're doing. It's like, what are the professors teaching them? And then I realized that the well the professors themselves never really wrote code in anger. So they

Kent C. Dodds (31:14.817)
Mm, mm.

Kent C. Dodds (31:29.93)
Yeah.

Bob (31:38.06)
really weren't teaching them anything very important. 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. 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 good place for the schools to adopt. I don't know that they will. I haven't 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 then, then I think that would be a good way for apprenticeship programs to work.

Kent C. Dodds (32:32.545)
Right.

Kent C. Dodds (32:36.471)
Hmm, yeah. I actually earlier this year released a foundational course series that is just about programming. Here's what a variable is, here's a function, and and kind of the idea is just like I you are not going to be writing these by hand in 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

I don't know what the ceiling is and we as far as how good these agents will get. And so even if I had Grady Booch on a couple weeks ago and and he said like the LLMs are a dead end and we've gotta go to something else, which is whole interesting conversation in itself. But even if there is a ceiling with LLMs, the what's to say we don't find a different route and take that route? I I fully expect something like that to happen.

Bob (33:24.043)
Yeah.

Kent C. Dodds (33:31.55)
But 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 f find ways to implement features 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 with C programmers saying, we're gonna miss out on assembly and I I did write assembly actually in in school and we did I I wrote a zeros a machine program, machine code program that like would take input and then print what you typed. That's all it did. It worked. Yeah. But but

Bob (34:15.192)
Yep.

Kent C. Dodds (34:30.827)
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. that sounds like that resonates. I I feel like I've heard you say that before.

Bob (34:43.916)
I I don't know that I've said it exactly that way, but but you do definitely need to know the material that you're working with. Right. And if you're gonna be dealing with agents, you need to know the material they're working with.

Kent C. Dodds (34:57.089)
Yeah, yeah. That that sounds pretty solid. let's I I I had one other question that I wanted to ask you about with regards to specifically product engineering and like what what does it mean to engineer a product? a lot of times when we're when people think about product engineering, they're thinking, well that's like just the the overlap with a product manager. But I think that there's a a a very distinct line between what is a product engineer and what what makes a product manager.

Where is that line for you?

Bob (35:29.438)
heavens. Product engineer. so

Let me put it this way. I I worked for a guy 40 years ago. And I was, we were writing code that controlled little mini computers that tested telephone lines. Right. 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 could 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 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 f 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. And I'll tell you, you come back with a completely different perspective on things. When you're riding in the truck with, you know, Jacob Smalley, 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. I don't know if that's where you are going with this, but from my point of view, a product engineer lives half in the technology and half in the customer's house. You know, and and knows the customer's children and knows the customer's grandmother, and you know, and knows the plumbing problems that the customer has. There's this deeply human side to product engineering.

Kent C. Dodds (37:10.989)
Yeah.

Kent C. Dodds (37:19.105)
Mm mm.

Bob (37:35.019)
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 getting geeky here, but there's a constant communication flow between the two. But that's that's how I would phrase that.

Kent C. Dodds (37:51.936)
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 skill is because of that human side. but I do agree that there's a marriage between that technical and that human side that that needs to happen. That's not going to happen just by the product manager. that said, I do think that the days of a 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 and and frankly, I think that the hallmark of some of the greatest software engineers who who built the greatest solutions was their product sense and their understanding of the customer.

Bob (38:21.511)
Yeah.

Bob (38:40.511)
Absolutely. Absolutely. I mean and that that's the direction that the agents are pushing us. Because 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. You know, you y 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. Right? He's making me do all this stupid stuff.

Kent C. Dodds (39:02.498)
Yeah.

Bob (39:09.099)
Y don't get me started. I just had an episode with my wife trying to use some piece of software and it was just so frustrating.

Kent C. Dodds (39:16.529)
man, it was probably medical software going to the hospital. Like that's always the worst. Yeah. Yeah, that's a whole thing. So 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. I know that for a fact. Yeah. I

Bob (39:22.751)
Yeah, well

Kent C. Dodds (39:37.474)
I think that's that's really valuable for for folks to understand that understanding the customer is actually it's a distinguishing characteristic that will set you apart from software engineers in of the past and and really even many software engineers are still kind of figuring that out. does it make you sad that you can't just be the geeky in in the weeds technical side of things and just ignore the the product side?

does that

Bob (40:06.932)
No, 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 then they look at you and said, my God, you just did something that solves my problem in an elegant and useful way. And you have been validated. That validates your geekiness. Because it couldn't happen, it couldn't happen without the geekiness. But it also can't happen without the connection.

Kent C. Dodds (40:27.394)
Yeah.

Bob (40:36.844)
The human can have.

Kent C. Dodds (40:37.345)
Yeah. Yeah. I I've definitely had people approach me with really amazing pro s solutions that are just so technically awesome and and they're just dying for validation. And I say, Thank you for sharing that. If I ever need this, I'll let you know. And and I never do. That's the problem.

Bob (40:56.834)
Yeah, well there you go.

Kent C. Dodds (40:58.283)
Yeah. 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 talk with or or anything that you wanted to leave our our viewers with before we wrap up.

Bob (41:13.396)
No, no, it's your show. I mean I can talk for a a million years about a million things.

Kent C. Dodds (41:18.839)
Well then maybe I'll maybe I'll reach out to you again for a future episode and we can talk about a a few more of those million things. so as as we wrap up, I want you to give us a homework assignment. Something like it's easy to just listen to a podcast, but to actually have it change you and improve you, you need to take some action. 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.

Bob (41:54.329)
So here's what I'd like you to do. this should this should be fairly simple. I've got a little tool. It's up on GitHub, github.com slash unclebob slash swarmforge, s-ar-r-m-das-f-o-r-g-e. just go there and look at that. you ought to be able to if you read the instructions, you ought to be able to bring it down into your machine and execute it. you might have to fiddle a little bit, but it's no big deal.

This is a tool that will allow you to use agents in a coordinated way. You get the agents to talk to each other. You can have them, you know, shuttle, shuttle information back and forth or give each other tasks. you might you might find that useful. And then when you're done, if you've done that, 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.

It's f 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.

Kent C. Dodds (43:06.081)
I love that. Yeah. Take a look at Swarmforge. 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. So thank you so much. What what is the best way for people to keep follow what what you're doing, keep up with what you're up to and and follow up if they've got questions.

Bob (43:28.374)
the social network that I use most often is X. used to be Twitter, now it's X. I don't know even how you even talk about that anymore. But my handle there is Uncle Bob Martin, all one word, all lowercase. and that's probably the best way.

Kent C. Dodds (43:44.491)
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.