The Changelog: Software Development, Open Source - The Pragmatic Programmers (Interview)

Episode Date: July 11, 2019

Dave Thomas and Andy Hunt, best known as the authors of The Pragmatic Programmer and founders of The Pragmatic Bookshelf, joined the show today to talk about the 20th anniversary edition of The Pragmatic Programmer. This is a beloved book to software developers all over the world, 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 of software. Also, the beta book is now "fully content complete" and is going to production. If you decide to pick up the ebook, you'll get a coupon for 50% off the hardcover when it comes out this fall.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash Changelog. This episode is brought to you by Linode, our cloud server of choice. It is so easy to get started with Linode. Servers start at just five bucks a month. We host Changelog on Linode cloud servers and we love it we get great 24 7 support zeus like powers with native ssds

a super fast 40 gigabit per second network and incredibly fast cpus for processing and we trust linode because they keep it fast they keep it simple check them out at leno.com slash changelog. From Changelog Media, this is the Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. Today, Jared and I are talking with Dave Thomas and Andy Hunt, the authors of The Primatech 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 of 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. 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 e-book 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 it took you 20 years for a second edition. How has this book stood the test of time?

Firstly, 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 people haven't changed that much. Expectations have changed, but the actual way people do things, I mean, that really hasn't changed for thousands of years. It was just as bad now as we were then. And, you know, 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 in 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 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 latest adventure, it's like, oh, you know, 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, this sort of thing. I mean, we didn't have anything in there talking about security, trying to fight against bad actors. Because 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, it's, it's everywhere. Don't reinvent the wheel 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 uh when this was first written which was 98 99 um. That was before the Snowbird meeting that kicked off the agile movement,

for want 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 we've had the opportunity to simplify some explanations in light of the fact that stuff that we were talking about has now 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 was just barely out.

And to be a programmer today, Google's your best friend, right? Find the answer if you've hit a wall. Even then, when you wrote the book, Google was barely even in the day-to-day lives. No, we were using AltaVista, I think, a lot, 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 the Internet with a capital I. It's like you can download all these languages. You can get help online from people.

There's these communities. It's the internet. Again, it's really kind of like going back in time and reading some of this going, wow, because that was brand new and exciting and interesting. And now it's ubiquitous. One of the exercises we had in our chapter on estimation was to calculate how long it would take to send, I can't remember what it was, like 10 megabytes over a 9600 board line. Oh, man.

It's probably harder to answer now. It probably is, yeah. First find the 9600 board line. 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 from 1999 and drop them into a teen 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? Everything, every day. I mean, it's funny.

Anytime I go out and give a conference talk, I always throw in a joke that, well, it's Wednesday. That means there have been 47 new JavaScript frameworks that came out this morning. And invariably, right, the whole crowd laughs nervously because that's not far off. Nervous laughter. The nervous laughter, yeah. 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 and better ways to approach problem solving with different attitudes toward frameworks 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, 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 paths. 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 local university. And I've been putting together some material using peg parsers 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. And my heart goes out to developers nowadays that you have to keep track of all that stuff. 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,

stop the madness. 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 React or whatever. Kind of like a feature freeze on all programming.

On the world. 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 discover it's missing other things. So then they go and they write their own version, which has those things. And it goes on and on and on, and it never actually gets resolved. And I just feel

that 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 forward progress. That's all I'm saying. No, I'm all for experimenting. I'm just saying we don't always have to be using the cutting edge of everything every time we write a piece of code. Again, it comes down to context.

A lot of the times, boring is great. There are some applications, some things out there. I want something. The thing that's driving 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 web view of stats or something. Right, right, right. Something non-critical. Even that will probably, you know, crash on you but yeah um you know boring boring has its place um 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. I would love to say freeze the world, don't make any changes, 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 depends. It totally depends on the context. And that's something we tend to be a little tone deaf to. 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 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 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. So sometimes a little bit of that, just moderation, I guess, goes a long way. I say, and in general, you only want to change one thing at a time.

If you're debugging, you're not going to go change five different lines of code, swap in a new library, and cross-compile it to a different target. Well, let's see if the bug's there now. You have no idea what's going on if you do that sort of thing. You change one thing, see what happens. When you teach kids to climb, you always say the rule of three, right? You only ever move one hand, one foot. And then that way you've already 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. There you go. Yeah, I saw that video. 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 their clients. Yes, but I wouldn't say – I try not to preach. We try not to preach. It was more a case of 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, looking at the wrong end of the telescope and and you know suffering in the same ways so the original idea was that we were just going to write a little white paper um of the sort of the things that we'd observed 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 or you know this kind of this kind of get plenty of exercise. Always get that the wrong way around. I always do. I usually do eat your broccoli and brush your teeth, which is out of order. But, you know, 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 iterative and incremental. It's, oh, it's a tracer bullet. Oh, 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 be like, okay, well, start with this. And then by the time we get there, we got a more of a common vocabulary we can talk about some of these issues better and um you know as unlike any software project ever right that

little idea of a white paper grew uh into a larger project and that became the pragmatic programmer book maybe go a little deeper too then to the differences i would say so we're 20 years later uh you're still in the software business. Not much has probably changed much about the two of you. That's part of the question, really, is what are the differences in the last two decades? I mean, 20 years in software is like, I don't know, do we compare it to the dog years? Is it times seven? What's the multiple there?

But it's a lot, right? It's a big, yeah, it's a big multiple. What's changed in 20 years? Everything and nothing, to be flip about it. And Dave can certainly go in and tell you some about the – I think there's a fundamental shift of attitudes of – I was really struck when we came back and looked at the original Prague Prog 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 OO style sort of a book. But it really was. Most of the architectural and

design tips were kind of at least OO flavored, if not overtly, this only works in an OO style system. So there was a lot of that. A lot of examples I thought 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 that sort of thing now, it's like'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 a you know an iterate or something um so there's definitely a lot of that attitudes and approaches that change moving stuff to the cloud you know

big change we would talk about the build machine sitting in the corner, which some people still have, bless their hearts. But, you know, that right there is a really big shift of having build machines that are just, you know, fungible resources off somewhere else. You know, 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, or is it New York, whatever, has been living in the South long enough that he can say, bless their hearts.

It's a nice touch. That is nice. Yeah. 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. In the old days, you wrote code and it ran on a mainframe or maybe it ran on a PC or possibly even on a web server.

But it would be kind of boring old code that did some business function. Now you're writing code that can change people's lives. It 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. I mean, at the end we talk about don't enable scumbags.

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 but we have the power to say yes or no and we need to be thinking very very hard is the software that they wanted me to write going to harm other people and if so are you prepared to take that in on your conscience? Thank 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. do you two still work together or beyond just writing the book well we're i mean sort of is the answer um so andy is uh still running pragmatic bookshelf i kind of retired into genteel 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 like work together again for a while. And it's actually kind of nice after a break to go back and work with someone you've 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 you know yeah well and it was it was funny when we first decided we should take a serious look at redoing this edition of 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 20 years? What are the things we should address? What topics did we, you know, felt we should drop? Which ones 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 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 git diff

because we moved from using LaTeX to using Markdown on the second edition. But wrote a quick tool that basically did a, what is it called? Cosine whatever-y comparison on a paragraph-by-paragraph basis to see what had changed. And the answer is about 75% of the paragraphs have changed.

75, is that what you said? Yeah, 75%. And by change, I don't just mean, you know, like a small typo fix or something. 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 have been 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 will ever change until we get mind-melding. So, you know, I think that's, you know, it's pretty easy to predict, actually, which ones would change the most. And again, it's like, you know, you can go back to Fred Brooks' book, Mythical Man Month, and it's all talking about the IBM mainframes and languages

and technologies we don't use anymore. But if you went through and did a 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 this kind of, you know, Dave was talking before about this adrenaline junkie 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 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 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, 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,

you know, basically just sitting quietly with people. I think, yeah, that definitely impacts the world. And it could be the reason we're seeing a more aggressive, apparent society than we have for a long time. When I looked 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 of clarity not just clarity when you're naming them but clarity that helps you think about things better that's a people problem um it's all it's all to do with you know various psychology and physiology and other kind of ologies that are are to do with our failings as human beings or are maybe that's the right word not failings maybe our uh uh ambiguities and our our our weaknesses i'm still back on the amnesia bit myself and andy i was just curious if you have thoughts on like how we solve these problems because we do have this issue in our industry where there's a lot of wheel reinvention.

Sometimes it's experimental 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. How else do we either institutionalize or communityize into our culture the passing on of the knowledge from those who've come before us so that we stop making the same problems and we can 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 X, Y, Z. 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 such a constant drive to write code faster, provide more functionality more quickly, use 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 theses and dissertations and seeing what people came up with before that was useful. Sometimes they do, and you'll see an article on 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. Well, it's not new. It goes back when.

In quite a few places in the book, we point out that this idea came from Simula in 1967, or this idea came from this other place way back when. We don't have a good sense of history. And 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 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 should be a separate class because I think it's, okay, so what we do is 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 see tricks, you see, you know, the more you read, the more you understand how people are organizing their thoughts on paper and everything else. Now, I'm not talking about developers reading books here. I'm talking about developers reading code

and trying to read a variety of code. So they go back and they look at code written in different languages and try to work out how that works, why that works, why does it work the way it works? So I would like to see the idea of teaching tied into this idea of learning how people did things in the past, reading their code, and then discussing, okay, why did that happen? I'll 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 ch equals star C P plus plus, which takes a character pointer, dereferences 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. Two of them are pre

and post increment address dereference. And so that maps directly onto the hardware. And it's like, oh, okay. So that's why it's there. Now then you can ask yourself, okay, is that something I really need to think about going forward? You know, do I need that on mine or is it just a convenience that happened to be there? You know, same with GoToConsideredHarmful. You have to understand, I mean, people will quote GoToConsideredHarmful and entire languages had 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 more sexy as a title. Clickbaity. Clickbaity. 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, it 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 restricted 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, post-increment, and don't really know why we do it. Here's one that I learned. Globals are evil. Global variables are evil. I learned that in college, but I never – it's almost like it's a cargo cult. I never learned why.

It was just like a maxim. It's just like this is true. You should read our book we have a whole section on that but let me let me get back to that uh for a second talking about like like the go-to and these old old letters and old articles and old um 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 um was it Dijkstra who had the Turing Award lecture about the very humble programmer? 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 culture, and it is probably, of all the kind of human-y, human factors-y 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. This is part of our headlong rush into the shiny new thing is this kind of faith that, well, that's going to experiment, get feedback, try it. You know, this is part of our headlong rush into 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, if they don't read a book like you've written here, where will people get this kind of wisdom, this sort of history? I would even say this reverence for the history. Where does somebody learn that in today's world? A mentor. Somebody in their company or someone they know who's 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. 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 funny.

It is the things you can do to research history. It's phenomenal. It's phenomenal. If you wanted to go back and have a look at Turing and have a look at the stuff they did at Bletchley 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. 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 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 it's that old saying about chopping down all the trees, first you have to sharpen the ax, right? So this is one of the important things, and we mentioned this a little in the book, is you have to set aside time to sharpen your ax, to improve your knowledge portfolio, to sharpen your skills. 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. It's not like the matrix where you stick the jack in your head and boom, I know jujitsu. That's a good start and you can start getting work that way, but it's an ongoing, continual process. You have to make the commitment to always be learning, to always learn something. If you think about, say, a jazz pianist. So a 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 would sit there and you'd play Mary Had a Little Lamb and then get more and more complicated. And there are still musicians who are incredibly good musicians who fundamentally sight read and memorize a piece and they can play a piece and whatever. If you want to be 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 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, 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 with software. You can start off by cutting and pasting out of whatever you find online and developing applications that way. But if at some point you want to become virtuoso, 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 something I think, one of the things that's changed over the interleaving years, 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 these days, you've got students starting in at JavaScript, starting in at a higher level language. So in a way, it's kind of, again, it's a two-edged sword. We had kind of an unfair advantage because you had to know a lot of that stuff back in the day.

It was 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 in order to own and run one, as opposed to now, you walk near the car with your fob and it just starts. 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. Isn't that an unfortunate fact, though? I mean, the definition of a leaky abstraction is that 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 the underlying constructs? That'd be great. That'd be nice. That'd be nice. That'd be awesome. Just not the way 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, unless it's something really, really trivial, it goes down to the shop every time something breaks. 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 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, which I do actually thinking about it. 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 probably way, way beyond my level of math to understand it. But I don't care because it's going to produce a sign.

Right. But if I'm going to use a library that does parsing, for example, and every now and then I get a funky result, well, I'm never sure. Is it my fault? Is it its fault? And depending on the newness of the library, I'm kind of inclined to think, well, maybe it's its fault. I've got to dig into it. And the number of times I've 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 the 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 in a while. Think about the car as being a network of components. So at one level, you buy a car, but the car consists of a cylinder block and spark plugs and injectors. I'm sorry, electric motors.

Thank you. There you go. Wow. You know more about cars than you're leading on. Yeah. And then all of those things are themselves components that other people rely on. So there's probably, I don't know how many levels deep it goes before you get to

a rock in the ground that somebody has to dig out to turn into 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? You don't have to know if you can rely on the things that you're relying on.

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. But the reality is what we actually are is some of us are injector makers. Some of us handle the radio. Some of us handle the wheels. And 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 species, right? The whole field of computing has only been in existence, depending where you count from, 50, 60 years tops, 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 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 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. You know, 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 Get Prime. They just released a 52 page beautiful field guide called 20 Patterns. This field guide is a collection of work patterns Get Prime has observed while working with hundreds of software teams. And their hope is that you'll 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 the show notes for a link to download this field guide or learn more at getprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog.

It sounds like this book became a happy accident in terms of you weren't intending to write the book. And you wrote down some of your thoughts and that became this, you know, very popular 20-year-old book that we're now talking about with a brand new edition 20 years later. It's even used in university courses or some sort of course education as well. So, a huge success. Unexpected. So, what else was unexpected from this book? Oh, everything. I mean, the book, I mean, 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 would be now without it, I'm not 100% sure. So the publishing business was, you talk 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 as a follow-on we so we'd written the pragmatic programmer we'd written the first programming ruby book um so that that had that had come on the scene pickaxe we thought you know the pickaxe, yep.

And we thought, you know, what the world really needs, the better mousetrap, 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 desk toys, Nerf guns, some rubber ducks to put on your terminal, 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 in your

DevOps now into your project, you know, how to do unit testing, you know, the real basics. So we figured, okay, 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 they became incredibly popular to our surprise. And we had friends start to write us and say, hey, can I write a book 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 started coming and saying, 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 developer in a box concept. Maybe now's the time. Get the rubber ducks back out.

You still got that supplier in check? That was 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 a box, it's out there. Well, now we've got the books. Now we've got the books to supply it 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 in my knuckles long story short and it's what's interesting is that your repertoire of books was my learning ground, so to speak.

You know, that if it hadn't been for you all doing what you did and this happy accident, we're speaking. All y'all. All y'all. No, there's only two of us at Singular. All y'all only kicks in at 5 or 6. You know, this happy accident has enabled myself as well as many others, I'm sure. That must, you know, Dave, 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, this is going to sound a bit phony, but honestly, it is genuinely humbling. The, I always 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 chops. 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. And it was like, okay, what have I done? I've depressed him so much that he's going to go and become like a farmer or something. And no, basically I was talking about 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 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 make dramatic points that sound good. Generate little sound bites and go for the clickbait kind of stuff, and not realize that what you do actually does have an impact. And you've got to be a little bit careful and a little bit responsible. You're not going to go out and create an entire generation of psychopaths.

We were also, people often say, well, we got lucky. And in part, we did. 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 people needed to hear then. And I think that made a big difference. Also, it wasn't sort of universally beloved when we were working on it. We had a couple of reviewers, one in particular, who thought that writing a book such as this that didn't have hard proofs and hard logic behind it was irresponsible and that we should not publish this thing this

was this was a heinous i i forget what words he used but very very negative like you have no right to say this kind of stuff and i was 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 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, 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 kind of rare in the tech book world that you get a lot of fan mail 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 is pretty humbling. You know, I'll still chalk it up to beginner's 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, uh, 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, um, 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 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? 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, 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? 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 brand name publisher out there, just because we didn't actually carry that history with us. And I think that's really important, is going into something big like that from a position of confidence that isn't necessarily rooted in reality, I think is one of the best ways of making sure you succeed. Let's talk about 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 bookshelf. So, there's lots of books. How many books in total? How many words in total? Any stats? Words I don't know. Last time I counted, we were hovering around 300, 350 titles that we'd published somewhere in that neck of the woods. It's a little trickier to answer because what counts as a book?

Is it the same book that's had multiple editions? Do you count the different editions? Do you count the different editions? Do you count the ones, obviously we have ones that went out of print. As you mentioned earlier, a lot of tech books have a short shelf life. So 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, what's the stat on the current size of the repository? It's big. It's one and a half, two gigs, I think. No, no, no, way bigger than that. Last time, I mean, when I last looked at it,

it was over eight. That's probably 10 or 12 then would be my guess. It's big. It's big. By repository, you mean of the books, right? So you keep them all in digital format. Oh, yeah, and all the source for the books is under version control.

And see, this was our saving grace. Going into an industry we knew nothing about, we approached it as if it were a software project. So 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 expect if you were a software person. And I remember one of the first publishing conferences we went to, one of the other publishers, we were chatting, and he was just a guy, 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 at 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 in Word. This one was in QuarkXPress back in the day. This was in FrameMaker. This was in InDesign. This was, 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 in 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 because it's too depressing.

But I went to one in New York City. And I was sitting in the audience. And this would be about 2008, 2009, something like that. And it was a talk on creating EPUBs. And I was kind of interested because we'd just gone through that process of creating EPUBs. And the speaker described the flow that they went through to create an EPUB, 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 EPUB in just over a week. And the audience went wild.

Wow, that's really incredible. Literally, when he said that, applause broke out. And I was sitting in the audience with my laptop. And actually, there was an errata I had to fix on a book. And I'd actually fixed the errata, regenerated the created the epub 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 i mean that's a feat yes it's not a feat it's just a side effect. That's like saying... No, I mean the Wi-Fi. Yes, yeah.

But the rest of it is just like, you know, people that say I can deploy my application on every commit. Right. You know, and that's what we do. In fact, we actually considered doing that. We considered creating a new beta book every time the author checked in anything. But then we thought and we common sense actually prevailed on that you had some bad check-ins oh yeah rollbacks well and authors have been known

to insert comments that you know i hate this xxx whatever or something you know so yeah it requires a little bit of editorial control. Yeah. So speaking of processes and editorial control and tools, whenever I'm reading a book that has multiple authors, I find myself wanting to peel 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 even try to have it.

Do you have multiple voices i was reading the dry section uh of the new edition where you are talking about how people kind of took that wrong like you 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 it makes me wonder just like who writes what? How do you guys work together? What are the logistics of the process? We ended up from our experience 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, this sentence. We had a process that we settled on. We used version control for it. And 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. You couldn't just sit there and bitch about it. No criticizing, just rewrite it. No criticizing. And so we would go around. Some of those sections went through that mill so many times

that I don't think anyone could actually work out who wrote which character, nevermind which word, in those sections. And that had the unintended consequence of helping us blend a style. 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, and particularly in the new content, it's kind of interesting. The new content, we didn't need to do that as much. I mean, 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 match the existing text from the first edition. So, you know, 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, then I think I was kind of afraid it wouldn't be because it's been 20 years

and our styles have changed. We write differently. A book that I would write myself, I think, would have a different style than this. This is very consciously, okay, this is this voice. This is our shared voice for this topic. And I think it worked out really well, really seamlessly. So Adam and I have worked together and collaborated on text and prose and you know rewriting each other's things it can be

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 a pressure cooker. Your relationship, you spent some time writing a 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' relationship. It seems like, talking with you today, that everything's okay. But were there any knockdown drag outs?

Is that the phrase? Yeah, there were um but nothing that was uh nothing that was permanent let's put it that way um we had a few like people hanging up on other people type phone calls um but most you know it was mostly just a kind of people who are passionate about an idea and expressing that idea. And partly at the beginning, it was trying to develop a shared vision of a voice. 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 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 got 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 an 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, had you ever considered, over the course of your life, had you ever considered cheating on your wife? And he said, oh, no, absolutely not. Murder, yes. You know, did consider killing her. And he said, oh, no, absolutely not. Murder, yes. You know, did consider killing her. 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 one of the most kindest, gentlest people. Oh, murder? Yes, absolutely. Yep, straight up. So, yeah, it happens. But, you know, we weathered it. I feel like we're lucky then, Jared.

I haven't hung up on you yet and vice versa and no murders no murders we're doing good or we have something to look forward to one of the two

that just means you're not serious enough right right we're not pushing hard enough right well guys this has been a blast of a conversation

I would love to ask you this might be a hard one pick your favorite child kind of thing but if you had to take one big idea one topic maybe of the book the thing that is your favorite I love this section I think it's the best

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 if 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 would those what would that be yes no that's too glib you gotta give me a real answer all right i i'll start off. There we go. So my favorites are the two new tips. One of them starts it and one of them ends it. The one that starts it basically says, it's your life.

You are in control of it. You have agency. So you actually have to do something. Too many people are on autopilot. They'll take a job because it's the one that got offered, and then they'll stay there until they just can't stand it anymore. Then they'll take the next job that's offered, et cetera, et cetera. 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 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, it's 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. Those two things for me, I think, are 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 um 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 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 Dijkstra talking about the importance of being a humble programmer, not going faster than you can see, taking small steps, small bites. And 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 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've already maxed out 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, most concise, most elegant thing you can get away with and then go from there. Let's set the tone 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 B-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 lots of change 75 of the topics had changed etc this is not the same it's not the same book no no 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 This is 20 years later. If it was just the same book and we had changed a couple labels in it, changed Eiffel to Elixir or 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. Twenty years from now when we do the 40th anniversary edition from our walkers, you know, that'll be different yet again. It will explain how to be nice to Skynet and 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 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. That's really awesome. But I want to encourage people to, the book's in beta.

It's out right now. You can go get it today in e-book format at pragprog.com. That's P-R-A-G-P-R-O-G.com. And the hardcover, fellas, is coming out later this year. Is that right? There's no real set date. There probably is. We don't know what it is, but it'll be in the fall.

It'll be roughly middle of September, middle of October 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, too, the e-book format since Dave mentioned that the If You Enable a Scumbag, You Are a Scumbag section may not be the ending. Hey, maybe you might even leave. Get the e 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 buy 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 prose rather than argument. I think that's very, very wise of you fellas 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 into this episode of The having us. Yeah, thank you. All right. Thank you for tuning in to this episode of the ChangeLog.

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 podcasts, include us in it. And of course, thank you to our sponsors, Linode, GoCD, and GetPrime. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service,

and Linode, our cloud server of choice this episode is hosted by myself Adam Stachowiak and Jared Santo and our music is done by Breakmaster 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.