Robert C. Martin (Uncle Bob) is the co-founder of cleancoders.com, author of several very popular books including clean code, public speaker, idol of many programmers.
Uncle Bob joins to talk about clean coder, programming professionalism, the future of programming, lisp and Clojure, and the recommended reading books, etc.
Sponsors
This episode is sponsored by FormAssembly.
22 Ways to Use FormAssembly for Remote Work Success – Learn how to streamline remote work processes with FormAssembly’s all-in-one form builder and data collection platform
Go to getclayton.com/salesforceway or use the code SALESFORCEWAY to get one month free. The offer expires on October, 31st 2020.
Links
- [Book] Clean Coder
- [Blog] Uncle Bob’s personal blog
- [Site] Clean Coder site with programming videos
- [Video] The future of programming
- [Book] Uncle Bob recommended books
- [Video] Teaching videos for SICP book
Video
Video format of this episode on YouTube
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] I'd like to welcome our sponsor Form Assembly. You can find out how Form Assembly helps streamline remote work processes in the free ebook that we've linked in today's show notes. Form Assembly's all-in-one web form platform lets you create forms for just about any use case, from contact forms to donation forms, all while take advantage of useful features such as notifications, e-signatures, and more. Not only that, but you can also connect data to systems you already use. Form Assembly integrates with Salesforce, Padal, PayPal, and many other common solutions. Whatever your data collection needs are, you can be sure that Form Assembly keeps your data secure with encryption at rest and in transit on all plans, plus compliance with GDPR, CCPA, and more regulations. At the end of the day, form assembly helps you save time, money, and effort while getting the maximum benefit out of the data you collect. And I remind you, when you support our sponsors, you support the show.
[01:19] Hi, this is a continuation from the last episode.
[01:25] The the. The metric for mastery is usually something like ten thousand hours, right? Which is which is five years of full time work. And most programmers, most programmers don't make it to five years. They they leave and they go off to management or something because they they think they're supposed to. We have a we have a significant problem in our industry, which is the youth of that industry. It's growing like crazy. The number of programmers in the world doubles roughly every five years, and if you think about that for very long, you'll realize that half the programmers in the world must have less than five years experience. Well, that's not enough time. It's not enough time to become really grounded in in what is actually a a rich and complicated field. And so we we lose the people who are gaining experience. We lose them in two ways. We lose them because they get diluted by the the massive number of new people that are constantly coming in and who are all in their young twenties. And we also lose them because there is this pressure upon programmers not to remain programmers. They believe that their pathway is to leave programming and go into marketing and sales and management stuff like that. And my answer to that is hell
[02:55] no. If you are a programmer, stay a programmer for thirty years, but get good at it. You know, get really good at it, and. You know, you may think that the best way to make money is to be go into management. I, I can tell you that's not the case. I get it. I I saw one of your YouTube videos. It's the future of programming. Yeah, you talk about the importance of all this, the principles, or the, you know, this. You even have a programmer's oath in your personal blog. Yes, yes. So that's. Maybe you can brief us. Why do you do this? What's what's idea behind? Our civilization depends on programmers for its existence. We we could not exist as a civilization without computers. This did not used to be true. Thirty years ago, the normal human did not interact with a computer at all. Nowadays, nowadays, a human in the Western world interacts with a computer to do anything. You can't do anything without interacting with a computer. You can't microwave popcorn because there's a computer in that microwave. Didn't used to be the case. Now it is. You can't change the temperature in your home because there are really sophisticated computers in your thermostats. You can't make a phone call. Good God, a phone call. Hell. How many computers are in this damn
[04:25] thing? How many lines of code are in this thing? You can't watch TV. You can't drive your car. Modern car has one hundred million lines of code in it. You can't do anything in our society without interacting with a software system. Programmers rule the world. Other people think they rule the world, and then they hand us the rules, and we write those rules into the machines that govern everything. And our society does not quite understand this yet. It's gotten a couple of big hints recently. The 737 Max was a pretty big hint that software developers can kill a thousand people pretty easily, right? The the Volkswagen folks got a really big hint when they tried to get away with cheating the EPA machines in California. Some of those programmers went to jail, by the way. The folks at Knight Capital got a really big idea when one when a couple of programmers cost them 450 million dollars in 45 minutes. We programmers are now in the position where we can, with a single line of code, kill a thousand people, and that's not acceptable. That's not tenable. The civil, our civilization will recognize it, and we'll have to do something about it. There, there will come a moment when some poor schlock programmer will do something stupid and kill ten thousand people in a single
[05:55] shot, and the politicians of the world will look at each other and go, "Oh my God, what have we done? How have we allowed these people to go uncontrolled for so long?" And then they will legislate.
[06:09] I would like to get there before the politicians do, because the politicians will do a terrible job. They always do. I want to get there before they do. I want to know what the rules are. So we, as programmers, should be focused on establishing our ethics. What are the ethics of software? What are the standards that we refuse to cross? We will not go below. Right? What are the what are the disciplines that we all acknowledge we must follow in order to be a programmer? And that's why I wrote that oath. That's one of the one of the reasons I wrote that oath. Just as a a stake in the ground to say, look, there are certain things. To be a programmer, you must promise to uphold. Hmm. I don't know. For you, Uncle Bob, have you ever written a program in those life-critical systems, like in the airplane? Have you ever done that? The reason I'm asking is: is there like a higher stand? There must be higher standards in those systems, right, compared to the normal ones. There are higher standards in aeronautic software, in medical software, in mission critical software. You can see what those higher higher standards are. They involve testing. They involve other disciplines. The problem we've got is not that. The problem we've got is that do we know what
[07:39] software could kill people? For example, the software in the thermostat on the wall. What damage can that software do? Well, it happens to sit on the internet. It it hooks into Wi-Fi, and ooh, really nasty people can write code that recruits a million thermostats around the world and can cause them to send messages out on the internet to to cause denial of service attacks on life critical systems. Can you imagine? You know, an an aggressive enemy of the United States or some other country coming up with a a virus that finds every thermostat, you know, hundred million thermostats, and uses it to completely shut down the internet in that company in that country, right? That could kill an awful lot of people. Do the do the people do the programmers writing the code in those thermostats practice disciplines that will prevent those kinds of hacks? Or are they just a bunch of guys who write a little bit of code and oh yeah, kind of works and it's just a thermostat. So who cares?
[09:02] It's gotten to the point where you must care. If it sits on the internet, you must care. If it's a game that sits on the internet, you must care. If it's a thermostat, if it's a microwave oven, if it's a refrigerator, you must care. If it's a car that gets signals from the cellular network, you must care. But it's so hard to. Dict right? I'm where is my code to be used? Or now? Or in the future? For example, I'm writing Salesforce code. It's just to manage the company's customer-related data. It's critical for the company, but I don't think it will kill people. So can I lower the standards because of this? It's really hard to say. Nowadays, oh, could the could the code in Salesforce be used to kill people? What an interesting thought. Now, if you were a a foreign adversary, and you had the means to change the way people recruited. High-level individuals and salespeople and marketing people, so that they could be preferentially people that were were sympathetic to your cause.
[10:27] How many people could that end up killing? But that's not like a direct, right? That's kind of like indirect. Yeah, none of this is going to be direct. None of this will be direct. It's the indirect problems that that are becoming really significant. The seven thirty sevens crashed not because of any direct software fault, but because of an indirect linkage between a piece of hardware that was broken and a set of requirements that did not anticipate that correctly. Still a software fault. But very indirect. the The direct lie told by the Volkswagen guys. That's not really the problem. The indirect problem of not updating all the servers. At night, capital caused them to lose four hundred fifty million dollars. That was that was an indirect thing, and and the linkages in these indirect chains are going to get longer and longer because software is everywhere. Yeah, it totally makes sense. Yeah. But maybe I mean thirty. You said it. Thirty years ago, we didn't even normal people didn't really use computer at all. I would assume the world is just going faster and faster. Maybe thirty years after now. It's a totally different world, right? Yeah, probably. Although maybe a little less different than we think, because the last thirty years were the
[11:57] were the peak of Moore's law. Density was increasing at an exponential rate. Speed was increasing at an exponential rate. The computers were simply getting better and better and better at astonishing rates, and that stopped. That's gone. Computers are not getting faster. They are not getting denser. The laptop I have today, which I just bought a month ago, is not significantly better than the one I replaced it with. That's five years old.
[12:30] So it is entirely possible that we have just turned the corner on a plateau, and that plateau may be where we live for the next thirty years. I got it. So, what are the skills programmers should learn, in your opinion? Because you have another book I have also read is the Clean Code book. In that book, you talk a lot about professionalism as a programmer. I do.
[13:05] Yeah, there it is. The clean code. Yes. Yeah. So, in this book, what kind of skills do you advocate for programmers?
[13:16] Well, the the Clean Coder book is the human side of the story. Clean code was the code side of the story. So, as I was writing Clean Code, there were a number of things I wanted to talk about. But they didn't fit in the book because the book is about code, and so I I had this big backlog of issues to talk about, and that's why I wrote this book. This book is about how you deal with being a programmer. How do you deal with the fact that your boss will put you under pressure? How do you deal with the fact that? If you have a big fight with your significant other, your wife or your husband or your partner, you're not going to be able to write a damn bit of code for a day or two. How do you how do you deal with these things? And that's that's really what this book is about. You know how to be a professional programmer. One of the big one of the most important parts of being a professional programmer is to realize a fundamental truth. You may believe that your job is to get programs to work. That is wrong. Your job is to get programs that communicate with other programmers. They may not work, but but if they communicate to other programmers, if other programmers can understand them, then those other programmers can
[14:46] make them work. I see. First job of the programmer is communication, not with the machine, but with other programmers, and with the business. A lot of programmers have no concept of how to how to communicate with the business. They don't understand the business. They don't want to understand the business. This is a fatal flaw. You you must understand the business that you are writing code for. And so, a a programmer who wants to become even a a middling programmer must understand the business. Must spend time understanding the business they are writing the code for. I see. I see. Hmm. In my podcast, they usually talk about also the soft skills, because one of the reason you are the idol of so many programmers, including myself, is that you really have a. Characteristic, your own characteristic. It's charming, and you talk in an entertaining way that can easily attract the people. How did you grow these skills? Did you learn it on purpose?
[16:01] That's a really interesting question. I am an introvert, a a serious introvert. I don't like people. Okay. I'm much happier sitting here at my laptop writing code. Right. And if you put me into an environment where there are a lot of people, I tend to kind of just sit there quietly and nod and and wish that I could be home on my laptop.
[16:27] But I have a bizarre personality quirk, which is that if you give me a formula. For interacting with people, I can do it very well. So, for example, put me on stage and ask me to sing a song, and I will belt that song out at a really high volume and entertain everybody. Right or or ask me to give a talk and I will give a talk and and it'll be animated and I can make everybody smile and listen, or we can do a podcast like this and it and the the beauty of this kind of mode of communication for me. Is that it's very formulaic? I know exactly what to do. I have a program that I wrote in my head. I know what to do in each case. So that makes it very easy for me to to be this kind of programmer, to be this kind of speaker, to be this kind of educator. Maybe it was maybe I was born with it. I don't know, but it's it's easy for me. Programmers in general did not become programmers because they like people. Right, we're engineers. Engineers focus on things, not people, so much. And the the people, people to us are unpredictable variables in a world that ought not have unpredictable variables. So we like to focus on the predictable part of the world, the code. Now,
[17:57] that's always a problem because the people we need to communicate with. Are unpredictable variables that we need to get some kind of control over—not control over, but communications with—and there are a couple of little techniques that I've learned over the years that help with this a great deal. And the first one is know your standards and defend those standards. Your boss does not have the authority to override your standards. You have the right to say no. You don't want to do this with animosity or anger. You just simply want to say, No, I have some standards here, and I cannot do what you're asking me to do. For example, your boss comes to you and says it's got to be done by Tuesday, and you know that there is just no way that it's going to be done by Tuesday. There's there's nothing you can do to get this done by Tuesday. You must then say no. It's not going to be done by Tuesday. You don't understand how important this is. You must do everything possible in order to get it done by Tuesday. I'm sorry, but it will not be done by Tuesday. This is not anything I have any control over. You, dear manager, must manage the situation. Don't be rude about this, but make sure that you hold that standard.
[19:25] Hey friends! This episode sponsored by Clayden. Clayden is the first developer-friendly code review bot that helps Salesforce teams catch security and design flaws before they become problems. It's up and running in Clux and works with GitHub, Bitbucket, GitLab, and Azure DevOps. Go to getclaydon.com/salesforceway to get one month free.
[19:51] It's getclaydon.com/salesforceway.
[19:54] You can also find the link in our show notes. Thank you for supporting our sponsors. And then be aware that there will be manipulations. The manager will say. Well, you at least try, and and it seems so obvious that you ought to say, well, yes, of course I will try. But you must never say that, because it's a lie. You're not going to try. You already know there's nothing you can do. There's no extra thing you're going to suddenly do. There's no no new thing that will pop into your brain that will suddenly allow Tuesday to be possible. So your response to this should be, Sir, we are already trying. There is nothing else we can do.
[20:46] Now this is an example of the way that managers get to the truth. We we engineers we get to the truth by looking at the math you know oh the program works or it doesn't it's red or it's green very black and white right red red and green managers get to the truth through emotional confrontation. They're they're the people who like people. They get to the truth by manipulating people. They will confront you emotionally. They will come up in your face. They will make sure that you understand how important this is. And if you back down. Then they know that they have they have learned what the truth is. The truth is that you had more you could give. But if you don't back down, if you hold your ground, and you know that you're right about it, then they will walk away from that, knowing that they got the truth. And and by the way, they'll gain a lot of respect for you because you did not back down. That's how they learn to respect. I um I I got I learned this the hard way. Okay, I was in charge of a group of programmers. This was thirty years ago. I was I was in charge of a group of programmers, and we had a customer that that our group was focused on. And this customer had been through the ringer, right? We had promised them over and over things, never delivered, never delivered. And I, I had gone to this
[22:16] the manager, and I'd made promises, and I was bound and determined to keep those promises because the poor guy. I mean, he had been run through the ringer, right? So, so now I'm back in the main office, and I'm in a conference with a bunch of other managers. And I can hear what they're doing. Right, they're going to take resources and reallocate them to other things, and I'm watching them. I can see them make these decisions. Right, and they're going to take them from me, and I'm going to have to break my promise to this guy. And something snapped in my head. And I I got red faced and I started yelling at the mall saying Do you understand what we are doing to this guy that we have made promises to over and over again We cannot do that And you know I I thought sure I was going to get fired. And then I sat down, you know, with sweat and red face, and thinking, "Oh my god, what did I just do?" And they all looked at me and said, "Well, you've got a good point."
[23:19] That's, and that was the day I learned that emotional confrontation is how they learn the truth. I see. I especially love one of the things you mentioned just now is. You don't even need to you you you don't even try to say I will try. That's not even in your dictionary because there's nothing you can really try. Why? Yes, yes. That's that's so good to hear from you. Let's let's talk a little bit back to the code part because I'm personally really interested about Lisp language. Yeah, because I started to touch Emacs at the early days, so Lisp was definitely language there, and then we have Closure. It was a beautiful language, and the interesting thing is that you love Closure and Lisp so much. You always advocate them in your personal blog. Could you brief us why do you think Lisp is important?
[24:30] There are only a few languages in the world that have managed this trade-off between power and syntax. Lisp is one of them. It has almost no syntax. And yet, it is immensely powerful. Immensely powerful. The syntax of Lisp could probably be written. On half of an index card, because there's almost no syntax at all. Compare that to something like Java or C plus plus or C sharp, which are very syntax heavy languages. And because they are so syntax heavy, they tend to be constraining in the way there you can express things and how powerful they are. Lisp is one of those on the opposite side. Tiny syntax, massive expressibility. I learned this the hard way. I've for very for many many years. I was I did not know Lisp. I had heard bad things about it from other people. Too many parentheses. That's what I heard mostly, and and so I never bothered to learn Lisp. Until about oh fifteen years ago, and I got a copy of this book. Let me get it for you. Is the system book?
[25:49] It is, yeah. Structure and Interpretation of Computer Programs. By the way, this book is now free online. You just look up Structure and Interpretation of Computer Programs. The PDF is online, all for free. All the all the video sessions with the original authors are there for free. You can watch them drawing parentheses on a blackboard. It's wonderful. I got this book fifteen years ago. Somebody recommended it, and it sat on my bookshelf for a few years. Then I opened it up, and I started reading it. And it's Lisp. I didn't know it was Lisp. I just started reading it, and and as I turned the pages, I said, "Oh, I guess I'm going to learn Lisp now." Okay, fine. And the book became fascinating. You know, it was one of those things where it's a really technical book. But the the arguments they make are so compelling, and the code they write is so cool. I started like throwing the pages really fast, and I couldn't put it down. Was oh my god, this is really cool! Whoa, man, this is really and you know it was like that. I was getting more and more enthusiastic the more I read it, and then we get to page. I think I've got it marked here. It's like two hundred and forty something. And
[27:04] you know we're this far into the book, right? Two hundred and forty pages in, and they just stop, and they shut down, and they say, okay. Everything we just told you, we're gonna have to violate it now. We're gonna have to ruin it for you. And they introduced the very first assignment statement in that two hundred and some odd pages of code that did all kinds of fascinating things. There was not a single assignment statement, and I I had to go back through it and look at all that code. You mean there's no assignments in any of this code? There's no assignments, and by God, there weren't any assignments in that code. And then they go on at at page two hundred and forty something, and they say, "Now here's why this is a problem." And they define so precisely why the assignment statement is a problem, why it corrupts the flow of of processing, and then they go on. And they show a few things that you can do with assignment statements. Why you might need them from time to time. They're very cautious about it, but they they go on and then and then about fifty pages later they stop again. Oh. And they introduce threads, and I thought, what a what an interesting thing it was to equate assignment statements and threads as roughly equal complications in programming. Anyway, wonderful book. It convinced me that Lisp was a language I needed to know,
[28:34] and then I ran into Closure, which of course is Lisp on top of the JVM, which gives you the entire power of the JVM, the whole library system, and everything, the whole Java ecosystem. With this really lovely language on top of it, and I'm I'm sold. It's all I write in now, unless I have to write some Java or something. But generally, if I'm if I'm coding for myself or any of the the businesses that that I'm involved with, I write. Okay, I got it. Thanks a lot. Before let you go, one last quick question: What advices do you want to give to the young generation, the young programmers, for the reading book part? This is definitely the wonderful book I would assume.
[29:20] Yes, certainly. Certainly, there's you know, good book here. Interpretation of computer programs for the young programmers. What books should you read?
[29:43] Start with those. This is Canoos. The Art of Computer Programming, mathematical heavy book, fundamental algorithms, sorting and searching, semi-numerical algorithms. Read these, understand them, understand all the data structures. You know how do trees work? How do queues work? How do linked lists work? How do doubly linked lists work? How do you generate random numbers? Why would you want to know that? How do you sort? How do you search? Learn all these things. This is just like the foundation, right? If you don't know this stuff, you are like a doctor. Who does not know what pulse is? It's just you must know this stuff. Go to the fundamentals. They're utterly fundamentals, and you must know them. Next, ah, where's where's my where's my books here? Um, oh yeah, here we go.
[30:45] A
[30:47] lovely book written in the late seventies, "Structured Analysis and System Specification" by Tom DeMarco. Get a hold of this book and understand it. It will it will describe to you a technique that no one uses anymore, right? And and no one probably should use anymore. But you should understand this because it's necessary. To know where you are today, it is necessary to understand where we came from and why. Here's another one like that: Structured Systems Design by Miler Page Jones. Right, practical guide to structured systems design. Read these books; they're quick reads, and they will give you a tremendous amount of context. And then let's see one more book,
[31:37] two more books.
[31:42] First of all, there's this one. This is Martin Fowler, right? Refactor. Okay. Ref. Read refactoring. Understand it. He's got a new a new edition out. It's all done in JavaScript. This one's done in Java. Nineteen ninety five book. I think it's ninety nine actually. I think this is a ninety nine book. The new one just came out, so you know you can read either one. It doesn't matter. And then, much underrated. But utterly, utterly wonderful and and analysis patterns and important is analysis patterns. This also is Martin Fowler, where he goes through business rules, business objects. What are the common patterns of of businessy kinds of things? This this really, really very useful. One more book. One more. I'll give you one more. The most important book written within the last thirty years. Design Patterns. The modern view of this book is that it's outdated and no longer necessary. That's absolute crap. This book, written in 1995, is probably the most important book written in the last 30 or 40 years because it does not give us anything new. It describes a set of 24 solutions to problems that recur over and over and over again. And if you don't know these patterns, you are working at a an extreme disadvantage.
[33:13] And with that, I think that's probably enough of a backlog. This reminds me. The functional programming part nowadays. When I follow you, following Martin Fowler, following Michael Feathers, all these great programmers, your personal blog are usually talking about functional programming. So the OO is no longer like in the trend. What what's the the word going on on this part is that FF is definitely more trendy. Oh, it's certainly trendy. So, but but let's get a we need to get a few things straight here. OO is not gone. OO is not has not been superseded. Functional has not replaced OO. Functional programming was actually the first paradigm invented. That was way back in the nineteen thirty s, right? And and Lisp is an old language, functional language that came out in the fifty s. OO was invented in the sixty s. Procedural programming, structured programming was also invented in the sixty s. These three modes of programming were all invented or discovered roughly around the same time, but our hardware and our software technology was not up for them. Eventually, the the hardware and the software got good enough where we could do reasonable OO. You know, polymorphic dispatch became actually feasible, and then it's only in the last few years,
[34:44] the last decade or so, that functional programming was actually feasible in a an efficient way. We can now write functional programmers programs that run like lightning, whereas before they were all kind of slow. The three of those ideas: structured programming, object-oriented programming, functional programming, are.
[35:09] Synergistic with each other, they work with each other. They are not mutually exclusive. You are not doing OO and then not functional. You are not doing functional and not OO. They are not orthogonal. They run together. And a good programmer will write a program that is structured, object oriented, and functional, all at the same time. Okay, this is a new idea to me definitely. I spend my whole life writing OO and I just started to learn a bit of Haskell because Mark Seemanns highly recommended to learn Haskell. Then I started to touch that. So well, a lot of new things, exciting new things in front of me. I just, as you mentioned, those books. I just need to buy those books and then sit and read them through. Thanks a lot for this. Oh, you're very welcome. So, how people could find you? What are you doing now? If you want to introduce. Oh heavens! Um. Uh. My website is cleancoder.com, so that's easy to find. And by the way, that list of books is on there. And you can find out where I'm going to be and what you know where I'm going to be speaking. Almost all of that is virtual nowadays. So my videos are sold on CleanCoders.com. So same name except plural. CleanCoders.com and and that's a set of over seventy, eighty
[36:39] videos now that. That cover the gamut from clean code to design patterns to functional programming to object-oriented everything, right? Just, and I keep on adding another video once every month or two. You can get my email is Uncle Bob Martin, Uncle Bob at CleanCoder dot com. My Twitter handle is at Uncle Bob Martin. Um, I think those are probably about everything you need if you want to get. Yeah, definitely the Twitter. You're really active over there. Is your email person this Uncle Bob at cleancoder.com, cleancoders.com? Right? Is that also public? Either of those works. That doesn't public because I I I have some difficulty to really locate your email address. That's why Mark Siemens introduced. It is public. A lot of people know it. Of course, my email is is a mess because a lot of people know it. So, if you write me an email, it may be a while before I see it. I got it. Yeah, scroll up and down this long list of read. All right, thanks a lot, Uncle Bob. It was really great, great pleasure. You know, talk to you. Well, thank you. I appreciate. Okay, bye bye. Bye bye.
[37:58] Hi, I'm constantly looking for good guests. If you have any guest recommendation, please reach me out. I'll make sure they're joining to the show to share their knowledge. Otherwise, thanks for listening to the show. I'll see you next Thursday.
