bandwidth for change log is provided by fastly learn more at fasted.com. We move fast and fix things here at change law because a roll bar check them out at rollbar.com. And we're hosted on Linode Cloud servers had a Linode.com slash change log. This episode is brought to you by Linode, our cloud server of choice. It is so easy to get started with Linode servers started just five bucks a month. We host change log on Linode cloud servers.
We love it. We get great 24 seven support, zoos like powers with native SSDs, a super fast 40 gigabit per second network and incredibly fast CPUs for processing. And we trust little because they keep it fast. They keep it simple. Check them out at Linode.com slash change log. From change log media, this is the change log of podcasts, featuring hackers, the leaders, and the innovators of software development. I'm Adam Stukovianc editor and chief here at change log.
Today, Jared and I are talking with Dave Thomas and Andy Hunt, the authors of the pragmatic programmer. This is a beloved book to software developers all over the world and it's celebrating its 20th anniversary edition this year. So we wanted to catch up with Andy and Dave to talk about how this book came to be. Some of the wisdom shared in its contents as well as the impact it's had on the world software.
Also, just a few minutes ago, I got an email from pragmatic bookstore letting me know that the beta book is now fully content complete and is going to production. So if you decide to pick up a new book, you'll get a coupon for 50% off the hardcover when it comes out later this fall. So we have quite a treat today. We're joined by both of the pragmatic programmers Andy Hunt and Dave Thomas. Guys, thanks so much for sitting down and talking with us. Thanks for having us.
So we're here to celebrate. We're here to talk about a brand new edition of the classic the pragmatic programmer. First edition 20 years ago, October 1999, the new edition out in beta in ebook format now printing and hardcover later this year. Your journey to mastery 20 years later, most technology books, their half-life is very short. In fact, they're kind of some of the most perishable goods, write a book on technology and you'll be editing it nonstop. But took you 20 years for a second
edition. How is this books to test the time? First, I'd say the pragmatic programmer is probably not really a book on technology per se. If I had to say what it was, it's a book on people. And it's, people haven't changed that much. Expectations have changed, but the actual way people do things, I mean, that's really hasn't changed for thousands of years. It was just as bad now as we were then. That's just the way it is. The content definitely has to be updated because we had examples
in there that make really no sense unless you're into software archaeology. So we definitely had to update a lot of the code and a lot of the references we made. But the biggest updates weren't because of the changes into technology. They were because of the changes in our experience. So that over the last 20 years, we've explained the content of the book many times over to different people. And as we've done that, we discovered better ways of explaining things.
We've also looked at the reaction to various parts of the book and discovered that we weren't really communicating as well as we thought we were some of the ideas that we had. So a classic one of that is dry, where dry has come to mean don't cut and paste. But the original don't repeat yourself was nothing to do with code. It was to do with knowledge. So we've had to go through and update that. And also in the time, there's been changes in the way that the industry works
so that we are doing far more in terms of cloud type stuff. Concurrency is now everybody's problem. And so we've had to address those new areas as well. You have to sort of go back and put yourself into what the world was like 20 years ago. Because certainly when we first took on this this latest adventure, it's like, oh, we'll just go through and we'll change a couple of the technological references and we'll beef up some of the things that we've had more experience with. But,
you know, it won't be that different. And you go back and you read it and then you start to remember, you know, your friends at the time, your clients at the time, what you were working on. And you really start to realize what a different world it was 20 years ago. You know, AOL was carpet bombing people with CDs trying to get you to dial up, you know, this sort of thing. I mean, we didn't have anything in there talking about security. I'll try to try to fight against bad actors because,
you know, at the time, it was sort of just a struggle to get your code to work. You didn't really have to worry specifically about it being attacked for the most part. And now that's kind of step one. A lot of things that we promoted and pushed were still very brand new at the time. So we were talking a lot about insisting that you do unit testing. And, you know, that's part of sort of the safety net
that holds you up. But at the time, that wasn't really widely accepted. It wasn't as widely practiced. So we had advice in there saying, you know, go off and build your own unit testing framework for your favorite language. So you'll have it available. Which look, I mean, it's kind of hilarious now. It's because now, no, do not do that. That's a terrible idea. It was a great idea then. But times have changed now. That's ubiquitous. It's everywhere. Don't reinvent the wheel. So, you know,
some things like that changed. I certainly think for the better where, you know, advice that we gave out, you know, things that we were pushing. We were promoting have become commonplace have become widely accepted. So that's kind of heartening on the one hand. And the other thing to remember is that back when this is first written, which is 98, 99, that was before the snowboard meeting that kicked off the agile movement from one of a better word. And we were part of that. But it hadn't
happened yet. And a lot of the vocabulary that has come to become common nowadays was formed by that movement. And so, you know, we've had the opportunity to simplify some explanations in light of the fact that stuff that we were talking about has no become commonplace as part of, you know, the various different agile ways of doing things. Well, speaking of commonplace, one of the things that was not really commonplace at the time of the original launch was even Google. It was just
barely out. And to be a programmer today, you know, Google's your best friend, right? You know, find the answer if you've hit a hit a wall. Even then when you wrote the book, Google was barely even in the, you know, we were using we were using altavista. I think a lot, you know, a couple of the other early players. And again, it's funny. If you go back and read the original, there's almost this sort of idea of breathless excitement about this, the internet, you know, with a capital I.
It's like, you can go, you can download all these languages. You can get the help online from people. There's these communities. It's the internet. And it's again, it's, it's really kind of like going back in time and reading some of this going, wow, you know, that, because that was brand new and exciting and interesting. And you know, that was ubiquitous. One of the exercises we had in a chapter on estimation was to calculate how long it would take to send, I can't believe it was like
10 megabytes over a 9600 board line. Oh, man. You know, I harder to answer now. I probably is. Yeah. First, first find the 9600 board line. Yeah. Exactly. So one of the things you say in the preface speaking to this, all the things that have changed, you say that if you take a developer of 1999 and drop them into a team today, they'd struggle in this strange new world. And that got me thinking, is there anything that you two struggle with in the strange new world? And if not, how have you
managed to keep up with the pace of change? Well, everything every day. I mean, it's, it's funny when I, in time I go out and give a conference talk, I always throw in a joke that, well, it's Wednesday, that means they've been 47 new JavaScript frameworks that came out this morning. And invariably, right, the whole crowd laughs nervously because that's not far off. You know, nervous laughter. The nervous laughter. Yeah. It's, you know, on the one hand, it's kind of a fire hose.
Just the amount of ideas and attempts and things people are trying and doing. So it's kind of cool that we have that level of experimentation going on and people trying to find new ways to express things in better ways to, to approach problem solving with, with different, you know, attitudes toward frameworks and, and approaches. But on the other hand, trying to keep up is difficult. I don't think
it's even just necessarily keeping up. I think that the actual rate of change people have become accustomed almost like adrenaline junkies, you know, to the rate of change and kind of want to see it. And as a result, what happens is that a lot of stuff gets developed, new frameworks, new libraries, new techniques. Never quite gets fully there, right. And as a result, you're constantly
dealing with stuff that's almost working or that almost integrates into other things. And what that means is as a developer, you're trying to do something which is difficult in the first place. You know, you're trying to basically build a watch from component parts. And now you're being asked to do it while riding on a surfboard. And that, yeah, I struggle with that a lot. I mean,
right now, for example, I teach a class on programming languages at the local university. And I've been putting together some material using peg pausers and generating interpreters and stuff like that. And I have been probably, I've probably wasted two or three days this last couple of weeks, switching back and forth between JavaScript and TypeScript. And I even had a little little go at OCaml until I could find some combination of things that would actually work with all
the various libraries that I wanted to work with. It was just ugly, you know. And my heart goes out to developers nowadays that you have to keep track of all that stuff. You know, in a way, I think the best thing we could do for the developing world right now, sorry, the world of developers right now would be to say, okay, stop. Everybody, you're right, stop them, Adness. Let's just sit and breathe for a while and write code using what we've got.
And then let's not come up with the next big alternative to, you know, react order. Kind of a feature freeze on all programming. The problem is that like I say, people love to think that they can do it better. I mean, I know I have that problem. And so they go out and they create something which is addressing the one particular niggle they had in something else and ignoring all of the other smart decisions
that went into that original thing. And then they release that as the solution to this problem. And then people adopt that and they discover it's missing other things. So then they go and they write their own version, which has those things. And it just, it goes on and on and on. And it never actually gets resolved. And I just feel that, you know, we are too willing to hope that there is a silver bullet out there. And I mean, it's what 40 years old, 50 years old, there are no silver bullets.
Isn't that the name of progress to some degree though? Like you almost have to sacrifice a bunch of bad decisions to make a good decision. Yeah, to a point. But once those bad decisions are actually stopping you going forward, then you're into the negative territory. So if we were to make bad decisions more slowly, then we'd be able to make more for quote, quote, progress. That's what I'm saying. Right. No, I'm all or experimenting. I'm just not, I'm just saying we don't always have
to be using the cutting edge of everything every time we write a piece of it. Again, it comes, it comes down to context. So a lot of the times boring is great. You know, there are some applications, some things out there. I want something. You know, the thing that's that's driving my, you know, my pacemaker, my MRI machine, whatever. I'd like that to be built with pretty boring tech. You know, something very stable, been around forever, no surprises. I do not want last Wednesday's
JavaScript framework, you know, involved in that. Unless it's a well view of stats or something. Right. Right. Right. Something non non critical, even that will probably crash on you. But yeah, you know, boring, boring has its place. And that's, you know, one of the things we, we kind of an underlying message we strive to talk about in the book a lot is this importance of context. So you can't say you should always use boring. I would love to say freeze the world. Don't make
any changes, but, but you really can't, but you can't say always use boring. You can't say always use cutting edge. I mean, it just it depends. It totally depends on the context. And that's something we tend to be a little tone deaf too. You know, we want to use the latest shiny because it's exciting and it's fun. And hey, let's use it on this project with this set of hapless users.
And, you know, they kind of never know what hit them. Yeah, one piece of advice that I've heard and I've tried and I think it, I think it has some legs is that when it comes time to pick tool or pick technologies for a particular task. And you want to have some sort of progress, but you don't want to go all in is let's say there's eight components that you need to pull in. Seven of them choose boring. Choose the one you've used before. It's a known quantity, et cetera. And then
mix in one thing that's shiny or new or different. And also it's kind of a control case for you to actually test that one thing versus I've just decided to pick seven new technologies and I don't know what I'm doing. Right. So sometimes a little bit of that just moderating the records goes long way. I say in in general, you know, you only want to change one thing at a time, right? If you're debugging, you're not going to go change, you know, five different lines of code,
swap in a new library and cross compile it to a different target. Well, let's see if the bugs there now, right? You have no idea what's going on. You know, if you do that sort of thing, you change one thing. See what happens. Right. When you teach kids to climb, you always say, you know, the rule of three, right? You know, you'll never move one hand one foot. And then now we've got three other things holding on. And I think it's the same with software. I practice that same
principle, getting out of the bathtub. Yeah, I saw that video. Yeah. It's surprisingly very good with bathtubs as well as climbing because a lot of people slip and fall and break something. And I don't want to be that person. There you go. Just speaking of this book in particular, this came from experiences, right? So you guys have been in the software business for a very long
time. This book actually came from your experiences that you, I assume, wanted to preach to other software developers to make them better software developers by way of the experiences you have with your clients. Yes, but I wouldn't say I try not to preach. We try not to preach. It was more a case of, you know, we were out there working in the trenches, working in the field, working
alongside with folks. And what both Dave and I noticed was that going from client to client, different company to different company, large to small, people were making the same classes of mistakes. They were doing the same things, you know, looking at the wrong end of the telescope and you know, suffering in the same ways. So the original idea was that we were just going to write a little white paper of the sort of the things that we'd observe. And it's like, you know,
it hurts less if you do it this way. You know, try to keep this, try to bear this in mind. But of course, you can't just, you can't just come out and tell people brush your teeth and eat your broccoli or, you know, that this kind of, you'll get plenty of extra. I usually do eat your broccoli and brush your teeth, which is out of order. But you can't just come out and tell people, well, you know, eat less and run more, you know, diet and exercise. You have to be a little more
circumspect about it. So we came up with this sort of set of little stories, anecdotes, metaphors, you know, ways we would explain things to people that would kind of help get it in there and help them understand, oh, okay, I see what you're talking about. It's not just, it's not just iterative and incremental. It's, oh, it's a traceable at all. I understand that or, you know, whatever it might be. So we had started just in talking to clients. We had started accumulating
these little stories, anecdotes, metaphors and so on. And we thought, well, this would be okay. We'll just write some of them down just to save us some time going into a new client. We can just give them this little brief and like, okay, well, start with this. And then by the time we get there,
we've got a more of a common vocabulary. We can talk about some of these issues better. And, you know, as unlike any software project ever, right, that little idea of a white paper grew into a larger project and that became the pragmatic programmer book. Maybe go a little deeper to then to the differences, I would say. So we're 20 years later. You're still in the software business. Not much have probably changed much about the two of you.
I'm as part of the question really. What are the differences in the last two decades? I mean, 20 years in software is like, I don't know, is it to be compared to the dog years? Is it time seven? What's the multiple there? But it's a lot. It's a big, it's a big lot. It's a big lot. What's changed in 20 years? Everything and nothing to be flip about it.
You know, and you know, Dave can certainly go and tell you something about the, I think there's a fundamental shift of attitudes of, you know, I was really struck when we came back and looked at the original Prague Prague at how object-oriented centric it was. Because if you'd asked me, I wouldn't have remembered that, oh yes, that was very much a kind of an O.O. style sort of a book. But it really was. Most of the architectural and design tips were kind of at least O.O.
flavored, if not overtly. This only works in an O.O. style system. So there was a lot of that. There are a lot of examples interest. I thought it was kind of interesting used iteration, used for loops. Because that was a convenient pedagogical technique to talk about invariance or this or that or whatever we were discussing. And you look at so that sort of thing now. It's like, well, people don't really do that anymore, right? You don't use a raw
for loop. You're using a list comprehension or an iterator or something. So there's definitely a lot of that. Attitudes and approaches that change moving stuff to the cloud. Big change. We would talk about the build machine sitting in the corner, which some people still have, bless their hearts. But that's that right there is a really big shift of having build machines that are just, you know, fungible resources off somewhere else. Spot instances on demand.
You can say that in one sentence and that's kind of a small change, but that really engenders a sea change of attitudes of how you approach deployment, how fast you can deploy, what your restrictions are. I mean, it really opens up a whole different world. I think it's funny that a man originally born in Connecticut was at New York, whatever, has been living in the south long enough that he can say, bless their hearts. It's a nice touch. I think the other thing that's changed is
like I said, people haven't changed, but people's sensibilities have. And I think that we have seen with the increasingly pervasive impact of computer technology on our lives, that the responsibility that's being put on developers to behave ethically has increased dramatically. So that in the old days, Europe code and it ran on a mainframe or maybe around on the PC or possibly even on a web server. But it would be kind of boring old code that did some business function. Now your writing code
that can change people's lives that can kill people if it goes wrong. And as a result, we need to think a lot harder about the impact of the code we write. And so we have tried throughout the book, both implicitly and explicitly, to tell people, you've got to be more conscious of what's happening to the code that you write. Right? Are you? I mean, at the end, we talk about, you know, don't enable scumbags. And I hope that doesn't get beeped. But it's true. You know, it is possible to write
software, which is used for some very, very bad things. And we want to be thinking about that, because we are really the community of software developers. We're in a position which is pretty unique. We can and we are changing the world. And the world that we create is largely up to us. I mean, yeah, people are going to tell us what they want. We have the power to say yes or no. And we need to be thinking very, very hard. Is the software that they want to need to write?
Going to harm other people. And if so, are you prepared to take that in on your conscience? This episode is brought to you by GoCD with native integrations for Kubernetes and a helm chart to quickly get started. GoCD is an easy choice for cloud native teams with GoCD running on Kubernetes to find your build workflow and let GoCD provision and scale build infrastructure on
the fly for you. GoCD installs as a Kubernetes native application, which allows for ease of operations, easily upgrade and maintain GoCD using helm, scale your build infrastructure elastically with a new elastic agent that uses Kubernetes conventions to dynamically scale GoCD agents. GoCD also has first class integration with Docker registries, easily compose, track and visualize deployments on Kubernetes. Learn more and get started at goCD.org slash Kubernetes again, goCD.org slash Kubernetes.
Did you just go work together or beyond just writing the book? Well, I mean, sort of is the answer. So Andy is still running a private bookshelf. I kind of retired into Gentile kind of whatever a year or so ago. So we interact. It's actually been quite fun doing this book as being an excuse to work together again for a while. And it's actually kind of nice after a break to go back and work with someone you worked with for a long time because you
can still use the shorthand. You don't worry about all of the kind of like day to day stuff that normally gets it in the way. Yeah. Yeah. Well, it was it was funny. When we first decided we should take a serious look at redoing this addition to the pragmatic programmer, we each went off and made a list of okay, to answer your question, what were the biggest changes over the last, you know, 20 years? What are the things we should address? What topics did we, you know,
felt we should drop, which one should we revisit a little stronger? And when we came back and compared our lists, they were 80% the same, 75, 80% the same. So we started off kind of definitely on the same page. So we talked about what changed the most. I was thinking about your book in terms of churn and in terms of diffs, right? Because you have the two versions, you could run a diffing tool against them and see what's changed, what's new. And maybe interestingly, what hasn't changed?
Like the most timeless of things that you wrote 20 years ago. What are those things that are that are still stand true as true today as they were when you first penned them 20 years ago? Yeah, we did actually write a different tool. It's not quite as easy as doing a get diff because we moved from using La Tech to using the mockdown on the second edition. But wrote a quick tool that basically did a, what is it called? Cosign whatever we
read comparison on a paragraph by paragraph basis to see what have changed. And the answer is about 75% of the paragraphs have changed. 75% as I always said? Yeah, 75% and by change I don't just mean you know, like a small typo fixer. That's a, well, it's kind of like enough wording has changed to reach the threshold of my diff. Gotcha. About 30% of the content, the tips, I'm sorry, are brand new. They weren't even in the original book. And probably at least half of the remaining
tips are being rewritten. So probably only about a third of the tips escaped with just a kind of light dusting. But the things that haven't changed really are the fundamental human things, communication, you know, working with people and trying to work out what they want and why that's not always easy. All those kind of things are, you know, I don't think we'll ever change until we get mind melding. So, you know, I think that's, that's, you know, it's a pretty easy to
predict actually which ones would change the most. And again, it's like, you know, you can go back to Fred book, Fred Brooks's book Mythical Man Month. And it's all talking about, you know, the IBM mainframes and, you know, languages and technologies we don't use anymore. But if you went through into the search and replace with some more modern tech stack, it would read as fresh today as it did, what was that 40 years ago? Because again, it's people problems and we haven't changed. So,
these are still the things that we're facing. But we have, we have this kind of, you know, day was talking before about this adrenaline junky aspect of our work where we want the shiny new thing. So, we have this kind of amnesia in the industry that, oh, well, surely we've solved all those people problems. We've got, we've got Jira, we've got agile techniques. We don't have people problems anymore and you just kind of skate over it. And it's like, no, it doesn't work that way.
You still have these issues and you still have to, you know, learn how to work around them and learn how to work with people and get things done. How do you feel about empathy in today's workplace? I feel like that's been in the last 20 years. That's the thing that separated most before we were far more co-located working together. And over the last 20 years, we've been separated more and more. And now we use things like Zoom or Skype or Slack or whatever might still be cool to communicate.
And the ability to have a face-to-face person-to-person interaction is lost. And therefore, it's hard to empathize. I think that's a really astute thing and it's not just in the workplace. If I look at my kids, I would say the majority of their interactions with their friends are online. Yeah, they see them sometimes. But most of the time, they'll be sitting there, you know, chatting with them online somehow. And yeah, I think that does actually impact
everybody's empathy, not just developers, but the entire world. As we move away from face-to-face and reading body language and basically just sitting quietly with people. I think, yeah, that definitely impacts the world. And that could be the reason we're seeing a more aggressive, apparent society than we have for a long time.
Hmm. Well, I look down your table of contents. You mentioned that a lot of the things you cover is people problems, but not a lot of the titles of these sections really describe what I might find as people problems. The thing there is that the symptom is not expressed as a people problem. But the cause is. So with many of the tips, if you actually go into them, what you'll
find is, yeah, we'll talk about, I mean, there's definitely very technical tips in there. But in a lot of them, we'll be talking about how, for example, the section on naming things actually talks about research that says about the idea that the names that you give things actually changes the way you think about them. That's a people problem, right? And, you know, the idea of naming is incredibly important. The idea of clarity, not just clarity when you're naming them,
but clarity that helps you think about things better. That's a people problem. It's all to do with, you know, various psychology and physiology and other kind of allergies that are to do with our failings as human beings or are many of us not very worried, not failings. Maybe our
ambiguities and our weaknesses. I'm still back on the amnesia bit myself. And Andy, I was just curious if you have thoughts on how we solve these problems because we do have this, we do have this issue in our industry where there's a lot of wheel reinvention, sometimes it's experimental, and you know, in the name of progress, but a lot of times it's making the same mistakes as people
that have gone before us. Obviously, you can write a book. That's one way you can pass on knowledge, but like, how else do we either institutionalize or community eyes, right, into our culture, the passing on of the knowledge from those who've come before us so that we stop making the same problems when we go out and make some different problems? Well, that's a really good question.
And I wish I had a glib answer to say, oh, just do XYZ, but it's kind of, I mean, it's sort of, you know, endemic to the way that we work that we kind of throw out the old code, throw out the old compiler, the old language, you know, no one's using turbo Pascal these days, I notice, you know,
that's been a few decades. You know, we have this such a constant drive to, you know, write code faster, provide more functionality, more quickly, use the new technology, follow the latest chips, the latest, whatever, there's such a pervasive drive for new, new, new, new, that people really aren't in the habit of digging through old memory management, um, theses and dissertations and seeing
what people came up with before that was useful. Sometimes they do and you'll see an article on, you know, hacker news or Reddit or something where somebody dug back and found some gem that had been overlooked, applied it into a modern context and wow, here's this new, cool thing, but it's not new,
you know, it goes back when, um, in quite a few places in the book, we, we, you know, point out that, you know, this idea came from Simula in 1967 or this idea came from, you know, this other place way back when, uh, we don't have a good sense of history and, you know, I like to lay blame for a
lot of our issues at the college university level that may or may not be fair, but that's where I put it, uh, because right, you know, it is rare to find a history of computing class that would teach you any of the, um, you know, the, how the ideas came to be and who worked on what? I don't think it's a separate class because I think it's, it's, okay, so what we do is we, we write software and just like poets and authors, we start with a blank page and we create something from it.
Now, if you want to become an author, I would suggest that one of the things that you do from like age four is you read, yeah, and you read and you read and that I think is incredibly important to the ability to write, you know, you, you see tricks, you see, you know, the more you read, the more you understand how people are organizing their thoughts and paper and everything else. Now, I'm not talking about developers reading books here, I'm doing my developers reading code
and trying to read a variety of code. So they go back and they look at, um, code written in different languages and try to work out, you know, how that works, why that works, why does it work the way it works? So I would like to see the idea of, um, teaching tied into this idea of, you know, learning how people
did things in the past reading their code and then discussing, okay, why did that happen? Give you a good example, why does C++ have the pre and post increment operators plus plus and minus minus? Right? Well, the reason, yeah, the reason and it's kind of weird, right? The fact you can write chr equals star CP plus plus, which takes a character point, it de-references it to return the character and then increments it by one. Right. Well, the reason is that the machines in Bell Labs,
there are PDPs and the PDP has seven different addressing modes. One, while two of them are pre and post increment addressed irreference. And so that maps directly onto the hardware. And it's like, oh, okay. So that's why it's there. Now that you then you can ask yourself, okay, is that something I really need to think about going forward? Do I need that online or
is it just a convenience that happened to be there? Same with go to considered harmful. You have to understand, I mean, people will quote go to considered harmful and entire languages have been written without go to based on the title of that paper. But the title of that paper actually wasn't the title of that paper. It was a letter written to CACM. The original title was something totally different and the editors changed it to go to considered harmful because it was like more sexy as
a title. Click BADY. That's the word you want. Yeah. And the actual context of go to considered harmful as a letter is actually to do with program proving. The fact that if you have a go to statement is really, really hard to write proofs of programs. And back then, the idea was that we should be able to mathematically prove our programs correct. There were people who spent their entire careers working on program proving. Now, we still have that in some very, very strict domains, like logic
design. But that is no longer relevant to us. And yet, we still carry around all of these things that we've received based on headlines go to considered harmful, most string-cerman. And don't really know why we do it. Here's one that I learned. Global's are evil. Global variables are evil. I learned that in college, but I never, I never, it's almost like it's a cargo cult. I never learned why. It was just like a maximum. It's just like this is totally true. You should read our book.
We have a whole section on that. But let me get back to that for a second talking about like the go to and these old, old letters and old articles and old addresses. We pick up sort of the wrong ones, right? We capitalized on go to considered harmful and made a thing out of that. But what about was it Dijkstra who had the the Turing Award lecture about the very humble programmer? That is a that is a critical piece of early literature. And you talk about things that haven't changed,
right? This was 1970, 72. Somebody can Google it while I'm rambling. And you know, he makes the very important point that complexity will overwhelm us if we don't take a very humble, very measured approach. And it's been 30, 40 years and everyone present company included has ignored this wonderful advice. Humility is difficult in our environment, in our in our culture. And it is probably of all the kind
of human, human, human, factorsy things that you need to be a good developer. I would submit that being humble, realizing you don't know all the answers that you need to find out that you need to experiment, get feedback, try it. You know, this part of our headlong Russian to the shiny new thing is this kind of faith that, well, that's going to be better. And I can do it better. And, you know, I'm better than this and that, well, yeah, maybe, but you should validate that. You should
try it. You should go back and read these things. You should try these other experiments. Well, they don't read a book like you've written here. Where will people get this kind of wisdom, this sort of history that I would even say this reverence for the history. Where does where does somebody learn that in today's world? A mentor, somebody that they're working, somebody in their company or someone they know whose older experience been around is aware of this
sort of oral history. And that's a rare thing. That's kind of hard to find out there. I think there's another way too, which is we have the entire world available to us now, thanks to the uppercase i internet. And that means that we've also got opportunities to play with things that we never used to have. So if you are motivated and if you're curious, you can go back and you can actually get a copy of a similar compiler and run it on your local
machine. So for this course I'm giving, I was looking for a pdp 11 emulator. So we'd all be able to write some pdp 11 assembler. And I found one that actually runs in the browser. It's written in JavaScript and it actually emulates a pdp 1170 in my browser. And you have to slow it down because by default it would run faster than a real pdp 1170 would. Being running in my browser. That's fine. Yeah. It is the things you can do to research a history. It's phenomenal. It's
phenomenal. If you wanted to go back and have a look at churring and have a look at the stuff that did at Blitchdy Park and all this kind of stuff, it's just, you know, it's there and you can play with it. But people don't. People are always looking forward. Never looking back. Well, I mean, I agree with you. I feel like a lot of us just want to, we just want to have some work. You know, like a lot of us just want to become functional programmers that can get a job
and then we're busy with our job. And you got to start with that. But you know, it's that old saying about, you know, chopping down all the trees. First, you have to sharpen the axe. Right. You know, so this is, you know, one of the important things and we mentioned this a little in the book is you have to set aside time to sharpen your axe to improve your, your knowledge portfolio to sharpen your skills. You know, it doesn't come for free. You can't just go to college or university or go to
a code boot camp and now I know everything. You know, it's not like the matrix where you stick the the jack in your head and boom, I know Jiu Jitsu. You know, you can, that's a great start. Something you can, and you can start getting, you know, work that way, but it's an ongoing, continual process. You have to, you have to make the commitment to always be learning, to always
learn something. If you think about like, say a jazz pianist, so jazz pianist probably started off learning to play the piano by reading music and basically copying what was there on the page. And so you know, you would sit there and you'd play Mary had a little lamb and then get more more complicated. And there are still musicians who are incredibly good musicians who fundamentally sight read and you know, memorize the piece and the complia piece and whatever.
You're a jazz musician. That's not good enough. You have to understand the theory of what you're doing. And it's really staggering to me that if you, if you go online and you read, or you look at videos of jazz musicians explaining what they're doing and how they're doing it, it's all theory. All right, I always thought these guys were just playing out of their souls, but they're playing out of their souls and their brains at the same time. They actually understand the underlying
reality of what they're doing. And it's the same as software. You can start off by cutting and pasting out of, you know, whatever you find online and developing applications that way. But if, at some point, you want to become virtuous. So if you want to develop new things that haven't been done before, then you've got to go back and understand the basics. You've got to understand the theory.
And that's that's something I think one of the things that's changed over the interleaving years, you know, when we started off when our careers were young, you kind of had to know a bit more of the lower levels. You had to know a little bit about Boolean logic and transistors and chips and gates and assembly language. And, you know, these days, you've got, you know, students starting in at JavaScript, starting in at, you know, a higher level language. So, you know, way, you know, it's
kind of, again, it's a two-edge sword. We had kind of an unfair advantage because you had to know a lot of that stuff back in the day. You know, it's like when the Model T first came out, right? The starter instructions ran two pages because that's what it took to get it going. You had to be a mechanic to in order to own and run one as opposed to now, you know, you walk near the car with your
fob and it just starts. You know, it's it's so much it's a much different world. But that low level knowledge, understanding how all the higher levels of abstraction feed down and actually run on the bare metal, that model is crucially important, I think, to have in your head. Otherwise, when you're operating in one of the higher level languages and something goes wrong, you have no idea what's going
on. It's not an unfortunate fact, though. I mean, the definition of a leaky abstraction is that, you know, you have to understand the things beneath it or on the other side in order to use it correctly. Wouldn't it be, I guess this is just an idealist perspective. Wouldn't it be better if we didn't have to know? That would be great. That would be nice. That would be awesome. That would be awesome. That would be awesome. That would be awesome. That would be awesome. That would be the world
works. Yeah. Don't ask for what you can't get. It depends on the level of, if you can componentize stuff well enough, that it is genuinely a black box, then you don't have to know how it works. So, for example, my car has so far exceeded my knowledge of how it works. That, you know, unless it's something really retrieval, it goes down to the shop every time it's the big brakes. You know, because I open the front of my car and it just basically looks like a big
plastic box. I have no idea what's going on, but that's okay. And I'm happy to use my car because it is componentized to the point where, you know, somebody somewhere can fix it. If software were componentized, the same would be true. If I could rely on a box that did something, a library, for example. Yeah. Yeah. And which I do actually think about it, but when I do, when I get a sign out of a math library or a cosine, I don't know which
particular expansion it uses, I don't know how it does it. I know it's going to be way, way beyond my level of math to understand it, but I don't care because it's going to be used to sign. Right. But if I'm going to use a library that does pausing, for example, and every now and then I get a funky result, well, I'm never sure. Is it my fault? Is it it's fault? And depending on the the mueness of the library, you know, I'm kind of inclined to
think, well, maybe it's it's fault. I've got to dig into it. And the number of times I ended up putting tracing code into other people's library code just so I can find out what's going on. That's where that componentization idea breaks down. So to reuse the metaphor with a car, as developers, are we all called to be the mechanic or can some of us be the end user of the car in a componentized world and maybe just have to send the component off to the mechanic every once
and a while. Think about the car as being a network of components. So at one level, you buy a car, but car consists of, you know, a cylinder block and spot plugs and injectors. I'm sorry. That's so recent. Thank you. There you go. That Wow. You know more about cars nearly not. Yeah. But and then all of those things are are themselves components that other people rely on. So this probably, I don't know how many levels deep it goes before you get to, you know,
a rock in the ground that somebody has to dig out to turn it to steel. But maybe it's 20 layers deep. And at each of those layers, people are relying on the previous layers being rock solid components that they actually can rely on without having to dig into too much. And that's what we're lacking. Right. Yeah. So you don't have to know if you can rely on the things that you're relying on. You know, as in if you know that they're going to be good for you, you understand 100% how they work.
There's no ambiguity. There's no bugs, whatever else. Then we are all car drivers. Right. But the reality is what we're actually are. Some of us are, you know, injectors makers, some of us handle the radio, some of us handle the wheels. And you know, we're all doing the things that rely on people at levels below us. And I think the important thing to remember, which again, I think we lose sight of is this is still brand new to us as a as a species, right? The whole field
of computing has only been in existence, depending where you count from 50, 60 years tops. Right. You know, late 40s maybe that's that's nothing. You know, you look at some of the older professions, you know, legal medical where they've had, you know, hundreds of years, you know, thousands of years in some cases to come up with. Here's how we mentor people. Here's how we educate people to bring them through the ranks. Here's how we attack problems. Here's how we
address ethics in our profession. And we've had a lot of time to work out those issues in other areas. And you know, we're still we're not we're embryonic at this point. I mean, 50 years is nothing. This episode is brought to you by GipRime. They just released a 52 page beautiful field guide
called 20 patterns. This field guide is a collection of work patterns. GipRime is observed over with hundreds of software teams and their hope is that you use this field guide to get a better feel for how your team works to recognize achievement to spot bottlenecks and also to debug your development processes with data. You'll learn about long running PRs, flaky product ownership, scope creep knowledge silos and so much more. Check this out for a link to download this field guide
or learn more at Gitprime.com slash change log. That's g-i-t-p-r-i-m-e dot com slash change log. It sounds like this book became a happy accident in terms of you weren't intended to write the book and you wrote down some of your thoughts and that became this you know very popular 20 year old book we're now talking about with a brand new addition 20 years later. It's even used in university courses or some sort of course education as well. So yeah huge success. Unexpected. So what else was
unexpected from this book? Oh everything. I mean the book means it's fair to say I think the book changed our lives because because of the book we got an entree into conference life. We got to meet a whole bunch of very interesting people. We got involved with the Agile manifesto folks and we ended up with a publishing business. So without you know the book changed everything where we'd be now without it I'm not 100% sure. So the publishing business was you tell about happy
accidents right we did not sit down and decide hey let's start a publishing business. That was not our original idea. What we'd wanted to do that as a follow on we so we'd written the pragmatic programmer we'd written the first programming Ruby book so that that had come on the scene. Pickaxe look right. You know the pickaxe yep and we thought you know what what the world really needs the better mouse trap what we need here we wanted to come up with a kind of starter kit in a box
for teams. So it would have a pile of books on the things you absolutely had to know to get started and some you know desk toys, Nerf guns, some rubber ducks to put on your terminal you know this kind of thing and we went pretty far down that road we actually lined up a source of rubber ducks that we could get imported and boxes and shipping and all these kind of logistics and then figured well the real problem was we didn't actually have enough content to really fuel this endeavor.
So we needed a couple books on the real basics like how to use version control how to incorporate automation and your dev ops now into your project you know how to do a unit testing you know the real basics. So we figured okay we'll just we'll just write those books first then we'll have something to put in this box and those became the first books that the pragmatic bookshelf published
starting in the fall of 2003. So we had the first couple books out and then these became incredibly popular to our surprise and we had friends start to write us and say hey can I write a book for for all y'all because all y'all is the proper plural as I discovered I thought it was just y'all down here I was wrong it's all y'all. So our friends are coming say hey we'd like to write a book can we write a book and we started publishing books and never did get back around to the
to the developer in a box concept. Maybe now it's a time get the get them rubber ducks back out. You still got that supplier in check. That was a lot a lot of years ago I don't know if they're still in business now. Free business idea for the listeners if you want to do a developer in the box it's out there and he just well now we've got the books now we've got the books to support with.
So they call dibs don't do it. Yeah. Well that's interesting because I came on the scene like so Jared has a bit more of a history he's gone to to school for what he knows and I just sort of learned what I know by rubbing my knuckles on the ground and punting things and just bloody my knuckles most very short and it's what's interesting is that your repertoire books was my learning ground so to speak you know that if it hadn't been for you all doing what you did in
this happy acts and we're speaking all y'all all y'all. No there's only two of us is singular. All you all when he kicks in at 506 you know this happy accident is enabled myself as well as many others I'm sure then must you know they've you mentioned life changing that must be really life-changing as well is that you've been able to influence so many careers as well as useful software. I think the word you're looking for is scary but yeah it is actually it's it's this is going to sound
a bit funny but honestly it is genuinely humbling. The I was remember I was doing talks for a while I was on this no fluff just stuff tour which basically takes a conference to a different city in the United States like once every two weeks it just moves around the country which is a really
really great way to develop your speaking jobs and somebody came up to me after one of my talks and said it was the day after I'd spoken and he said you know I listened to your talk and I went and I quit my job and I went oh no you know and it was like okay what have I done I've
liked to press him so much that he's going to go and become like a farmer or something and no I basically I was talking about like whatever it was and his current job didn't offer that so he decided he wanted it and he went and found something else and quit quit his previous job
and that kind of thing happens a lot and it is really scary it's very easy to sit there and say okay I'm just going to you know make dramatic points that sound good you know generate little sound bites and you know go for the clickbait kind of stuff and not realize that what you do actually
does have an impact and you're going to be a little bit careful and a little bit responsible you know they're not going to you know go out and you know create an intergenerational psychopaths we're also you know people often say well we got lucky and in part we did if if the book had come
out 10 years earlier or 10 years later I don't think it would have had anywhere near the impact that it did as it turned out we had sort of the right book but at the right time it was what you know what people needed to hear then and I think that that made a big difference also it wasn't
it wasn't sort of universally beloved when we were working on it we had a couple reviewers one in particular who thought that writing a book such as this that didn't have you know hard proofs and hard logic behind it was irresponsible and that we should not publish this thing this was
this was a heinous I forget what words he used but very very negative like you have no right to say this kind of stuff and like well it needs to be said so thank you very much for your input thank you for your feedback and you know we went ahead anyway and and I'm glad we did but you know
I guess my point here is you know if you come out with something you're always going to have naysayers you will have people who say that you're wrong or they disagree or whatever and hey you know what it's a big world that's fine we've had enough feedback over the 20 years from people who
like you said you know this has changed their careers this has changed their lives for the better I mean we get fan mail you know I think it's it's kind of rare in the in the tech book world that you get a lot of fan mail from from people especially 10 20 years you know after the fact but we
still get fan mail email you know regularly that this has made a big impact on people and as Dave says that's that is pretty humbling you know I'll still chalk it up to beginners luck because we were just writing down what worked for us you know here are the things that we've noticed here's
the stuff you might want to think about try and do it this way so you know we approached it very realistically very honestly we didn't have a product to sell we weren't trying to sell some big IDE or some development tool or some process it's just hey here's the stuff we've done this works give it a shot and that's proved to be workable and very popular.
I think the other thing that that I think the book was just pure dumb luck I think the book shelf was also dumb luck but for another reason and that is when we were looking around to you know start creating the first couple of books we had the decision do we publish them ourselves or do we send them off to a publisher and just basically you know do the writing and we asked ourselves the one fatal question that I think every entrepreneur needs to ask themselves and that is how hard can it be
I don't know yes and we answered it using the same stupid answer that every entrepreneur and that would be oh come on it can't be that hard I think had we known going into it the I think the expression is pecked to death by ducks there are thousands and thousands and thousands of little
small details in the publishing world that if you knew about upfront you would just basically go oh no I'll let someone else deal with that but because we didn't know that we went in and we just basically said well how should we do this you know and we applied all of our software development
ideas to publishing and we did it that way and as a result for a while we were the fastest growing publisher in the world which is kind of easy to do when you start from almost nothing but at the same time our systems still are way superior to any commercial publisher out there any big
you know brand name publisher out there just because we didn't actually carry that history with it so I think that's really important is going into something big like that from a position of confidence that necessarily rooted in reality I think it is one of the best ways of making sure
you succeed some of the book amounts then so since you've been doing this quite a while I mean tons of categories on the left hand side of the pragmatic bush shelf so there's lots of books how many books in total how many words in total any stats words words I don't know last time I
counted we were hovering around the three hundred three hundred and fifty titles that we'd publish somewhere in that nick of the woods it's it's a little trickier to answer because what counts as a a book is it the same book that's had multiple editions do you count the different editions
do you count you know the ones you know obviously we have ones that went out of print as you mentioned earlier a lot of tech books have a short shelf life so you know many times we have to retire one and we'll come out with another edition if it makes sense or if it's something that has already
passed by the wayside like the Google Glass book for example that was fairly short lived so one thing that's sorry just I want to step on the current size of the repository it's big it's one and a half two gigs I think no no way bigger than that last time I mean when I
last looked at it it was over eight that's probably ten or twelve then would be my guess it's it's it's big my repository mean of the books right so you keep them all in digital format oh yeah and they're they're all they're all the source for the books is under version control and see this this
was our saving grace you know going into an industry we knew nothing about we approached it as if it were a software project so there is everything's under version control there's a build machine in the cloud that produces the books as you check in there's all these sort of trappings that you
would you know expect if you were a software person and I remember the one of the first publishing conferences we went to one of the other publishers we were chatting and he was just a gat just you know his jaw was on the floor that we had everything even in the same format and we could tell
you know it's the side effects right by virtue of having everything in version control we could tell it a glance when an author had last worked on a book how fast they were going you know when they were working you get all these kind of statistics sort of for free just by having that
version control everything's in the same format you don't have these issues that other publishers have well this one was inward this one was in quark express back in the day this was in frame maker this was in in design this was you know whatever so these things we did sort of by accident ended
up saving our bacon there's whole cottage industries that sprung up and publishing to help other publishers get around these problems that we never had in the first place because we did it differently yeah yeah I was in a publishing conference I don't typically go to publishing conferences
it's too depressing but I went to one in New York City and I was sitting in the audience and this was be about 2008 nine something like that and it was a talk on creating e-pubs and I was kind of interested because we'd just gone through that process of creating e-pubs
and the speaker described the flow that they went through to create an e-pub which was baroque at the best and he at the end said so we can go from a I think it was quark format into an e-pub in just over a week and the audience went wild wow that's really incredible you know
literally there was when he said that those you know implores broke out and I was sitting in the audience with my laptop and I'd actually there was an erata I had to fix on a book and I'd actually fix the erata regenerated the book created the e-pub and pushed it you know and you know that was in
the first quarter of his talk so you know on the hotel wi-fi no less that's a meat yes what it's not it's not a it's just a side effect of that's like saying no wi-fi the the rest of it is less like you know people that say I can deploy my application on every commit
all right you know and that's what we do if we actually consider doing that we consider creating a new beta book every time the author checked in anything but then we thought and we common sense actually prevailed on that yeah it's a bad check ins oh yeah raw bags
well and authors have been known to insert comments that you know I hate this xxxx whatever or something you know so yeah it requires a little bit of editorial control yeah so speaking processes and editorial control and tools whenever I'm reading a book that has multiple authors I
find myself wanting to appeal back the covers and think like who wrote this sentence and you know whose ideas were these I'm sure it's difficult as a co-authoring to have a singular voice or if you can try to have a do you have multiple voices I was reading the dry section of the new edition
where you are talking about how people kind of took that wrong like you'd mentioned the top of the show Dave and it starts off with this you know this James T Kirk reference and I'm thinking is this a Dave thing is this an Andy thing I'm just going to wonder just like who writes what how do
you guys work together what are the logistics of the process we ended up from from our experience with with the first book and it took us a long time to get there we took a year over a year of not taking on clients working just on the first edition of the pragmatic programmer and we
would argue Dave and I would argue over this word that word you know this sentence you know we had a process that we set a lot we use version control for it and the the process was when somebody finished something they would say to the other person here you go and the other person had one or
two choices they could either say love it or they'd say I'm going to rewrite this part of it right you couldn't just sit there and bitch about it no criticizing just no criticizing and so um we would go around some of those sections went through that mill so many times that you know
I don't think anyone could actually work out who wrote which character nevermind which word in in those sections and that had the unintended consequence of helping us blend a style um I mean I can definitely tell stuff Andy wrote and stuff I wrote if we write them individually
but when we put them together in the book um and particularly in the new content it's kind of interesting the new content we didn't need to do that as much when we still went through that process but it wasn't anywhere near as intense because we'd actually kind of developed a shared
common style having spent all that time you know basically working through it on the first edition well and plus we wanted to to match the existing text from the first edition so yeah whatever drift had happened over the last couple of years we needed to you know sort of you know match or refresh
what was there so you can't tell here's where we you know chopped a limb off and sewed something else on um and yeah remarkably I think it worked out really well if I go back and read it now I find it harder and harder to remember was this back in the first edition or was this something new that we
added you know it's it's much more seamless um you know than I think I was kind of afraid it wouldn't because it's been 20 years and you know our styles have changed we we write differently um you know a book that I would write myself I think would have a different style than this you know this is
very consciously okay this is this is this voice this is our our shared voice for this topic and I think it worked out really well really seamlessly so Adam and I have worked together in collaborating on text and pros and you know rewriting each other's things and it can be uh difficult on a
relationship even in the small amount that him and I do it like sometimes we have to talk about things or provide context why I didn't like the way this was worded or why I rewrote it I imagine you guys went through a like a pressure cooker or your your relationship just like you know you
you spent some time writing the thing and then you wake up the next day and Dave has rewritten that entire section because he didn't like it that put a lot of stress on your guys' relation it seems like talking to you today that everything's okay but were there any uh knockdown dragouts
that the stick the phrase yeah there were um but nothing that was uh uh uh uh uh nothing that was permanent must put it that way um we had a few like people hanging up on other people type phone calls um most you know it was mostly just a kind of you know
people who were passionate about an idea and expressing that idea um and partly at the beginning it was trying to develop a shared vision of a voice um and that's a really really hard thing to express because it's kind of more you know it when you see it you can't sit there and plan
ahead you know and so when we're arguing about no I think we should explain it this way no I think we should explain it that way it will go it got very very difficult which is why to some extent we settled on the show me as opposed to tell me because if I if I didn't like the voice
then I could rewrite something in a different voice and say here this is what I mean you know and that would be a easier point to discuss one of my favorite quotes of all time Jimmy Carter former president Jimmy Carter was in an interview and somebody asked him something
about did you had you ever considered you know over the course of your life had you ever considered cheating on your wife and he said oh no absolutely not murder yes did you know did consider killing or and it came out in the interview it was when they were working on a book together so you know
here you know Jimmy of all people right here's you know one of the most you know kindest generals people like oh murder yes absolutely yep straight up so it happens but you know we were lucky then Jared I haven't hung up on you yet and vice versa and no murders like
no murder we're doing good or we have to look forward to one of the two that just means you don't serious enough right right we're not pushing hard enough right well guys this has been a a blast of a conversation I would love to ask you this might be a hard one you know like pick
your favorite child kind of thing but you know if you had to take one big idea one topic maybe of the book like the thing that is your favorite like I love this section I think it's the best do you have and I'll I'll give you you can pick three if you can't pick your favorite child but
if there was a one big idea you can each answer this one that you just said you get the book you got to read this thing because it's it's something I'm proud of or something I think is you know 100% worth your time what was what would that be yes no that's too glib I'm giving a real answer
yeah all right I'll start off there we go so my favorites are the the two new tips one of them starts it one of them ends it the one that starts it basically says it's your life right you are in control of it you have agency so you actually have to do something
um too many people are on autopilot you know they'll take a job because it's the one that got offered and then they'll they'll stay there until they just can't stand it anymore then they'll take the next job that's offered and etc etc they will complain that they're using a language they don't
like and keep complaining as opposed to actually finding an environment where they can use a language they do like or whatever else they all complain that their employer isn't teaching them enough um but it's not their employer's job to teach them it's theirs so it basically says it's your life
and you can make it any way you want it to be but you have to actually do something and then the other side of that is the kind of the last tip which is kind of like it was an awkward tip and I'm still as funny we're going to print and I'm still not 100% sure whether or not
it's a good idea to end on it but it basically is the idea of the responsibility and the idea that you are taking responsibility for the stuff that you do which is kind of like another way of saying it's your life but it makes you think about it in terms of the big picture as well as the personal
picture but those two things for me I think are the the more important tips in the book because they're the ones that give you the idea that you have responsibility both for yourself and also for everybody else so now that he's taken those you go first you get the best exactly exactly
so I would say I don't know that they're my favorites but I think that they're the most important ones that people need to pay attention to and and heed is around this idea there's a new tip called don't outrun your headlights and it kind of goes back to what we were talking about earlier about
Dykescher talking about being the importance of being a humble programmer you know not going faster than you can see taking small steps small bites and there's there's several different tips that kind of express variations of this idea you know the essence of design going for something
that's going to be easiest to change taking you know the smallest steps possible the essence of agility trying something small seeing what happens and then you know acting on that feedback so there's a there's a set of tips that go around this kind of idea of not going faster than you can
you know taking the small steps getting the feedback working on it and that's expressed in a couple of different ways from a couple of different angles different levels of abstraction but it's a very common thought of you know don't overextend yourself you know if you try to be as clever as
you possibly can when you're writing the code you've got no bandwidth left when it's time to debug it or explain it to someone or port it or do whatever you have to do with it you know you've already you've already maxed out your your capacity your capability you've got no headroom so you actually
want to go the exact opposite you want to write the absolute simplest you know most concise most elegant thing you can get away with and then go from there let's have the zone for those who are going to pick this book up today maybe even for the first time maybe even for the second time if
they're a a be back reader so to speak this is not the same book we mentioned earlier about the diff that you really couldn't tell there's a lot to change 75% of the topics had changed etc this is not the same it's not the same book now you're you're exactly right this is this is a very
different book because it's we're at a very different point in time this is 20 years later if it was just the same book and we had changed a couple labels in it you know changed you know iful to to you know elixir or you know changed c sharp to rust and made no other changes it would
kind of be the same book but that would have done a disservice to everyone because the world is different now so yeah it's a very different book that was you know the first edition was good for its time we're hoping this edition will be good for the conditions we're in now 20 years from now
when we do the 40th anniversary edition from our walkers um you know that'll be that'll be different yet again it will explain how to how to be nice to sky net and and then let you code and whatever continue to think free i suppose i just wanted to ask you that question because i think
it's an encouragement to hear from the both of you from you specifically that this book is worth either picking up for the first time or picking up it again if you've read the first edition so this 20 years later second edition is very much a new book new principles to learn new things to
consider on your journey as a software developer to this thing called mastery which we all never really truly ever get to because we're always improving um that's that's really awesome but i want to encourage people to the books and beta out it's out right now you can go get it today
in ebook format at pragprog.com that's prag.com and the hardcover fellows has come out later this year's that right there's no real set date there probably is um we don't know what it is but it's it'll be it'll be in the fall it'll be roughly middle of september middle of october um
sort of time frame just in time for christmas so you can get the nice hardcover edition for yourself and all your loved ones just in time for christmas i would encourage to the ebook format since since they've mentioned that the if you enable a scumbag your scumbag section may not be the ending
hey maybe it might even leave get the ebook now and the encouragement there is that you will get 50% off the hardcover which i think is just very generous you fellas to do that like by the ebook today and you get 50% off the hardcover when it comes out which is super cool yep fellas thank you
so much for sharing your wisdom for remaining friends calling back uh you know for encouraging change through pros rather than argument i think that's very uh very wise if you fellas to to to act on that but then also to share that wisdom with the rest of us so thank you for your time
today well thank you so much for having us yeah thank you all right thank you for tuning in to this episode of the change log hey guess what we have discussions on every single episode now so head to changelog.com and discuss this episode and if you want to help us grow this show reach more
listeners and influence more developers do us a favor and give us a rating or review in iTunes or Apple podcasts if you use overcast give us a star if you tweet tweet a link if you make lists of your favorite podcast include us in it and of course thank you to our sponsors Linode go see
the and get primed also thanks to fastly our band with partner roll bar our monitoring service and Linode our cloud server of choice this episode is hosted by myself Adams de Kovia and Jared Santo and our music is done by break master cylinder if you want to hear more episodes like this subscribe to our master feed at changelog.com slash master or go into your podcast app and search for changelog master you'll find it thank you for tuning in this week we'll see you again soon