YouTube Deep Summary

Hey everyone, this is Daniel and you're watching a long form conversation with Robert Martin, also known as Uncle Bob. For those of you who don't know him, he's a professional software engineer for more than 50 years. And he's the author of several programming books, including clean code and clean architecture that we also discuss in this conversation. And we cover a lot. We cover the skill and craft of programming and how we can grow that. The productivity of developers, advice for newcomers in the field and stacks of books that angle Bob can recommend. Programming in the age of AI, discussions on various languages including Java, Scola, Closure, C++, and a couple others. Type systems and technical bits and a lot more. I've personally left with a couple of ideas that I've been pondering over the last few days, and I'm probably going to ponder for quite a few more. So, please enjoy a wide-ranging conversation with Uncle Bob Martin. Robert, Uncle Bob, thank you so much for making the time. It's a pleasure. >> It's my pleasure. >> I always enjoy doing these things. >> All right. So, I want to start uh out of all places with closure. >> So, >> what's your relationship to closure and uh how did it change your thinking about code? Okay. Uh, let's see. Where is it? Where is it? Uh, I got a book. Somebody gave me a book years ago. Oh, there it is. >> It's a big bookshelf. if I have for >> so um years ago this like 15 maybe 20 years ago >> somebody said I should read this book and I went on eBay and I got a a fairly rough beat up copy of the thing and it sat on my desk for a couple of years and then I one day I just picked it up and thought you know I should read this book and um I started throwing the pages. I mean, it was it was one of those weird experiences where it sucked me in and I was I was reading code, but it was, you know, scheme. It was list code. I'd always had a kind of negative feeling about lists. People had told me there were too many parentheses. >> So, as I started reading it, it was like, oh, oh, oh, oh, this is really interesting. And I'm throwing the pages over and about um I don't know, it's page 242 or something like that, the book comes to this screeching halt and says, "Okay, now we have to destroy everything we've told you so far." And and they introduced an assignment statement. And I was absolutely floored by this because I' i'd read a whole bunch of code in this book and I had to go back and look at it all to see that there in fact were no assignment statements anywhere in any of that code and I thought >> okay this is different. This is not something I I'm used to. The date the year now is probably I don't know 2006 something like that. >> So I thought okay this is something I have to learn. I finished reading the book, of course. I went on to find uh some lisp engines and I just stumbled upon closure, which was brand new at the time. >> Uh and it was, you know, sits on top of the JVM. So, it gives you all of the JVM libraries and all the power of the JVM, you know, for better or for worse. Uh but you get to write uh in in a very lispy like language. I was also intrigued because the author of Closure was Rich Hickey and I knew Rich Hickey a little bit. I had interacted with him on a number of earlier debates about C++ and object-oriented programming and things like that. And I I had learned to respect his opinion even though we disagreed on several things. >> Okay. >> Uh so I thought, okay, this is a rich hickey creation. I can buy that. It's a lisp. It's on top of the JVM. And I began to write code and I got a number of the early books and I read them books by Stu Halloway and and other folks uh and thought you know what there's something to this language it's it's better than what I have been doing and I had been writing a lot of Java at that point you know my my career spans an immense number of languages from assembly language to C to C++ to Java and a whole bunch of others. >> Yeah. uh and I had been working in Java at the time and and started doing a lot of work in closure and the more work I did the more I liked it. >> Uh so I I have been a closure programmer ever since that that point. Wow. >> I can still dabble in Java. I can still dabble in C. Every once in a while I will write a little C program just to make sure that I can still do it. Every once in a while, I'll write a little assembly language program just to make sure I can still do it. But if I'm writing code, I'm writing code in closure. That's the short version of the story. >> Why closure? Out of all the things that that you've touched, what makes it so special and what makes it your preferred choice? >> There is a relationship between uh the elegance of elegance, wrong word. There's there is a relationship between the expressiveness of a language and the syntax of a language and that relationship is inverse. The more syntax, the less expressivity expressivity. The fewer things you can say. The more syntax and grammar there is, the more constrained you are and it's harder to say the things you need to say. Closure has like all lisps almost no syntax at all and almost no grammar at all. It is an absurdly trivial language which means that you can say an immense amount of things very easily. Now the the uh the other side of that coin is that you can also uh bury yourself very easily. You know the constraints that people put into languages are done for a reason. >> Yep. And so Java is, you know, statically typed language. You can't pass the wrong argument to the wrong, you know, you it tries to protect you. Closure doesn't try to protect you at all. It's just you do whatever the hell you want to do and and you know, if it doesn't work, well, that's on you. >> I've been programming for over 50 years. I'm very comfortable with that. >> You know, I don't need a a language to protect me from myself. I don't need static type checking. I don't need any of that stuff. What I'm after in a language is to be able to say what I want to say in as few tokens as possible with the most expressiveness, the most elegance. And I find that to be uh any kind of lisp, but in particular closure. I I think Hickey did a really spectacular job with just the few little gentle adornments he added on top of closure. uh to make it a little bit different from lisp. So I I happen to like the way closure works. That may just be my own bias because I've been coding now for I don't know 15 years in closure. >> Wow. Uh and uh everybody thinks you're a Java programmer after the after the um the big popular books. Uh but I'm not sure how many people are that. Yeah. Um well I am a Java programmer and I I I can code plenty of Java you know. So, it's the expressiveness of closure that brought that keeps you in. Anything else? uh doesn't >> I wanted to talk about uh static types uh a little bit later but now that you brought brought them up what makes you what makes you uh comfortable with uh writing in a in a weekly typed not weekly a dynamically typed language uh code of any reasonable complexity. I felt that I mean I I write Scola a lot and uh I feel that the Scola type system is um very helpful in specifying what needs to happen when and uh it can I mean brought to its extreme the scholype system being very powerful it can be extremely constrained to the degree that you can't really open up an HTTP server unless you know Kisley's and monads and whatever else Um, right. So, I was wondering how you how you feel and how you think about these uh about these ideas. What makes you now comfortable with a dynamically typed system on code of any non-trivial complexity? >> Well, a lot of this has to do with my background. Um, you know, I've been programming for 50 some odd years. Uh, and I started out as an assembly language programmer, which is not a statically typed, you know, language. It's not a dynamically typed language either. There's no types except for the word. And you have to invent your own types, you know, data structures that that do certain things or represent certain things. And the assembler is not going to check a damn thing. >> Yeah. So, so very early on I learned the discipline of understanding what my types are and how I had to protect them. That was just the normal way of coding. >> I became a C programmer in the 70s, the later 70s. >> Uh, and the same thing happened there. The C was not typed at all. You you could have types, but the compiler didn't check a thing, right? So, you you you could pass anything to any function and blow the stack. And so that same kind of discipline carried forward. Now something weird happened around 1986, right? And this was the the introduction of C++. You know, Jesus Drew Drip publishes a couple of books and one of them looks just like KN&R >> and all the C programmers go, "Oh, this is going to be the new C." And so we all get the book and we're all reading the book and he's introducing this concept of really good good in the in back for those days static typing and there was this great sigh of relief in the industry. Oh thank god thank god now we have a compiler that checks types because if we didn't have that we were all going to have to become Pascal programmers and we didn't want to do that. >> So so we adopted C++ almost on moss. I mean the the C community moved to C++ I'd say like 80% of them and we we adopted the static typing model and for a while that was very comforting but then you see what starts to happen right you got this fairly simple static typing model in C++ and then they want to put in templates generics >> and at first the generics are fine you know little angle brackets who cares and okay yeah that's pretty useful I create a list of integers. I can create a list of doubles, you know. Oh, that's really nice. And then they want to add more to it so that you can do other things, co-variance and contravariance and and then they start to add even more things to it and the generic thing goes crazy. >> Yeah. You can then write entire games just in just in types then, >> right? The generic language becomes touring complete. Okay, bam. You're at that point, the language is dead. Uh, and I left the language screaming in horror. I thought, okay, these guys are way off the rails. I'm not I'm not dealing with C++ anymore. And I I became a Java programmer. Well, then the same thing happens in Java, right? Java's nice type type system, pretty easy. Then they put some generics in. They're simple generics, little angle brackets, no big deal. Okay? And then they start putting in the question marks and the funny little things and the whole thing just goes crazy and it's like, okay, I got to get out of this Java language cuz they're going to take it off the rails, which I believe they have. Java's way the heck out there now. They do some goofball things. They tried to get, you know, closures in there. They tried to get all kinds of gunk in there. And and at some point, you just have to say, "Okay, guys, you go. you run with it, but I've got real work to do. I'm going to work in a language that lets me do real work. And so when I adopted closure, which was like 15 years ago or something like that, the lack of strong typing, the lack of static typing, didn't bother me. It's like, oh, okay, I remember this. I remember what this was like, and I just fell back on my old disciplines, and that was fine. Although there was a new discipline that I had added to that list which was test-driven development. >> Yeah, >> I started becoming a test-driven developer like 25 years ago. Started writing unit tests in earnest, right? You know, disciplined writing of unit tests before I write the code. I followed Kent Beck's rules. >> Mhm. >> And uh once I went back into closure, I didn't abandon that. I just kept on writing unit tests. And those unit tests were a big help for typeecking, right? I could make sure that all of the all of the data structures that I was passing around were the right kinds of data structures and I was very pleased with that. So that's that's where it was maybe 15 years ago. Then in the last five, six yearsish, the closure community introduced a library which they call spec spec alpha I think they call it. uh and it's very tentative and everybody's wondering if it's going to survive in that form or not. Maybe it will, maybe it won't. >> But it's a a very interesting library that allows you to check types dynamically but with an awful lot of discipline. So if I feel the need to to really anchor a type, I can do that. I can write a library. I can make sure that that library is called by my unit tests to make sure that all the types remain remain intact. I can even put the uh the checks in the main loop of the program so that you know maybe every hundred times around the main loop I just throw a a type check for the whole big uh bunch of in-memory data just to see >> if anything's gone wrong. And that's good for, you know, alpha testing and beta testing and before you get into production. Uh once in production, I rip all that stuff out. But that's been great for me. I it's it's better, I think, than static typing because I'm not constrained by anything I don't want to be constrained by. >> But then you get the guarantees. I get all the guarantees I need dynamically but I have unit tests and I if I need to soften a guarantee I can I can say well in this case this type does not need to conform perfectly right but in these cases it must I have all that power uh which is the power that a static typing system cannot give you so I'm I'm very happy with that >> that's very interesting u I mean reading your material I I I would have guessed like 95% you're you're an advocate of full static typing, but now that now that you're describing uh your relationships to uh testing and closure, it feels like you're like 20% of the static typing, but with the 98% of the guarantees of that the stat static typing can give you and uh with the flexibility that allows you to then shape that at will. That's >> I think that's that's a fair way to put that. Yeah, I mean I I've been programming for too long to um to not want the flexibility. >> That's very interesting. >> Rail against the constraints, but I will put my own constraints up. >> Yeah, that's that's so interesting because um uh the way that I that I generally thought about uh about static typing was that they make explicit what otherwise is in your head. So if you don't have like a full static types, you kind of have to know while reading your your program how your data structures need to look like and what is consistent with what so that you can guarantee the correctness of your code. So in other words, if you don't have the types explicitly mentioned by or enforced by something like a type checker or the compiler, you have to kind of hold them in your head. But that I understand now that it's a false dichotomy because you can enforce the types in something like what you're doing but then not be constrained by um the um the rigidity of uh a type checker. Am I getting this right? >> I think you're getting that just right. Yeah. >> Got it. There's a great deal of comfort especially for younger programmers I think uh in having the compiler do all this checking for you right um now I you know I I adopted C++ in the 80s in the late 80s and I felt that comfort I thought oh good thank goodness now we've got static typing I don't have to worry about passing an int where a double is necessary and I can I can actually you know have the compiler check this for me and then as the years went by, my um my enthusiasm for that began to wayne because okay, yes, it does check a few things, but not nearly enough. >> Mhm. >> I mean, we still had, you know, plenty of null pointer exceptions, plenty of segmentation faults, plenty of all of the old horrors that we had with C. The static type checker might have saved a few of a few things, but it didn't stop the neverending patter of bugs. And what I found that did was unit testing that and stop is the wrong word. uh greatly attenuate. If you're writing a stream of unit tests and if you're disciplined about it, you will greatly diminish the number of these kind of weirdo bugs that occur, the segmentation faults and the no pointer exceptions and weirdo gunk that happens. You will get that under control much more quickly. And it was right in that time frame where I was writing a lot of unit tests and I was doing it in Java and I thought, wait a minute, why do I need this static type checking if I'm doing all these unit tests that are checking my types dynamically and I don't run my application until all the unit tests pass. And bit by bit I thought you know I should investigate other languages like Ruby. So, Ruby came along right about that time and I thought this language Ruby, I think I'm going to be a Ruby programmer. And for about two or three years, I didd around with Ruby on Rails and fiddled and I really enjoyed the freedom of the uh the uh the type system because it's dynamically typed. And then then I stumbled onto Closure and that just changed everything, right? that changed everything because it was a functional language and because it was dynamically typed and it was just so damn trivial. The syntax was just so tur and I thought yeah this is where I need to be. >> That's very interesting. Um how would how do you balance this idea of enforcing your discipline with unit tests and with libraries that kind of make sure that your data structures conform to the patterns that you want? How do you balance that with the uh I mean a critic of that would say that there's a lack of productivity because you have to write unit tests over unit tests and have all sorts of libraries to enforce your your stuff especially in critical paths of your code which may lower the the throughput of your thinking. Whereas a a compiler with a uh static type system would naturally enforce that and you would just focus on the business logic and the compiler would enforce um I mean for for example in languages with explicit nulls it would just not compile if you don't check for nulls with any sort of flow typing. How do you how do you balance this out? I learned a very long time ago um that the thing that slows me down the most is debugging. If I, you know, I'm debugging something, it could go on for a minute, it could go on for two weeks. >> Yeah, >> I've had those cases where it's two weeks long. In one case, my the CEO of the company, uh there was a bug. It was just one of those weird bugs and it happened like every other week. uh and it was in the field and there was a customer who was going to cancel and it was just a nasty situation and and the CEO said, "Bob, when that bug occurs, the next time that bug occurs in the field, they're going to call us. You're going to get on a chartered jet. You're going to go out there. You will be there in a couple of hours and you will debug that thing." Fortunately, I found the bug before I had to get on that on that jet. But it was one of those, you know, hair tearing kind of bugs. I learn I learned a long time ago that debugging is the bane of productivity. Anything I can do to stop myself from debugging is going to make me much more productive. >> And static typing did not help me with that. >> That's very interesting. Can you tell me more about that? because I I found I found as a scholar developer that I've I haven't used a debugger in like two years >> because because everything is just out there for me. Uh I mean I happen to to know very well the libraries and tools that I'm using. So I know my stuff. There's nothing that I need to um to concern myself with. Um but I'm curious to hear your take on it. Well, my take comes from the uh the time period where C++ was the statically typed language I was using. And one of the things that I found was that there there is a typing there are typing bugs. >> You write your code and it won't compile. And then you have to debug why it won't compile. >> And sometimes that's easy. Oh, I missed a type here. Sometimes it's not so easy. Sometimes you have to do funny little workarounds or change the types in strange ways or or fiddle around and and I found that I was spending a lot of time debugging the type system because the type system was so constraining and and of course everybody's solution to that is you know well just cast it just do a cast you know cast it from one type to the next or do a dynamic cast or or you know what you could always you could always move it over to a void pointer and then recast it. There's all these >> horrible tricks that you can do that are very tempting >> when you're when you're battling a typing error. >> Now, on the on the one side of the argument, it's well, your code isn't correct, so you've got to correct it and get the typing right. Okay, but that's no different from saying I have to get the program correct when it executes, right? It's still debugging. And anything I can do to shorten that debug time to get rid of the debugging issues will make me go faster. So every unit test I write makes me go faster. Every time I I specify a dynamic type constraint, that makes me go faster because it eliminates another one of those debugging rat holes that I'm going to go down if I don't do that. So that's that's kind of my philosophy. >> Avoid any kind of debugging rat hole. the the way that I mean the reason I'm asking and uh the reason why I'm double clicking on stat static typing for so long is because uh for the longest time I felt that a uh a static type system is uh a great solution to the problem of how do you prove that your code is going to be correct other than just by running it. I feel that uh after so many decades of programming uh we are still not in the place where we can say okay I've wrote I've written a program I want something to tell me if this thing is correct uh without me actually putting this into production or running this um and if it feels like um a moral failure of the the entire field of the industry that in at least in some places the only way that you can prove whether program is correct is to run it and it there has to be a better solution. This is why I'm I'm asking this for I'm I'm uh digging into this subject. >> So you have you have fallen into the Dystra trap. >> Tell me about it and tell everybody about it. >> Huh? I'm sorry. >> Tell everybody about it. >> Oh, so Edgar Dystra, this goes way the heck back in time in the late 1940s, the early 1950s. uh Edgar Dystra young man uh was wanted to be a theoretical physicist but he saw a computer >> and it was a computer that didn't even work but but he really liked the idea and he got hired as a programmer and he helped them um first of all he helped them get the hardware working and then he also started writing code in an extremely primitive machine. >> Mhm. And he encountered all of these debugging issues. He encountered the difficulty of expressing code in these very primitive machines. And he said exactly what you just said. He said what we need is a mathematical structure where you can prove software correct. And he railed against tests. He said tests do not prove software correct. All a test can show you is the existence of bugs. It cannot show you the absence. what we need to do is prove things correct. And he worked on this for a very long time. And I won't bore you with all of the details, but in the end, he completely failed. >> I mean, it's a testament to I mean, the current state of programming uh world is a testament to that. >> Yeah. Well, software, we we want software to be a mathematics. We want software to be provable. That's what we want. You know, we Oh, we we should have a a hierarchy of theorems. That's what Dyster wanted. A hierarchy of thems. And programmers should not be writing code from scratch. They should be taking the theorems that already exist and adding a few little lemas to them like a mathematician would do, right? You take what already exists, the superructure of theorems, and then you add a few little things to prove some little thing down here. That's what Dyster wanted to create. And he he failed at that. He could not create that. He he went through the effort of trying to prove software correct and found that the effort was greater than the effort to write the software and test it. It's an enormous amount of effort. Software in conclusion. My conclusion, this is my conclusion. Software is not a mathematics. It can't be a mathematics, right? It is instead a science. Mathematics is a positive discipline. You prove things correct. Science is a negative discipline. You prove things incorrect. >> Yeah. >> That's what you validate the theories, right? >> That's all you can do in science. Nothing has ever been proven in science >> except what isn't true. >> Yeah. We can prove the things that aren't true, but we cannot prove the things that are. Truth will always be hidden from us in a science, right? We might narrow in on it, >> but we will never get there. That's what's interesting about science. And that's what's interesting about software at at some level. We h we all have to admit that yes, software could be a mathematics. It is a structured logic. You could prove things correct, but from a practical point of view, that's outside of our reach. And we have to treat it like a science. We test it to see if it's correct. We run experiments to see if it's correct. We treat it like a science and respect it in the same way. The respect a scientist has for a theory is skepticism. >> Right. Yeah. >> You don't you never buy a theory, right? It's like okay, you know, F equals MA. Well, yeah, but uh not in every in not in every circumstance. Scientists are always skeptical. Mathematicians are not. >> Mhm. >> Mathematicians prove things. So they know. Scientists never know. And programmers never know. >> Yep. That's what we know. That's what experience teaches us. Um I was curious how you maintain the the discipline that you uh that you were mentioning earlier. You said that you are still writing assembly code and C code just to just to make sure that you that you can still do it. How does that help you with um the discipline that then informs the rest of your code? >> I don't know that it does. Um, it's it's more like I'm trying to come up with a good analogy. Uh, it's more like a a guy who runs a contracting business, right? And he's got a hundred guys working for him and he's he's out there making deals with clients and but he used to swing a hammer. >> He built that business from the ground up, right? And every once in a while that guy who sits in an office somewhere and he's on the phone all the time making deals, every once in a while he picks up a hammer and hammers in a nail just to remind himself of his roots. And I think that's what it is for me. You know, every once in a while I'll just pop open a little little thing. I'll write a little bit of assembly language just to remember the distance that I have traveled because I'll tell you one thing, it's a hell of a distance. >> Yeah. I mean, it's a it's a it's an impressive career by every stretch of the imagination. And uh >> Oh, I'm just talking about the distance of the of of what programming was like in the in the late60s and what you've been part of that you've been part of that journey. >> Yeah. I lived I lived most of that journey like you know I did a fair bit of writing of code in punch cards. >> Yeah. >> And paper tape. uh you know >> do you have any any similar advice for programmers of this day and age to keep well grounded as to keep themselves well grounded as programmers? Do you do you would you suggest a new programmer learn one of the oldish languages or thinking uh just u um keep in their head the fact that they are programmers of machines and not just thinking uh just building uh mental house of houses of cards. Am I making this sense with this question? >> No, you're making that perfectly clear. And and it's one of the things I tell students in virtually every class I teach is that at some point you should break open a little assembly language thing. Find something on the internet that'll let you write some code for a 6502 or an 8080 or something like that. Some old machine that was that was popular back in the 70s or 80s and spend a glorious weekend. You'll have to get rid of all your family cuz it's a very deep dive. uh but spend a glorious weekend just trying to get anything at all done in an assembly language just so that you know what the roots are just so that you understand what these machines are. The machines themselves, although they've gotten much faster and their bit channels are wider, you know, 64-bit machines and and they've got some interesting instructions, they are still van architecture computers. The architecture hasn't changed much. These are still single instruction executing machines that work the same way that those old machines work. And it's important for us to understand that as programmers to know, you know, what the roots of our of our profession are. I wrote this whole book about this. Where's that book? Oh yes, here it is. Yeah, we programmers. I just wrote this couple about a year and a half, two years ago. Uh, and this is the story of Charles Babage, Grace Hopper, Edgar Dystra, um, the guys who made C, Kernan, and Richie and and, uh, Thompson, uh, and a bunch of other people >> and and I go into a very deep technical dive. This is a book written for programmers. So, you want to know what kind of machine those guys were using? I go into, you know, what the instruction sets were and the architectures of the machine and how they had to write the code and what form that code was in. So, this is a very technical book, but it's also a very personal book >> because you get to know these people a little bit and their goals and aspirations and their failings. It's a a fascinating story and this is this is something that I think younger programmers should know. We are in the midst of facing down a an interesting demon and it's the AI demon. Now, there's nothing wrong with that. But AI is great. >> Now that you brought it up, let's let's go. >> Well, AI is great. I love it. I, you know, I've got co-pilot attached to my IDE and it throws up little suggestions to me all the time, most of which I ignore, but some of them are useful, right? So, it's it's a productivity tool. Helps, great. I love it. Um, but there is a risk. The demon here is the is the idea that you will trust it beyond its means. Now, I'm also a pilot, right? I fly I fly a little little airplane around just for fun nowadays. Used to do it for business, now it's just for fun. Uh, and airplanes got a good good autopilot. Real good autopilot, right? So, uh, I don't trust it. You know, I'm watching it like a hawk all the time. I check all the time. Are you right? Are you still in the right mode? Are you still doing the right thing? >> Every once in a while, that autopilot will go off and do something weird. >> Now, that's because I hit the wrong button, but still, I mean, I didn't know I hit the wrong button. I didn't know I didn't set it up correctly. And all of a sudden, the autopilot's taking the plane in the wrong direction. And I'm I'm looking at it going, "Yeah, no, you're not doing this thing right." It's the same attitude I have with an AI, right? I am in control of that AI. You know, I am the programmer. I author this code. The AI can help me. I've got no problem with that. But but I'm going to scrutinize everything it does. >> The demon is the demon of trust. That's where and and I and I see this beginning to creep in especially in younger programmers where they just write a prompt and they trust the code. >> Yeah. They expect the entire app and the to build from scratch. >> Yeah. No, that's that is not going to be the way this works. Even when the AIs are good enough to really write the code well. They're not yet, but they're getting there. They're getting there. Even when they are able to write the code very well, the difficulty will then be in structuring the prompt properly. >> Mhm. >> Which is a way of programming. We programmers are the people who specify the details. Those details have to be specified somehow. And whether they are specified in closure or Java or Scala or a prompt, they still have to be specified with sufficient detail and with sufficient knowledge of the business that an AI could then write the code. Think of every compiler you've ever used as just another kind of AI, right? Because that's what they are, right? This is just a better one. Okay? But somebody still has to specify. And you know who doesn't want to do that is the business. Businesses don't want to get involved with all the little horrible details, right? We do that. We programmers are the detail managers that make sure that every little fiddly detail is just right. There's a little thing behind me. Uh it's on the screen back there. It's a little project that I did for my uh >> uh flight school. I go in there every once in a while. The guy there said, "Hey, um, maybe maybe you could help me write a little thing that would list all the flights that are reserved and and check to see if they're in the air and here's some websites you can pull data from." And so I put that thing together for him. >> Mhm. >> And you know what? It was just a lot of little details. Just a lot of dumb little details. Oh, how big should that field be? And how where should the spaces be? And and you know, what order should they be? and just all this. That's the stuff we excel at. That's what we're good at. Programmers are good at thinking at that level. Not necessarily the level of code, but just the details of getting it all right. And the AIs aren't going to do that very well. We're going to have to be putting that effort into our prompts and we'll probably have to be reviewing code for a very long time. >> Right? I mean in the in the industry a lot of our time is spent reviewing code more than writing like typing the stuff. So u the the ability to read and understand code quickly is going to be an increasingly important skill I feel. Um >> and and in order to do that well you must know the design principles and the coding principles and all the standards and in order to have those into your brain well you better be writing some code too. >> Yep. because otherwise you don't have the good understanding of what that thing is going to do. >> That's right. >> Um I I had a I had a curiosity. Um you said that uh I mean first of all uh I agree with the principle uh that good software is fundamentally good thinking and software is good structured thinking so that you can make the machine do what you wanted with sufficient detail even if the the co-pilot ends up generating at least a bit of the code. I was wondering how you how you can evaluate whether a model or the co-pilot in question has exceeded its means. You said that uh the demon is trusting the LLMs beyond their means. Um I was wondering how how you can tell what those means are and how those means can evolve as the LLMs get better. So when I when I'm using Copilot or something like that, um it will make suggestions. >> Sometimes they're fairly large suggestions. >> Uh I already have an an image in my mind of what that what the solution should be. >> Just that, you know, I say, okay, there ought to be these these structures here and they ought to dangle down like this. And then I let co-pilot do it. And if it comes up with something completely different, then I'm very skeptical. >> Although I have I have had it in in the past where the thing that he came up with different was actually better. But that's a good thing to know. You see, you evaluate it and think, "Oh, yeah, I should have thought of that. That's a good idea." Um, but I always have this expectation. I'm not just going to let it free and then accept whatever it does. >> So, that's the first thing. >> Okay. Secondly, I've got a bunch of smells that I can test for, you know, so if it writes a 50line function, I'm going to be really skeptical, right? Because it should should have broken that down into a bunch of much smaller functions from my point of view. If it throws a switch statement out there, I'm going to be pretty skeptical of that, right? Because couldn't you have used some kind of polymorphism in here? Isn't there some better way to structure that? So I have a bunch of principles that that are in my head that I've written about uh for years. Uh and I can take I can take those principles and apply them to the code that the AI produces. And that's not very hard to do is I'm going to look at it and go okay okay fine you know that that's good that part's bad this I can fix that. So that's how I that's how I approach it. I supervise it. I make sure it matches the principles that I am comfortable with. I make sure that it meets the expectation I had and if it doesn't I'm I analyze it very carefully. Uh and I think that's the best anybody could do and and I do not let it write the tests. I write the tests. That's so interesting because I've seen uh examples of software being written where the programmer I mean even if the AI is being used as a co-pilot not let it spit out everything the programmer writes most of the stuff with some help from the AI and then the prompt is generate tests for that and then 30 tests pop up. >> Yeah, how useless is that? Every bug that's in that code is now going to be replicated in the tests. The whole the whole point of writing tests is double-ended bookkeeping, right? Accountants enter, you know, every every transaction they enter, they enter in two different places so that they can check it. >> There's this great big check that happens on the balance sheet, right? >> When we're writing tests, it's done because we want to make sure that we've said everything twice. If you write code and then have the AI generate tests or if you write tests and have the AI generate code, it is only been written once, right? You haven't said it twice. >> Yeah. >> So when I'm doing this, I write the tests. I don't show the tests to the AI. I have the AI do what I ask it to do and then I will run the tests and that makes sure that the AI did what I needed it to do. I write the tests. It might write some code. >> That's a very interesting take. How do you how do you Okay. Uh I'm thinking of a good way to frame to phrase this question. Um because you call this uh trust this uh borderline blind trust in AI a demon that is more or less going to start swallowing a good chunk of the programming world. Um, I see the uh the big danger of the demon as one the trust being misplaced and two the thinking that comes up with good software, the good structured thinking that led to the good code in the first place becoming atrophied over time because as we rely on AI more and more, we rely on our brains less and less. So the question is how do you envision us programmers keeping this part sharp as AI starts taking more and more responsibility and more and more of the code being written by AI. >> Yeah, I think that's a personal discipline. You know, I like I go back and write some assembly language every once in a while just because >> and I think every programmer should probably be doing that. Everybody should go back and write a little Java, you know, write a little write a little Scola, whatever languages you're comfortable with, just go back and make sure that you still understand how all that stuff works. Even even if you are working with an AI, uh not 80% of the time, you know, 90% of the time, okay, I'm writing prompts and it's great. Uh you should go back and write a little bit of code from time to time just so that you have those principles in your brain. The day will likely come where that won't be necessary, right? where the AIS will be so so good that they will be the new compiler and we will understand the prompt language well enough so that we can write structured prompts well and we know the code that's going to be generated will be correct we're already in that state with Java right nobody looks at the the bite code anymore we're already already in that case with things like go nobody looks at the machine language anymore right you can trust that the compiler is going to generate the right code. >> It's not the way it used to be, by the way. We used to check it like crazy cuz cuz it didn't generate the right code half the time, but nowadays it does. And the same will happen with the AIS, right? Eventually, we will come to trust what the AIs generate if we enter the right kind of prompt language. And the prompt language is probably going to have to be very structured, very much like a what a lawyer uses. Words will have meanings and structures will have meanings and we'll have to come up with a good testing language as well. All right. And all of that's going to have to happen. That's probably decades away yet. >> Do you think so? There there I I I think there are people that that are saying that the data you're describing is either here or very very close like by end of year, end of >> Well, I'll believe that when I see it. How does that day look like? How do you tell whether that day has come? >> Um, here's how I would look at this, right? There will be a there will be a period of crazy enthusiasm, which we're seeing now, right? >> Yeah. >> And ramp up like crazy. And one of the most enthusiastic enthusias most one of the most enthusiastic groups will be the managers who think they don't need programmers anymore. >> Mhm. There are several people that are I mean there are many that already think that programming is becoming extinct for for this reason. >> Yep. So they're going to fail terribly uh because the problem is not programmers. The problem the problem is being able to specify things in enough detail and they're going to need people who can do that and people who do that are programmers. So So that that'll happen. and there'll be this big uh burnout and I don't think it's going to take very long for that to happen and then we will learn that okay we need to figure out how we how we construct this prompting language and there there will be a whole bunch of them people will come up with one scheme or another scheme or another scheme and that will take a while to condense and then at some point we will have one or two or three relatively good prompting languages that are formal and structured that you know you you put everything in the right order and all you choose just the right words and all of that will have to happen and I think that that's going to take some time. So I I I think what's happening right now is that we're in this enthusiasm phase and everybody says it's right around the corner. Don't worry, it's going to happen. It's next week. And I think no, it's probably a decade out. And there's another factor. We are burning gigawatts on this stuff. Probably terowatts on this stuff. And we're still expecting exponential growth. Now you take terowatts and you run them through exponential growth and you got yourself a heck of a problem. >> Yeah, you also need a Dyson sphere today. >> So if there's not a big revolution in efficiency, we're going to hit a plateau. We're going to hit a wall and that wall will be simple power consumption, right? Eventually it just takes too many nuclear power plants to run the AIS. >> Okay. Um so so as I uh if I'm hearing this right uh the day that you're describing sounds like basically a new programming language which bas which is like a glorified English or an unglorified programming language like a mix >> unglorified English I would think. Yeah. Legal ease. >> Legal ease program. Okay. >> Yeah. uh and uh some uh yeah probably the the hardware and the efficiencies and stuff uh may become a solvable problem maybe not but you're say you're saying that this is uh decades away okay that's an interesting take >> well yeah decades now I suppose it could be one decade I' I'd bet more like two but okay >> by the way I was wrong about self-driving cars so I made that same prediction about self-driving cars that that's That's decades away. No, no, it's not. So, take that for what it's worth. >> It's an interesting take now. Nonetheless, I'm curious to hear your take on this. And uh I'm also curious now that that we're speaking about AI. Uh I'm curious how do how you see our responsibility as programmers because as the AIS generate more code that has impact in in the real world who takes the blame if something goes wrong with it >> programmer takes the blame that's not going to change I don't think the humans are always responsible you can't make a machine responsible you can't put a can't put a machine in prison doesn't mean anything to the machine. >> But if the if the a if the AI writes code that we really don't understand um >> I mean >> isn't that true now? I mean you write Scala. Do you understand what's getting generated? >> You have any idea what the bits are doing down at the low level? Yeah, I guess it's a matter of trust all the way down, I guess, because you trust the compiler, you trust the by code generator, you trust the machine that you trust the OS, you trust the Linux kernel or whatever kernel you're running, and then you trust the CPU and then you're trusting all the way down. Okay. Uh so it's is it a fundamental issue of trust no matter how how good the AI is? How do you think about this? Well, it's going to be an issue of trust. We will eventually trust that the AIS take our prompting language and do the right thing with it. Now, that trust is not um unconditional, right? Even today, you know, I'm writing code in Java or I'm writing code in Closure and it's not doing what I expect. uh after enough testing, I'm going to start suspecting that there's something wrong in the closure interpreter or something like that or maybe there's a hardware issue. Right? So those that trust is never perfectly unconditional. But after you've got enough experience, after you've after you've run through uh hundreds of thousands of hours of writing prompts and getting the right result, yeah, you you will have a lot of trust. You'll also understand very deeply what the limitations are, right? So you will understand why you need this structured language and why you need to say things in just the right way and in just the right order. In some sense, we will become machine psychologists. Did you ever did you ever read Iroot? I Isaac Azimoff's lovely book. >> I have it on my Kindle, but I did not get to it. >> So, so the primary characters other than the robots themselves are the psychologists who try to figure out why these machines behave in the strange way they do. And I'll I'll leave the I'll leave it to you to read the book. The book is just fascinating. But the uh the basic idea there is that the humans are still there. The humans still have to monitor these machines. Weird things happen because they are machines and someone has to understand those machines at a very deep level in order to figure out why they're behaving the way they behave. I I expect that the AI revolution will go exactly the way every other revolution in our in our industry has gone. Every other revolution, whether it's the first compiler or the first OO or the first VM or anything like that, every single one of those revolutions was generated a lot of fear that we aren't going to need programmers anymore, right? lay people will be able to write code. The programmers are going to go away. They said that for forran they said that for C++ they said that for Java, right? Oh, we're not going to need programmers anymore. It's going to be great. And what really happened was we needed even more programmers. >> Y >> and I think that's exactly what's going to happen with AI. The the AI power will open up so many possibilities that we will need even more programmers to tell the AIs what to do. That's that's how I expect this to work. That's very interesting because that ties into my next question which is how do you envision the principles of good software craft craftsmanship the kind of clean code that you've been adv advocating for um decades now um how does that evolve how do you see >> how do you see these principles >> evolves any different >> tell me >> I don't um so assembly language I'm writing assembly language what principles am I using same principles I use today when I was writing C what principles was I using same principles now I'm writing enclosure same principles right organization specification use nice names you know separation of concerns coupling cohesion all those things are still going to be there when we are writing prompts in a structured well-defined legalistic way we will have all those same issues. Read a contract. Read a a contract from a lawyer and you will see all those principles in that contract. Coupling and cohesion and organization and naming things properly. They're all there in the in the language of lawyers. So, and that's what we will end up being just machine lawyers. >> Machine lawyers. Yeah. Programmers. Okay. Um how do you uh how does one get these principles internally? I mean there are ways to formalize them and uh obviously you spend a good amount of time uh clearly specifying what those principles are and with many examples and with uh more books than uh other people I mean many people have ever read. you've written more more books on programming that many programmers have read really uh about these. How do you how do you envision people really internalizing these principles uh at an intuitive level? Because it sounds to me that as the programming industry evolves, the way that we're going to specify our programs is like a program in the sense that we are not really writing very well structured code but better structured English or a less structured language and leave the AI to um generate more and more of that. And so the principles of clean code, good understanding, um, good I mean separation of concerns, all the ideas that you've been discussing are now going to be expressed at an intuitive level. And the question is, how can that intuition ever be acquired? Uh, and is there a way to accelerate that process? This is a bit a pretty wide and a pretty vague question, but I I'll let you take that wherever you like. >> Well, okay. So, I I believe that the the principles we're talking about principles of good good code. >> Mhm. >> Yeah. >> Uh will evolve along with our uh adoption of AIS. >> And it'll evolve in the same way that it always has. You know, when people first started writing uh object-oriented code, they made a mess of it. You know, we all made a mess of it because we didn't really understand exactly how to apply this whole inheritance thing, classes, and methods. And that was just so brand new. But over a period of about 5 years, all the old rules that applied back in the 70s reasserted themselves in this new context. And all of a sudden, we're all going, "Oh, yeah. No, this isn't really all that different, is it?" Okay, yeah, we got to separate this. We got to put all that together. Okay, name things. Okay, it's kind of the same thing. Oh, a little different language, but it's kind of the same thing. And then that happens over and over again. And I think that's what will happen here, right? Because at first, we're just writing, you know, English to the machine. Hey machine, I want you to do this and that and this and that. and it generates something and then you look at it and go, "Well, no, you didn't generate it right, so I need to add more to the prompt." Add more to the prompt. Now, generate it. Oh, no, that's not right either. Okay, add more to the prompt. Take this thing out. Move that thing around like so. Do that. Okay, more to the prompt. And as you're doing that work, you are once again rediscovering all the old rules that were that were around in the 70s and the 80s. Same old rules. Okay. Yeah. Separation of concern, name things well, define things nicely. Okay. And in the end we will come to the conclusion that oh yeah this really isn't all that different is it? It's just kind of the same just in a slightly better language. Yeah. Just a slightly better >> interesting. So you're saying that the same principles will apply because of the I I mean kind of like a Lindy effect but uh just the way that we're phrasing it to the computers is going to change is going to change. Nothing else. >> We will make the mistakes cuz everybody will and then we won't remember. Oh yeah. Yeah. That happened to me back when I was writing in C. Okay. Yeah. Yeah. I gotta do it this way. All the same rules will just come. Some more rules might come out. There might be some better uh different rules, but all those same basic principles will reapply themselves. And you asked an interesting question. You know, how do you internalize those rules? And the answer to that and and you implied it is to read read like crazy. Read as much as you can and read the stuff that was written in the 70s. Yeah. The stuff written by Tom DeMarco and Tim Listister and all those guys when they were struggling with the barest ideas they they had no idea but they just trying to get this stuff together. And as you read through that, you can feel the angst and you can identify with that angst and figure out the pathway that these principles follow. You know, everybody always says uh uh best time to learn history is is when you're young, but nobody bothers. You learn you learn history when you're old and then you realize, oh yeah, shouldn't have done that. It's probably going to be >> industry when you're young. Yeah. >> Uh it's probably going to be increasingly relevant for the field of programming as well. Even if this is a relatively new industry, it's starting to have a decent amount of history and of uh experiences to it and uh >> about 80 years now. Yeah. >> How do you feel the principles of clean code and of good code in general have changed over the years as you were witnessing them? Is there something that uh for example do you ever look at uh parts of your clean code book and you think oh my god I should have written this differently? >> I am in the midst of writing the second edition right now. In fact it's it's at the publisher at the moment. >> Okay. Um, and >> yes, yes, I mean there are things that I in the second edition there are things that I say differently and I change some emphasis and I relax some of the rules and I tighten some of the other rules, right? Because it's been what 15 years >> and in that 15 years I've learned a fair bit. Other people have have commented and I I understand their comments and I've incorporated them. Um, so sure, I think all of that evolves as it always does. You know, there's little bits here and there that we tune and tweak and fiddle with and that's never going to end. Uh, but then the second edition does does readress all the old ideas in a very different way. The the book is almost a complete rewrite. I think I saved a couple of chapters but even those chapters are are heavily edited. Uh but otherwise it's almost an entirely complete rewrite but the message is the same. >> Do do you have any example of something that you used to believe very strongly but uh has changed or you emphasized >> in the book? I was a very uh strong proponent proponent of test driven development and at the time I wrote it I was relatively new. I'd only been doing it for about eight or nine years. Uh, and so my disciplines were tight. I'm going to write my tests first. I'm going to write tests for everything. Over the last next 16 years, since then, I've encountered situations that made me soften those roles. And I've also en encountered debates that have made me soften those roles. Not soften the discipline. The discipline is still there, but widen the widen some of the constraints on those disciplines. So, for example, I write my tests first. I write a test, I make it pass. I write a test, I make it pass. But there are cases where that doesn't work, where you can't write the test first. And there's a bunch of reasons why, and I I don't need to go into them here, but they exist. Okay. So, then I have to write those tests after. Mhm. >> And I've accepted the fact that, you know, sometimes it's just better to write some of the tests after. Sometimes it's better, not always, but sometimes it's better to not write the test first, but to write 20 or 30 or even 40 lines of code because you don't really know what you want to do. And so, you kind of fiddle with the code and you get it into a certain kind of shape and think, okay, if I do anything more, I'm going to lose control of it. So now I'm going to write some tests. >> So that that happens to me. Uh I won't say a fair bit, but it does happen enough. >> So in the book I talk about these things. I talked about okay, I still like test-driven development. I think that's the way to go, but there are several other quasi disciplines that you can apply in certain circumstances that uh are going to be helpful. Um, I I make the same kind of quasi change in the size of functions. In in the original clean code book, I said, hey, you know, you want your functions to be five lines, four lines, six lines. You want them to be really small. Uh, in the second edition, I'm saying things like, well, yeah, that's still true. you still want your functions to be small, but there are cases where if you pull a 20line function apart, the coupling between those two functions can be too high and it makes it obs it obscures the code. So it sometimes is better to leave those leave those functions together in a single function rather than extracting them uh because it softens the coupling issue. Right? So I make that point in a number of number of places as well. And there's a lot of things like that. A lot of things where after 16 years I'm going well okay still a good rule but there are these cases off to the side that you have to be aware of. >> What other kinds of criticism have you received for for clean code? I mean what are some vocal ideas that prompted some changes to to the book? Um probably the biggest impact on the book was uh Auststerhout's um uh philosophy of software design. I think that's the name of the book. Uh a a philosophy of software. Yeah. A philosophy of software design. Um Austster wrote this book and uh he's he's very critical of clean code in the book although he's targeted, right? He does he doesn't just wipe the whole book. He says, "This thing in the book I don't agree with because of this. That thing in the book I don't agree with because of that, but this thing in the book I do agree with." So, he's he's uh he's rational about it. He's reasonable about it. He's not one of the flamers who goes off and says, "Oh, God, clean code's terrible." >> Um, and I read that book very carefully and then he and I got into an extended debate on the issue, which I actually uh transcribed that debate and I include it in the second edition >> very >> at the end as an appendix. right? Because it was a very worthwhile discussion. Um, so that's one where I thought the criticism was uh if not welld deserved, at least wellreasoned. >> Mhm. >> Now, there's a bunch of other people who have just come up and and done clickbait stuff. You know, clean code, terrible performance, just clickbait. And I get big big letters on the screen. clean code. Terrible for or it's time to stop recommending clean code there. All these lovely clickbaity things. Okay, fine. If you want to get clicks, you can do that, I guess. You know, and I I have um uh at first I tried to write uh responses. Nowadays, I don't even bother. It's just not worth it. What kept you um this this is something that I that I admire uh about you because you have written a lot and it seems to me that over time as you wrote new material, you incorporated feedback and experience and made you adapt the lessons that you were very adamant about as you were just describing. Um, and the reason why I admire this is that you seem to be truly um, internalizing the word craft into your code. And so I was wondering what kept you a craftsman over the years and how has that impacted the way that you view the productivity of a programmer? Long ago, I said to myself, the only way to go fast is to do a good job. You know, that's that's kind of grandparent speak, right? Grandparents tell their grandchildren, you the only way to do a good job. The only way to go fast, do a good job. Everything worth doing well. You know, just that kind of stuff. Um, but I I accepted that, you know, I said, "Okay, if I'm going to go fast, the only way I'm going to go fast is to do a good job." And therefore, everything else I learn must be targeted at doing a good job because that's the only way I'm going to go fast. My productivity can only go up the better job I do. Right? So, onetoone relationship or or a monotonic relationship, the better job I do, the higher my productivity. Productivity does not drive I I hate to use the word quality that's not the right word but productivity does not drive uh goodness of code >> goodness of code drives productivity >> what happen habits >> what habits are you keeping in order to continue growing your craft uh with the amount of stuff that's happening in the programming space I mean there are million things developing as we Uh so I was wondering how how you keep uh how you keep your craft growing when um let me say this differently. The the field that we are in is changing dramatically all the time and it and it always has. We we rode Mo Moore's law uh up until Moors law died and now we're blowing out server farms and using terowatts and and you know the the the change in our field is rampant. Some one guy I know calls it the churn. He built a whole business on taking advantage of the churn. Initially when you're young that's overwhelming, right? I mean, how can you possibly keep up with this? >> Yep. >> There's just so much happening. >> But as the years go by, you begin to realize that a lot of the churn is repetitious. It's the same thing being said in a slightly different way. And as the as the wheel turns, as the time goes by, more and more of the churn becomes identifiable as old news, even though it's stated as something new. It's old news. It's been around that block before. Don't need to pay attention to it any longer. So, uh, we've had a whole bunch of new languages come out, right? And I'll go all the way back to the Golang. Beautiful language, by the way. Old news. Old news. We've been around that block a few times. Not that the language is bad. It's just okay. We tried that before. Uh, a couple little differences. Who cares? Um, same thing with um Oh, what is the big one now? Uh, React. Oh, everybody's talking about React and and and I know that's a little old news, but oh, everybody's still talking about React. It's old news. It's old news. And you pick up a an inside Macintosh. Old news, right? It's been around that block. So, so the way I deal with the question that you're asking me is that I I have enough experience to look at the churn and pick out the things that are really new and there aren't many and ignore the things that are just old news. And I, you know, I can look at the old new stuff and evaluate it and say, you know, I'll spend a day and say, "Yeah, okay, I get it." And then I don't have to spend any more time on. Am I risking missing an innovation? Yeah, maybe. But everybody has to parse the stream that's coming in based on their experience and then pick the things that are that they believe are going to be impactful. And you know, with 50 years behind me, I'm I'm looking at those things and thinking, okay, I I think I know what they are. >> I could be wrong, but I think I know what they are. Something that makes me very curious about this um this idea ties into some of my earlier questions about good taste and uh internalizing good code. You and I are both teachers. Obviously you have um more experience uh teaching than I have of life. But uh I was one thing that I believe as a teacher is that if something can be learned, it can be taught. So my question to you is can this skill of identifying patterns and finding out what's old and constant can the skill be taught and if it can be accelerated in any way? >> Well, I think it can. Um the the way the way young people learn is by dealing with people who've been around the block a few times, right? By the way, that's something that we've lost in in the programming industry to some extent. Uh but in general, if you're going to learn something and learn it well, you want to learn it from someone who has been doing it for a long time. So I sitting next to an apprentice can identify things to that apprentice. The apprentice may run in and say, "Hey, look at this. It's so new." And I can say, "Yeah, no, that's not new at all. And here's why." And I can pull the books down off my shelf and say, "See there? See there? That was all done 30 years ago. And if you do that a few times, uh, you start to inculcate in the apprentice, uh, a a value system for the things that are old and be able to compare that to the things that are new, right? Which is good. That's a good thing to do. Now, I said that that our industry has um not been following that rule very well or not following that pattern. One of the reasons for that is is that we seem to think that programming can be learned in uh a 13-week boot camp or um a 4-year degree program that has a couple of computer science courses taught by people who have never coded in anger in their life. Uh it's probably not a good way to bring programmers into the world. Yeah. My son runs a company um called Clean Coders >> and he uses this apprenticeship model, right? And it and he's really detailed and disciplined about it, right? And they bring apprentices in and the apprentices go through a fairly long cycle before they ever touch client code, right? They go through a fairly long cycle of dealing with the masters uh and learning how to do things well. Aside from apprenticeships and uh osmosis for the lack of a better term, is there any other way that you think the skill can be imparted? The skills skills are something you learn by doing, but the values can be imparted, right? And and you learn values two ways. You either learn learn values by learning them from someone you respect or you learn them by making a lot of mistakes. >> Yeah. either way will work just fine. Um the the first of those, learning from people that you respect, the best way to do that is just to read. And again, I'll just go back to that again. Read, read, read, read, read. Find all these books and read them. Uh don't don't make the mistake of thinking that you're a programmer because you know how to write an if statement. >> Yep. >> Okay. What books would you recommend a newcomer read in order to I mean okay you've written more books than than uh um yeah okay uh but some foundational books uh that a newcomer is supposed to have internalized not just read in order to call themselves a programmer or maybe a craftsman. Well, okay. I I kind of like I kind of don't like to use the uh the phrase in order to call themselves, but what should a young programmer read >> in order to improve their career? >> Oh my goodness. Well, I've got a lot of books here. So, let's start with some really goodies, but oldies are >> Can honest to God, you know, dear programmers, read these books. Re read them. They're wonderful. You will learn things you didn't know in these books. Fundamental algorithms. Did I have it right? Yeah. Fundamental algorithms, sorting and searching, semi-numerical algorithms. Lovely books. Get them. Can's uh what is it? The um art of computer programming written a very long time ago. >> Uh let's see. Get those books. Read those books. Um, Tom DeMarco, Structured Systems Analysis. You should definitely read this book. It is really old. It has diagrams in it that are very old style. We tend not to use those diagrams anymore, although you should know about them. And you should also understand the topic here. How do you talk to someone who is not technical >> and capture the technical essence of what they want and turn that into an a design? >> This is a great book for that that particular purpose. Uh let's see um the next book. >> This is fascinating. >> Okay. Design patterns 1995. This may be the most important book written in the last 30, 40 years. Uh, and and right now it's undergoing an awful lot of negative press. People are saying that's that's so old. That stuff is just useless. No, we're not. No, you you should know this stuff. You should know this really really well. This is a very very important, very powerful topic. And this book is the uh the book that describes it best. Although there are some others out there that do a nice job. You should definitely learn that book. This book, I already pulled it out. God, read this book. >> Yeah, this is >> Read it later. All right. After you've read a few of these others, read this one cuz this this one changed my life. This one was a a really interesting book. By the way, you can still see all their lectures online as they're drawing lisp code on a blackboard. parenthesy parenthesy parenthesy. Fascinating. Fascinating stuff. Uh let's see what else is there. Oh, heavens heavens. How could I have forgotten this one? 1972 structured programming. >> Dystra doll You will read this book and you will learn where an awful lot of the ideas you think are modern uh came from because a lot of them are sitting right in this book. Great book to read. Uh pretty easy reading. Martin Fowler Refactor. >> Refactoring again. >> Second. This is the second edition. It doesn't matter which edition you get, frankly. Uh but e either one. This is probably the only one you can get now. uh but startling book from from my point of view. I read this in 1995 and it was one of those things where it was the first book to ever represent code as something malleable, something that you could change and improve. All the other books before that just showed you code in its final form. This book shows you code before it's reached its final form and then shows you how to improve it. Fascinating book. Very well worth very well worth uh having around. Let's see. One more. One more. Uh it's up here somewhere. Yep. Yep. There it is. >> Yep. >> Very undervalued book. Analysis patterns. Wonderful. Wonderful. These are ideas for how to take a business person's mindset and turn it into something that you can articulate in code. Wonderful book m this is the best book Martin Fowler ever wrote and not nearly enough people have read it. So So let's see. I could probably go on but there's >> fascinating >> there's a few that that you ought to read. Nice. Thank you so much for that. I'm going to uh add notes to to the video and to the conversation so that people can uh grab these books uh whenever they can. Um okay, how do you convince these people? Uh I mean, okay, I I I don't I'm thinking about how to phrase this. Um, how do you convince people to adopt the principles within the books that you've just shown us? Uh, to adopt these patterns and ways of thinking as habits, not just a nice to have or a one shot a one-shot thing that you have to do when your code starts breaking and when you're doing rewrites. How do you uh how do you convince people to adopt these things as a recurrent thing that they should keep in the back of their minds? >> I've come to the conclusion over many years of attempting to convince people that you can't convince anybody of these things. Oh, there are a few people who will listen and internalize. Most people will listen and become skeptical. And there's not anything wrong with that. That's a healthy attitude to take. And then uh they might leave leave and do something else for a while. There will come a moment in their career when suddenly something will go wrong or about to go wrong and their memory will go, "Oh, I heard about that." And that'll be the convincing moment. And it it may take many of those moments. all of a sudden you see, oh yeah, that guy over there, he said this, he said this, he does that, he does that. I think I understand why now. So, I've seen that happen a great deal. But, but the the convincing bit, that's very hard to do. Now, what do I do? What do I do to convince people? Well, I go on podcasts like this and I talk about it a lot and I write a lot of books and I write a lot of articles and blogs and I speak at conferences and I do YouTube rants and I do as much communicating as I can in the hope that some of that information will get into the brains of the people who are listening and then one day germinate and turn into a blossom. something flower. >> Got it. >> Probably chose the wrong metaphor there. But >> if you can convince one person and uh that person ends up building some useful code, then uh it's probably mission successful at least on that front. Um >> hope so. I I I have some follow-up questions that are um let's say a little bit more self-interested because I'm a teacher and I am looking for ways to develop myself as a teacher and you are a person that I uh would like to learn from not just as a programmer because you've written a lot and uh there there's so much material that you speak about in your books than we can ever cover in a conversation like this but Maybe uh could you tell me when did you realize that you are a teacher? because in your writing uh you can you can consider your writing as a form of teaching and I I'm wondering how you realized that you were a teacher and how you developed your own skills as a teacher because it it shows in this conversation that you're very engaging that you describe things in a certain way that you use certain gestures that you use certain words that you use certain emphasis and I'm I want to get some of those skills for myself as well. So, I'm wondering how when did you realize that you had this in you and how did you develop these skills? >> If I look way back into my childhood, I can recognize moments where um I was enjoying teaching something. >> Okay? And this goes way back to like being five or four, >> okay? Way back in time. It's probably some kind of personality defect. You know, if you get me into lecture mode, um it's hard to stop me. >> And so I I enjoy it. I enjoy the lecture. It's a passion. It's something that that I dream of doing. If I'm out on my bicycle riding and I'll do a 20-mi bike ride and that bike ride will be me lecturing to a a fictitious audience, refining my arguments and you refining my the phrasiology that I use and coming up with sound bites. It's just something that is in my head. I do it. The most important advice I can give to anyone who wants to teach is to have a ton of fun. If you're having fun, everybody else will too and they will learn. If you're up there stiff and you're teaching because you have to teach something, uh, everybody's going to turn off. >> Absolutely. >> You have to have a passion for what you're teaching. You have to enjoy the the delivery of the message. You have to be as engaged as a human being can be in the delivery of communication and everybody else is going to go, "Oh yeah, I could." It's the It's the best way to open other people to receive information. If you enjoy yourself visibly and animatedly, everybody else will too. >> That's something that I've definitely seen. And uh when I the way that I could get an audience to be engaged is for me to be engaged in the subject first and they will mirror my engagement at least in the topic and then to me as a speaker as well because they will see how how much energy and how much uh for yeah how much passion really uh I've invested into the subject and into making it as clear as possible. So, it uh this advice definitely resonates. Have you ever trained this skill of clarifying information and delivering it to people or has it just occurred naturally to you and h uh you've grown it just by just delivering lots of talks? Did you grow it in any way deliberately? Um I have been asked from time to time to train um people in the art of public speaking and the art of teaching. >> Uh which I enjoy doing. That's great. Um I I enjoy doing those lectures as well. Nobody gave me a lecture like that. >> Now my father was a science teacher. >> Uh and he and I would have very long discussions on scientific and religious topics and philosophical topics. and he was a very good speaker in a one-to-one basis. So I think I learned a few things from him. I also learned an awful lot about um delivery from of all people Bill Cosby. I used to I used to listen to his comedy routines over and over. I memorized most of them back when I was 10 or 11 or 12. Uh, and if you're if you're if you follow if you've ever followed Bill Cosby and then you watch me, you will identify some mannerisms because I certainly internalized a lot of what he did. Uh, despite I know the the the controversy that came later. The man was a genius. Um, so there's a lot of things like that where I I would watch people who delivered things well. Have you ever watched a Fineman lecture? >> Yes. Holy cow, that guy is is he liked what he did. >> He he really enjoyed it and he he enjoyed delivering the message. >> WA is kind of a benchmark for me. Uh from the point of view of teaching, he loved this so much. You can see it in his writing as well. He >> Yeah. Uh so you learned uh to grow your your speaking and your delivery skills by osmosis from the people that you admire. Am I getting this right? >> Um yeah. And there was also just some internal uh personality defect. I remember being 5 years old and uh my kindergarten teacher said, "Bobby, why don't you sing Rudolph the Red-Nosed Reindeer?" It was Christmas. And you know how kids usually sing really soft when they when they have to sing in public? And I just belted the dog on thing out. I got up in front of everybody and just Rudolph the Red-Nosed Reindeer. Five years old. No fear of audiences. Never. I've never had a fear of audiences. Um, for whatever reason, like I said, some kind of weird personality defect. >> It's just an obstacle that you didn't have to overcome. That's it. As far as I can tell, >> I never get stage fright. Um, and I'm almost at my happiest when I'm on stage. Almost. where uh okay uh I'm curious about that. Um do you go to conferences at all at uh this time? >> Uh up until co I was an avid conference go. I did a lot of uh going and speaking and you know I traveled all over the world. Mhm. >> Um since CO, you know, that all stopped at CO and then once it started up again, I'm of a certain age where I thought, you know, I don't need to get on an airplane again. I don't need to travel so much anymore. Why don't I stay home with my wife whom I really enjoy being with and my, you know, children and grandchildren. So nowadays, I don't do that stuff very much and I used to used to do it a lot. What? Okay. Uh I'm curious about how you think about programming conferences. What makes a great programming conference to you to to you given your experience? >> What makes a great programming conference? Um somebody writing a lot of code on the screen. >> Okay. >> Uh demonstrating things uh very very well. Uh so there's been a number of conferences where where that happens, right? Somebody will put something on the screen. It's code on the screen. You got a bunch of programmers staring at that and then the the person is going through it point by point demonstrating some interesting principle or feature or maybe something about a framework or something about a language. But if there's it's a bunch of programmers, right? If there's code on the screen, you've got their attention. The worst thing is when somebody gets up on the on the stage and is talking about something philosophical blahy blah at least for me, you know, I just turn that off. Okay, where's the code? Show me the code. >> Um, so that's that's from my point of view. Whenever I gave talks, uh, there was code on the screen or there was something technical on the screen, something that would draw a programmer in. uh and that's what I enjoy talking about enjoy uh presenting >> anything else other other than uh writing and demonstrating code this is intuitively how I've uh how I've held pretty much all my all my conference talks they're like just like live coding uh but I'm uh wondering what you felt made a great programming conference Uh, aside from the demonstration of code, is there anything else that made you feel, oh, that was a great that was a great event. I would go there again. There have been a a a number of conferences I've been to where a a keynote speaker has been invited >> and it's a keynote speaker who had who who's very experienced and had a significant message to deliver. >> Uh so I I once attended a conference where Tom DeMarco gave a speech and he had no code on the screen but it didn't matter because it was Tom DeMarco and he had a message and the message was a good message. Um, I've been to into conferences where Grady Booch is a keynote speaker. >> And again, no code on the screen, but a good message, a good message about being a software developer or a software manager or a certain kind of discipline. Um, those I I count as being very worthwhile conferences to have been to. But what makes a conference worthwhile apart from all of that is just hanging out with a bunch of guys who want to go to conferences >> and you know hanging out in there and then sitting next to him and say hey let's write some code come on show me this new language that you've been up to. the uh it's the social activity of getting a bunch of programmers in a room and or or in a in a building uh and then letting them interact with each other and then okay you go to a talk every once in a while and okay you go to a keynote but mostly it's just that camaraderie that's the best thing about a good software conference. Gracehopper uh convened the very first software conference ever in 1950 something or other. Uh and it was it was a conference about the possibility of having compilers because back then they were just doing machine language. And um she says of that conference that it was a great conference. I mean a lot of good talks and and you know people showing possibilities for how you could do you know arithmetic expressions in a language. Nobody had ever thought of that before. Really interesting stuff. But the most important things happened at the bar between between 1000 p.m. and 2 am. >> Yeah. >> So that's really where the conference happens. >> Okay. Nice. I'll take these uh U. Robert, I wanted to be respectful of your time. So, uh as we draw this conversation to a wrap, uh is there anything that you would like to share with my audience? Maybe a a thought, a quip, a piece of advice. uh the famous kind of billboard that other podcasters seem to be asking like if you had a billboard that could be seen by millions of people what would you write on it? Any any anything of that sort that you would like to say to my audience? >> Well, probably um appropriate for the times we are in. Don't be afraid of the future. >> Be great. >> Good one. A lot of programmers are afraid of this AI thing and uh they're paralyzed like, "Oh my god, I'm going to be left without a job. What am I going to learn next? How should I sharpen my skills? Am I going to be stressed for the rest of my career?" Good. That's a good one. That's a good one. Robert, it's been a pleasure. Thank you so much for being so gracious with your time. I'm going to leave links >> I'm going to leave a lot uh a lot of links because we have a lot of book recommendations and pieces of advice and people that uh are worth following and worth listening to. Robert, it's been a privilege. Thank you so much for making the time. Well, >> I appreciate it. Thank you.