[00:00:05] SY: (Music) Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today, we’re talking to Dave Thomas and Andy Hunt, the authors of the prolific book on coding, The Pragmatic Programmer.

[00:00:18] DT: Well, yeah, that’s kind of my entire point is to sow seeds of dissent among the young.

[00:00:23] AH: You know, a lot of this stuff is medicine. Three drops will cure you, but if you chug the whole bottle, you’re going to die.

[00:00:30] SY: The book is now being reissued for its 20th anniversary and we dive into the book’s impact, what’s changed in the new edition, and what remains the same, along with things they’ve learned over the past 20 years after this.

[00:00:49] Thank you so much for being here.

[00:00:50] AH: Well, thank you for having us.

[00:00:51] DT: Totally our pleasure.

[00:00:52] SY: So let’s start with some personal background. Dave, let’s start with you. Tell me a bit about what you’re up to and a little bit more about your coding background.

[00:00:59] DT: I started coding on an ASR 33 teletype in 1970 something writing in basic. I did it because I had run out of things to do at the end of a term at school. And so they sent me a cross the road to participate in a kind of experiment on teaching programming and I just fell in love. At that point, I changed my ideas for where I want to go to college and what I wanted to do at college. And basically, I’ve been programming ever since. What I’m doing now is I kind of semi retired from the bookshelf. I’ve got a lot more time to play, which is both a blessing and a curse. Blessing as I got more time to play and the curse is I keep doing too many things and not actually getting anything done.

[00:01:49] SY: You’re also a professor, right?

[00:01:51] DT: I’m an adjunct professor down at Southern Methodist in Dallas. At the time, it was one of the only graduate level course in Elixir. It is really interesting. It’s interesting to watch, I mean, universities still teach people some pretty boring languages, you know, in C++, in Java, or in JavaScript and wherever else. And it’s really interesting watching people for like the first couple of weeks totally struggling, and then suddenly when they get it, they just explode into this kind of productivity that they never had before. It’s wild.

[00:02:29] SY: Yeah. The times when you struggle can be very uncomfortable, but once you get it, it feels so wonderful.

[00:02:34] DT: Yeah. And a lot of them now complain about having to go back to the C++ and the Java.

[00:02:38] SY: They got spoiled. That’s what it was.

[00:02:39] DT: Well, yeah, that’s kind of my entire point is to sow seeds of dissent among the young.

[00:02:46] SY: You sound like a great professor. So Andy, what about you? Tell me about your coding background?

[00:02:50] AH: Well, so when I started programming, it was a little bit later. We did not have dinosaurs grazing at the window quite as much. We were still chiseling on stone tablets though.

So it was, you know, a little primitive. I did my first commercial program roundabout 1982 and a little, I guess, a couple of years before that, I was trolling through a radio shack back when they had such things and they had this little book on the sort of “Coming Microprocessor Revolution”. And I’m reading this as an impressionable kid going, “This is really cool stuff. I could make a living out of this. This sounds really interesting.” So I started, I think my first language was 6502 assembler followed closely by whatever flavor of C basic or such that was around. So I started off with there. I’ve worked for some Fortune 100 sort of companies, small startups. More recently besides running the bookshelf, I’ve written a couple science fiction books. I regularly play in local bands. I record some music. I just start, again, re-giving workshops for people of how to get better at programming both individually and as an organization, what you can do to sort of learn and improve your skills.

[00:04:06] SY: So we are here to talk about The Pragmatic Programmer, which is a book you all wrote 20 years ago. Congrats on the 20-year anniversary.

[00:04:13] AH Thank you.

[00:04:14] SY: So let’s start at the original Pragmatic Programmer. What was the impetus for you all getting together to write that book?

[00:04:21] AH: Dave and I were off consulting at the time and this mutual friend that we knew got us together on this project. And it was one of these sort of impossible projects that there was not nearly enough time and there’s no way it could be done. So our friend called the two people that he trusted to get this done. He called Dave and myself. And that was the first time we met. So we met on this project and realized that we had very similar the same ideas of, “This is how software should be done. These are the things that you should do. These are the right things. These are the common pitfalls you should avoid.” So we started doing some consulting together and we realized after some number of clients that it was all the same. People were making the same mistakes over and over again and we were telling the same little stories and trying to get them to do the same kind of thing. So we thought, “Okay, just to save ourselves a little bit of time and effort, we’ll write a little white paper. Throw down some thoughts or some simple principles, some of the basics from computer science that maybe people had not been exposed to or had forgotten, some of the things that we’d encountered in our experience that were sort of common and a better way to do things.” And it was just going to be a little white paper to give our clients. And unlike every software project ever, it grew in scope a little bit and it became The Pragmatic Programmer Book.

[00:05:49] SY: How long was that initial white paper?

[00:05:51] DT: We got to about 120 pages if I remember rightly.

[00:05:54] SY: Wow!

[00:05:55] DT: One of our wives, I think was actually mine, suggested, “You know, this should be a book.” We had no experience or confidence to be honest with you in that. So we thought, “Okay, how can we get some advice on turning this random collection of words into a book?” And so we hatched this really devious master plan that we would send a rough hundred pages off to the best publisher in the kind of computer area that we knew. And they would reject it. But when they rejected it, they give us a really nice letter saying what was wrong with it and then we’d be able to use that to fix it.

[00:06:31] SY: Oh, that’s nice.

[00:06:33] DT: Yeah. Well, the evil publishing company ruined the entire plan because it didn’t reject the book. And so it kind of ended up, that we ended up with a contract to actually write the full book. That was starting in the end of ’97. It took about two years.

[00:06:51] SY: Were you surprised that it ended up being so long when you thought about, “Oh, I’ll just put together our thoughts on a white paper, put it into a white paper, and then we’ll see how it goes,” then you ended up with over 300 pages with that?

[00:07:01] DT: No. Actually, the opposite. I was pleasantly surprised it was so short. I mean, with both of us, you put a nickel in and we can talk all day. And one of the things with The Pragmatic Programmer that was very, very difficult for both of us I think was to limit what we said.

[00:07:19] AH: That’s actually, I think that’s part of its secret sauce, kind of the secret to its success because we had, I don’t know, some number of tips and chapters and things that we kind of toyed with, “Yeah, let’s put this in. Yeah, let’s think about this.” And had to decide, “No,” and really distill it down. So instead of laboring on, on any one of these points, we try to get down to a really pithy little sound bite almost, like a tip. So we have these tips scattered throughout to help you remember them, but also to condense as much as we could into a very concise sort of explanation.

[00:07:59] DT: My personal kind of target was that we wouldn’t write any section that you couldn’t read during a bathroom break.

[00:08:07] SY: Okay. So I want to talk about what actually made it into the book. What are some key parts, maybe some parts that you’re most proud of?

[00:08:13] DT: Well, there’s a few things we did which actually have kind of like become industry standard terms, which is kind of like shocks me to this day. You’ll see people all over the web talking about dry, which is a don’t-repeat-yourself tip, which is probably also the most misunderstood tip in the original book. So it’s kind of unfortunate, but that kind of fills me with some pride. There’s quite a few things like that where people like orthogonality, which we did invent the term, but I think we popularized it.

[00:08:46] SY: And what does that term mean?

[00:08:47] AH: Two directions are orthogonal is if you move along one of them, you’re not changing your position on the other one. So if you think about like an X, Y graph, if you walk along the X-axis, you’re staying at the same location on the Y-axis or if you walk anywhere parallel to the X-axis, right? So the idea there is that you want to write software where the components are orthogonal. So that if you make changes to one, you’re not going to break everything else.

[00:09:17] SY: Sounds like a really important principle.

[00:09:19] AH: I think it is. All of our principles of design is kind of interesting because back when we wrote the original, we hadn’t really expressed it all in words before. And so it’s only when we came back to read it the second time around and realized that most of our design points all come back to this idea of making software easy to change and orthogonality is definitely one of the key concepts.

[00:09:46] AH: One of the other terms we came up with was the idea of programming by coincidence, which again people will bandy about like, “Oh, you’re a programmer by coincidence,” or, “Oh, no, I caught myself programming by coincidence.” And that was just something we made up to try to explain that idea where you hack some code together and it kind of works, but you don’t know why and then it breaks and you don’t know why either because you don’t know how it worked in the first place. So yeah, there were quite a number of things like that. And again, from our early days of consulting and telling the little stories and the little anecdotes, there’s quite a few of those have made it into the sort of popular consciousness. In fact, there was a really funny tweet the other day when we were talking about the new edition coming out. There’s a story in the original about Stone Soup & Boiled Frogs. And the boiled frog part of that is talking about situational awareness, where you can become very inured, very blinded to slow changes in your environment like the apocryphal story. If you take a cold pan of water and put a frog in it and turn it up slowly, the frog won’t notice and will get boiled. But if you throw a frog in boiling water, it jumps right out. I have no idea if that’s true and we are very careful to note in the book we have not tried this empirically, just to know. So someone on the other day on Twitter said, “Oh, the second edition is out. I can’t wait to see if the frog makes it this time.” That actually really warm my heart because so many computer science texts or programming books out there, so many presentations and conferences are so dead, dull, serious, and boring that you’re sitting there reading it and literally you’d rather gnaw your arm off then finish it. And so we made a real point to inject a little bit… you know, it’s not a comedy book. It’s not humorous, but there’s a fair bit of snark, a little bit of sarcasm here and there just because this should be fun.

[00:11:57] SY: What were you hoping that people would get out of it? You mentioned that you wrote it as a result of your consulting work and having to say a lot of the same things over and over again. What were you hoping would happen once you publish the book?

[00:12:07] DT: So we had no idea what was going to happen. I mean, we’ve never done this before. To be honest with you, I still have no idea why it took off the way it did, but it did take off and it became apparent pretty quickly. We actually hit number, I think it was at the seven or nine, I can’t remember, on the Amazon all book list.

[00:12:30] SY: Wow! That’s pretty good, especially for your first book.

[00:12:33] DT: Yeah. But I think what I was personally hoping for but for two things. First of all, I learned a lot in the process of actually thinking about the stuff in the book. And so that was really satisfying just having worked it all out in my own head. I was personally hoping that what we would do is I guess empower people, which sounds a little bit kind of new age-y. But what I was hoping would happen is that people would get the confidence to make their own decisions and not just receive wisdom from other people. We try to talk to people about how it was their responsibility and how it was up to them to learn this stuff and up to them to do what they think they should do. And in fact, we’ve actually amplified that quite a bit in the second edition.

[00:13:21] AH: In addition to that, we really tried to push the idea of continuous learning and figuring stuff out, right? So if we used a word or explained some concept that you hadn’t seen before or weren’t familiar with, the idea is you’re going to go off and look that up. Back when we wrote the book, it’s like, “Oh, you’d go search for this on AltaVista,” the what? The Google of its day, you know, and whatever it’s going to be 20 years from now, but you’d go find it somewhere. A lot of the tips and a lot of the things had these little teasers almost, little dangly bits of, “Here’s this interesting thing maybe you haven’t heard of before,” or, “Here’s this reference to classic literature or something that’s maybe uncommon.” What was the definition of the word deadline? What was its etymology? Where did that come from? It’s actually kind of interesting. So we’d have these little tidbity things just to help kind of foster the sense of curiosity, which I think is really one of the most critical aspects of being a good developer is to be curious about everything, like, “Oh, I didn’t know that. That’s cool. Let me find out more about that. Let me go dig into that a little bit.” Not obsessively but just, “Well, that’s kind of neat. Let me take a look at that,” or, “I hadn’t heard of this technique or that language or that approach or whatever.”

[00:14:41] SY: What was the response? Did you get some cool stories from folks who said that the book helped them?

[00:14:46] AH: Oh, for 20 years straight.

[00:14:50] DT: We’ve actually had quite a few people. There’s this thing, I get it quite often and every time I hear it my heart kind of stops a little bit where people would say, “I read your book,” or, “I saw you talk and I quit my job.”

[00:15:05] SY: That’s a little scary.

[00:15:07] AH: That could go either way, really.

[00:15:08] SY: Yeah. I don’t know how to feel right now. Yeah.

[00:15:11] DT: Yeah. If they did say, “I took up the priesthood,” then I know I’ve done something wrong. But most of them would be like, “You know, I read that and it said that I’m responsible for my own life and you’re right. So I’ve quit this boring job and I’ve gone and done something interesting.” For me, that’s really rewarding.

[00:15:48] SY: Why re-release the book now? Because I know it’s tied to the 20th anniversary, but you could have done a 10th year anniversary, you could have done a 15th year anniversary. So what’s special about now?

[00:15:58] AH: Well, it’s 2020, and it’s the 20th anniversary. It’s like, “Oh, that’s a…”

[00:16:02] DT: Good. Good. I like that, Andy. Good thinking on the spot there.

[00:16:05] SY: It is meant to be.

[00:16:06] AH: You know? Right? Right? It’s 20s all the way down. Yeah.

[00:16:09] DT: Yeah. Yeah. That’s what he said. It must be what he said.

[00:16:13] SY: Yeah.

[00:16:14] DT: I think to be honest with you, a lot of what happened in the intervening 20 years was a kind of very slow information gathering process. We wrote the book and then we kind of lived it for 20 years. And during that time, I think we both absorbed feedback on stuff that was good, stuff that was bad, and we also tried explaining ideas in a book to people. We did workshops. We have conference talks or just over a beer somewhere. We got to the point where I think we both happen to have enough confidence that we would be able to make worthwhile changes. I think 10 years ago, nah. You know, I think we were still in that gathering phase. I’m a very big believer in waiting until your brain says, “Yeah, it’s okay.” And for me, I was just waiting for that moment.

[00:17:05] AH: Well, and also kind of interesting and remarkable considering kind of our different, you know, where we’ve been in the last couple years has been pretty different, we both started off with a list of, “All right, what are the sort of new things we want to cover? What are the important things that have changed that we sort of want to talk about?” And we came up with separate lists and then compared Them and they were, what, 80 percent the same.

[00:17:28] DT: Yeah.

[00:17:29] AH: It was like, “Oh, okay.”

[00:17:31] SY: That’s great.

[00:17:31] AH: So we’re kind of on the same page there, which was a good sign. It’s like, “Okay. Well, you know, neither one of us is completely off in the weeds or we both are. It could go either way really.” Again, it was one of those good feelings, like we might be onto something here because we’re in agreement. We’re heading in the same direction here.

[00:17:49] SY: What are some things that are different about this edition? I know you said that there are 20 years’ worth of lessons learned that you’re now incorporating into this. What are some of those things?

[00:17:59] AH: There’s a lot of little changes obviously because all the tips had examples using the technology of the time or the fashions of the time. And when you go back and read something about CORBA and RMI, it’s like, “What?” Or Eiffel is a language. It’s like, “Wow!” No one knows these things. So at one level, there was that sort of stuff that needed to be updated and refreshed to more modern sensibilities and things that have become popular that we had advocated back then like unit testing and automated deployment and that sort of thing. But I thought one of the more interesting bits when we wrote the book, it was ’97, ’98, that was before the agile movement started. And as you recall, Dave and I were two of the gang that wrote the agile manifesto and sort of kicked off the agile movement. And it’s interesting to see a lot of the things in the original book that sort of predated that and you’ll certainly pointed toward that and led the way toward it, but it wasn’t really that yet. We had to make some pretty good changes towards the end of the book to sort of come up to date with more modern sensibilities tying a knot in what we had started maybe back then, but here’s what it is now.

[00:19:21] DT: Well, partly that, but also partly in those 20 years, the ideas behind the manifesto have been mutated.

[00:19:30] AH: Some would say corrupted.

[00:19:32] DT: Well, okay. Yeah. And so one of the things that we try to do in this new edition is to get back to the basics there. And so there’s a brand new section which is the essence of agility, various observations that things like you cannot buy an agile project management system off the shelf and why and then what you do about it and how you handle that. And he’s right. There were a lot of small changes, but there were also some pretty massive changes. This probably I would guess maybe 20 to 30 brand new sessions, partly because technology changed, so there’s a whole bunch on concurrency, partly because the world changed. So there’s actually new sections at the beginning and the end about personal responsibility and personal ethics and how to judge whether what you’re doing is, uppercase G, “Good” or bad in this kind of more complicated world. And we also, the original example was not intentionally a piece of patriarchal, sexist crap, but most educational came in there and this kind of stuff. So that we went through the edge. In fact, we actually have to change the subtitle of the book because the subtitle of the book was from journeyman to master. Now both are perfectly good words. However, there could be some debate about that. So that changed.

[00:21:02] AH: You know, again, these are the things that have changed over the last 20 years. We had nothing in the original book about security because security and programming really wasn’t an issue back then. Maybe it was and we didn’t know it, but it certainly not like today’s game. We added a whole tip on that, but there was a lot of little bits here and there where maybe we advocated some common practice or didn’t mention something where it’s like, “Oh, no, you wouldn’t do that in today’s world because it’s not the same anymore and you’ve got to be careful out there.”

[00:21:38] DT: That led to my favorite tip in the new book where we’re talking about ethics and the fact that as programmers we are blessed and cursed with the fact that we are creating the new world. The world is now formed largely in code and that’s incredible responsibility and obviously it’s being misused. So my favorite tip in the in the new book is a kind of a warning about that and it’s simply if you enable a scumbag, you are a scumbag.

[00:22:10] SY: Oh, I like that. I also like this idea of personal responsibility because I don’t think we talked enough about ethics when it comes to coding and our job as coders. I think we get so wrapped up in the code itself when we get so excited about what we’re building that we don’t always stop to think, “Should I build this and what are the ramifications of me building this and who’s going to use it and how they’re going to use it?” I think there are a lot of questions that we just don’t stop to ask ourselves.

[00:22:37] DT: You know what? In the old days, the code that we wrote, by and large, was pretty boring. It was code that was like online stores and this kind of stuff, right? But as we move towards a world where your toaster has a processor in it, the code that we’re writing nowadays is life or death. If our code misbehaves or if we leave security holes open another people can appropriate devices, we could literally kill people with our code.

[00:23:08] AH: And then we’re really not prepared for that.

[00:23:11] DT: We don’t talk about it. I’ve never heard anybody talk about that.

[00:23:13] AH: We’re really not equipped to deal with the hard questions like that. I mean, we still have long debates on how to name things.

[00:23:21] SY: Yeah.

[00:23:22] AH: We have a tip about that, right? Because it’s hard. And all of a sudden to go from, “Gee, what should we call this to I have become the destroyer of worlds,” I mean it’s a bit of a jump there, but that’s what we’re up against.

[00:23:38] SY: Yeah.

[00:23:38] AH: Even in the first book we said, “This is a hard thing that we’re trying to do. Software development, programming, it’s hard. It’s probably one of the hardest things you could do.

[00:23:50] DT: But it was hard back then because it was technical. Now it’s still technical but also its ethical as well.

[00:23:55] AH: Well, it’s everything. The side effects of the globally interconnected society is you’re not just writing code. You’re effectively writing the de facto part of some law, some social interaction, some social hierarchy. I mean, it’s like it’s tied into everything and that’s really a remarkable opportunity and certainly quite daunting.

[00:24:21] DT: I bet you the guys who wrote Twitter never thought that they could actually topple a regime.

[00:24:27] SY: Yeah. That’s big.

[00:24:28] DT: And I bet they also never thought that they could drive people to suicide.

[00:24:32] SY: Absolutely.

[00:24:33] AH: And yet, there you are.

[00:24:35] SY: So when it comes to ethics, what does the book say? How do you deal with these ethical dilemmas?

[00:24:41] DT: The book itself has a couple of sessions. First of all, at the beginning, it says, “You are responsible for what you do.” Not just in terms of the actual code you write, but also in terms of the path that you take through life. You do not allow your employer or society or anybody else to dictate a path for you because you only get the one chance. Take control of it. And so the whole book is written with that kind of assumption that the people reading it are responsible and actively involved in their own lives. So then at the end we talked about the ethics of it and we talked about the fact that we are creating the world. I mean, there’s no pat answer to how to deal with that. I mean, we don’t have a framework for that kind of discussion. But as a start, we said that whenever you do something, you should ask yourself two questions about every piece of code that you write. The first question is, “Have I done everything I can possibly think of to protect the user?” And that’s an interesting question because when you think about that in the kind of bigger context, you suddenly start seeing all kinds of ways that your code interacts with the physical world. Code that would seem to be pretty benign suddenly starts taking on a bigger context. And then the second question is kind of in a way related. It’s also kind of like the Golden Rule. If I finish this software, would I be comfortable using it?

[00:26:12] SY: Oh, I like that. Yeah. So what are some things that stayed the same in this book? What are some parts that were not changed?

[00:26:19] AH: So the technology obviously changed, but what hasn’t changed for hundreds, thousands of years is people. It’s still us. We still have the same cognitive biases. We still have the same problems learning. We have the same issues working with each other, working in groups, all the sort of ironically named soft skills because they’re not soft skills. They’re hard.

[00:26:44] SY: Yeah. They’re pretty tough.

[00:26:45] AH: They’re difficult and they’re absolutely necessary. You cannot succeed in development or in any kind of organization if you take the position of, “Well, I’m just going to be technical. I’m just going to learn this one language or framework really well and I’m just a coder and I don’t want to talk to people or work with people.” You can’t do that. It’s not how the world works. You’ve got to deal with these pesky humans such as they are. So really a lot of the philosophical tips and the sort of approaches that kind of dealt with teams and people issues, you know, anything along those lines pretty much stayed word for word because that hasn’t changed.

[00:27:26] DT: A lot of the other changes that were large changes, the idea is still the same. We just found maybe better or at least different ways of expressing it. So for example, we always talk about DRY, Don’t Repeat Yourself, and over the years, people have kind of come to misunderstand that to say, “Don’t cut and paste code.” So we rewrote that section just to try to explain a bit better what we actually meant by that.

[00:27:53] SY: What were other things that confuse people or needed clarification in this edition?

[00:27:58] DT: One other section I think that we’ve clarified a lot, the whole, what is called Bend or Break, which is about flexibility is a chapter with like five or six topics in it. And fundamental to that is this idea of change and we talk a lot about decoupling and how to deal with data structures in such a way that works and makes it easy to change code, et cetera, et cetera, et cetera. It’s not new concepts from the first edition, but it’s totally rewritten. Because over the period of 20 years, I think we come up with some better ways of expressing what we try to do. So I don’t know. I guarantee you that there will be a whole bunch of stuff that we could have done better in this book as well and maybe we’ll do a 40th edition, if nurse lets me.

[00:28:48] AH: In that section Dave was just talking about it in the in the Bend or Break Section. In the original version of the book, we had a whole section we called Meta Programming where we talked about the idea of moving configurable things out of the code base and just putting them in configuration data somewhere, in a database, a config file, something like that, which is a reasonable approach to take and we describe it slightly differently in the new one. But some number of years after the book came out, we were out consulting at some group and they had taken that advice to an extreme level. So they had something like 44,000 configuration variables for their application and it was killing them because to add any little thing to their app was now like a six-month process because you had to add it to the UI, you had to add the database, you had to put an admin screen in it for it. It became a very big deal. And we actually mentioned that in the book now. It’s like, you know, a lot of this stuff is medicine. Three drops will cure you, but if you chug the whole bottle, you’re going to die.

[00:30:02] SY: Coming up next, Dave and Andy talk about their favorite parts of the new edition of The Pragmatic Programmer and what kind of impact they hope it might have after this.

[00:30:20] SY: So I’m wondering what are your favorite parts of the book, the new book?

[00:30:25] AH: The end, finishing it.

[00:30:26] DT: No. No. So I personally like the very first and very last tips, the “you’re responsible and you have to be ethical” tips. Then there’s a whole bunch of new stuff that I really quite like. Andy has a really cool tip called, “Don’t outrun your headlights.”

[00:30:46] SY: What does that mean?

[00:30:48] AH: So the general idea is that as human beings, as a species, we suck at making predictions, but we don’t know that. We think that we’re really good at it. If you look at most of the sort of endemic failures in software, it’s some variation on you took too big a chunk. He tried to do too much at once. So this idea of trying to take small steps always. Take a small step and get feedback and act on it, use unit tests. All these kinds of ideas are trying to take small steps and get feedback because if you don’t, it’s like the thing in the car where you can literally outrun your headlights. In other words, you’re going fast enough that you’re on a curve that you don’t illuminate where you’re headed in time enough to actually react to it and you go flying off the curve. Again, probably not the best metaphor, but it’s visual. It’s visceral, trying not to look too far ahead because that’s what gets us into trouble whether it’s estimates or just trying to think, “Well, how can I make this maintainable five years from now?” You can’t. You have no idea what the world’s going to be like five years from now and whatever you guess you’re going to be wrong. So that’s sort of it. It’s kind of the wrong path to go down to say, “What can I do to make this maintainable?” I think it’s better to say, “Well, what can I do to make it replaceable?” And admit, “I don’t know what the landscape is going to look like this many years from now.” S I very much like the idea of trying to tell people to avoid fortune-telling.

[00:32:28] SY: Yeah. So I’m wondering for folks who are new to coding, new to programming, maybe haven’t started coding quite yet, people who are non-programmers, what do you feel like they can get from this book or is this a book that you’d recommend to folks who haven’t quite gotten started yet?

[00:32:43] AH: Surprisingly, we’ve gotten a lot of comments and a lot of feedback from people who aren’t developers, who aren’t coders who have gotten quite a lot out of it. In fact, one of our employees at the bookshelf who runs all the production who is not a coder read through it and said, “You know, this kind of makes me want to.”

[00:33:04] SY: Neat!

[00:33:05] AH: So yeah. It can certainly be inspirational.

[00:33:08] DT: It doesn’t actually have to be coding either because I would say that… I don’t know, just the top of my head 80 percent of the tips, even the ones with code in them are actually applicable outside the area of code. You just have to kind of like change all the occurrences of programming language into scripting or something, like writing a script or just some other activity because fundamentally what we’re talking about throughout the whole book is mechanisms for gathering feedback, making sure you’re on track, how do you communicate with other people, how to communicate with yourself, how do you solve problems. I guess we could probably take the book and take out all the programming stuff and add a few cartoons and turn it into one of those airport self-help books.

[00:33:52] AH: An airport book. Yeah.

[00:33:56] SY: So with this re-release, what are you hoping happens? What kind of results, what kind of impact are you hoping comes from this book?

[00:34:03] AH: I think I’m certainly hoping that it puts it into a place where it can continue to be helpful to people because certainly I think one of the concerns was as the years go by and it gets further and further out of date and harder for people to understand what we’re talking about because the examples don’t make any sense, you got people who’ve never seen a dial phone, a rotary phone for example. But these things persist in our language, right? So we say, “Roll down the car window or dial the phone.” There have been dials for a fair while now. But at some point, that kind of stuff falls away and then you just read it and it’s like reading a foreign language. It’s like, “I don’t understand this anymore.” So there is enough semantic drift over time that it would eventually not be helpful to anyone. So I’m certainly hoping that by bringing this up to date now this gives it at least another 20 years where people can read it and understand the lessons from it and it can be helpful to them. As they’ve told us previously, “This launched my career. This changed my career. I quit my job over this. I got the new job over this.” You know, I want them to keep having those experiences and still having this be useful to them.

[00:35:18] DT: I think I would hope among other things the book sparks discussion. I think that there are areas that are not necessarily technical that we really don’t talk about and I know a lot of people have like book clubs where they read the book. I’m really hoping that those discussions look at areas like ethics and responsibility as a very serious thing because I think in a way the last 20 years have been, the 20 years of agility, I hope in a way the next 20 is when we kind of grow up a bit and we start taking responsibility for what we’re doing. My biggest hope to be honest is that we didn’t screw it up. This is going to sound somewhat immodest, right? But when you write a book that’s so well-received, doing a second version [inaudible 00:36:13] the only place you can go is down. I would rather not go too far down. So it’s going to be interesting to see what happens.

[00:36:24] SY: I know people are very excited about it. I remember seeing the tweet I think from you Dave and seeing how many retweets it got and replies it got and people are very excited about this new release for sure.

[00:36:34] DT: Yeah.

[00:36:34] AH: Yeah.

[00:36:39] SY: Now at the end of every episode, we ask our guests to fill in the blanks of three very important questions. Are you two ready to fill in the blanks?

[00:36:47] DT: You go first, Andy.

[00:36:48] AH: All right. I’ll go first. What’s your favorite color? No.

[00:36:56] SY: Number one, worst advice I’ve ever received is?

[00:36:59] AH: I think the worst professional advice, I was young and dumb and it was my second, third job, something like that, and at the time, it was customary to go through a headhunter, and the headhunter found this position and I was I was waffling on it because it kind of looked good from a distance, but there were things that you couldn’t put your finger on but kind of getting a little red flag, a little, “I’m not so sure about that.” So I asked the guy as an earnest, young, impressionable lad, and he said, “Oh, it’s a good salary. I’d take it.” And I did. And it turned out that was not a good move. It was a disastrous position. The entire division from the VP and down got laid off within a year after I started. They closed the whole place down. And there were other horror stories, some of which have made it out into various anecdotes. But I did not trust that little inner Instinct that said, “You might want to look a little harder at this.” And I kind of took it at face value. So yeah, listen to your intuition kids.

[00:38:12] DT: Well, yeah, but the real moral of that story is hire Andrew Hunt and your company gets out of business.

[00:38:18] AH: Within a year, yeah.

[00:38:19] DT: Within a year.

[00:38:21] SY: Guaranteed. Dave, what about you?

[00:38:23] DT: I guess mine is actually kind of similar but different because we were in the hungry phase we took on every single project we could find. And so I got to play with so many different technologies and problem domains and everything because they said yes to everything. So that was great. And they grew and they grew and they got to a certain size. And I kind of got a bit, “Yeah.” I was kind of like, “I could do something different.” So I went and I left that company and I joined another one for a little while. And the original company said, “Hey, you know what? You’re getting to a certain age where people can’t be technical anymore and so we want you to come back as manager.” They made up some bogus position for me and I came back as a “manager” because I was too old to be technical. And I hated every minute of it. People who generalize and then give advice based on that generalization, always bad.

[00:39:23] SY: Number two, my first coding project was about?

[00:39:26] AH: My first professional paid for real coding project had to do with manufacturing and specifically inventory management. And that was significant because all of a sudden you get that real world shock, right? So you’re in the pristine elegance of your code where you get this much in, you get this much out. Everything balances. It’s all clean. It’s beautiful. It’s nice. And then you get to the real world where that little number in your program doesn’t match what’s in the warehouse. Why? Well, a dozen reasons. Shrinkage, they call it. Somebody made off with it. Somebody counted wrong. Somebody put it in the wrong bin. Somebody called it the wrong thing. It’s in the wrong warehouse All the sort of human error that would creep in and suddenly your very pristine pluses and minuses and math don’t matter because that’s not the real world. So yeah, that was an early experience of the differences between the world as we would like it to be from the view of our code versus sometimes ugly realities that are out there.

[00:40:40] SY: Dave, what about you?

[00:40:42] DT: My very first big programming job was in basic. It wasn’t actually a paid job. It was a project. We were using a mainframe computer to run our code and each person was given a total of five files so they could store on this computer. And that was clearly not enough. So I wrote, “This is right, so many scary words in this one phrase, a self-modifying basic program, it’s actually stored files inside its own source code.” So that was like the first program…

[00:41:14] AH: It later became [inaudible 00:41:15] and it’s now his third child, but yeah.

[00:41:18] DT: That’s right. That’s right.

[00:41:21] SY: Number three, one thing I wish I knew when I first started to code is?

[00:41:26] AH: I kind of wish in hindsight that something had been popular at the time that would have been maybe turbo Lisp for instance, something that would expose you to higher level constructs earlier. And I think that’s still kind of a bit of a problem if you look at curricula and how we teach programming. I’m not convinced we’re doing it particularly well. I think this might be true of a lot of Industries. You kind of mirror how the industry progressed. Well, you start with this then you add that then you add this other thing. It’s like, well, that’s how we got here. That’s not necessarily the best place to start these days. So I definitely wish when I started off that I had been exposed to higher level concepts sort of earlier on or maybe even first and then from there going down and learned more of the basics of how that magic came to be.

[00:42:21] DT: When I first started out, I was a bit of a tumbleweed and that I would go whatever way the wind was blowing. And I had a blast doing it. Like I said, in that first company, I was coding so many different things in so many different systems and it was just really, really good fun. It was exciting. There was also a bit of a rush and I was kind of getting rewarded by all the short-term hits of, “Hey, look that worked,” and I was going to do something totally different over here. And as a result, I kind of never really sat down and thought about, “What do I want to do? I just did it.” I don’t know what that would change. I know there’s a few decisions I made that would definitely have changed had I verbalize the kind of things that I wanted to do and knowing that you would never actually do them necessarily. I mean, I would never have said, “Hey, I want to write a book,” but the idea of at least taking some control early on I think would have been beneficial.

[00:43:22] SY: Well, thank you both so much for being on the show and talking about your book and your re-release. I hope it goes really well.

[00:43:28] AH: Thank you so much for having us. I mean, we love getting out and talking about this and try to explain where we came from and why we think this is important and why people like it. I hope they keep liking it.

[00:43:43] DT: Thank you too.

[00:43:51] SY: This episode was edited and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.