Anniversary Edition of The Pragmatic Programmer

Listen to this episode on:

Apple Podcasts | Google Podcasts | Spotify | Overcast | Pocket Casts

---

Join the authors of “The Pragmatic Programmer” throughout their journey of writing the book to the 20th anniversary edition. Dave Thomas and Andy Hunt share how the book has evolved and what has remained unchanged in the past two decades. They touch upon the best way to learn something new by teaching it and the responsibility of developers towards the software they produce.

This episode of the GOTO Book Club was made possible thanks to the support of GOTOpia.tech. Created for developers, by developers, the GOTO event series goes beyond annual conferences held in Chicago, Amsterdam and Copenhagen: you can also join online conferences, online masterclasses and meetups with top creators and leaders in tech year-round. 

And if joining one of these top-rated events isn't enough to satisfy your hunger for the latest in tech, you can watch over a thousand high-quality talks on the GOTO YouTube channel — subscribe now for ad-free videos released (almost) daily and join GOTO in person or online at any upcoming conferences using the promo code ‘bookclub’.

Preben Thorø: Welcome to the GOTO Book Club. This time we are honored and proud to welcome Dave Thomas and Andy Hunt, authors of The Pragmatic Programmer, a super best-selling book from the late nineties. We invited them to have a conversation about the 20th-anniversary edition of the book.

Andy Hunt: Thank you. We're happy to be here.

Dave Thomas: Totally our pleasure.

Preben Thorø: I'm holding the 20th-anniversary edition of your book here, The Pragmatic Programmer. It's technically 21 years ago now since you launched the first edition. I'd like to hear what was the reason? What was the background? What made you write the book back then?

What was the reason for writing the book 20 years ago?

Dave Thomas: So, Andy and I had been consulting for a number of years in the '90s. During that time, we typically got involved in projects that needed help basically. I mean, no one brings a consultant into a project that's just about finished. So, we'd get involved in these projects, and typically would find the same problems in every single one. We'd find projects where people didn't test, where there was no communication between team members, where no one agreed on the requirements. Even projects where no one actually knew how to build the software. Every single build was different depending on who did it.

We started putting down some notes on what we should be saying to people. The idea would be that we would give them those notes even before we arrived, as a kind of short circuit of the boring stuff, and get into the interesting stuff.

Andy Hunt: Just a white paper. I mean, we didn't intend this as a book or a big project. Right? This was just a little, as Dave said, just some notes. It was just a little white paper, a little job aid to send out, you know, ahead of time.

Dave Thomas: Yep. I wasn't even actually going to use that new-fangled thing called the web at the time. Anyway, so we put all this stuff together. As in most things in software, what was going to start off as like a 20 page, quick note quickly got to 50 and then 100 pages. We started realizing that this wasn't what we originally thought it was going to be. And, a suggestion came up that we should turn this into a book. We had no idea what that meant and we had no idea whether what we had was any good or not.

So, we had a cunning plan. What we were going to do is we were going to choose the best publisher for software books. And, we were going to submit our little 100-page manuscript to them. They would of course reject it. But, when they rejected it, they would tell us what was wrong with it. That way, we'd be able to fix it up and, you know, actually make something out of it.

Like all good plans, this one failed. It failed because they accepted it. So we started working in on "Pragmatic Programmer" with Addison-Wesley in I guess the end of '97 beginning of '98, some time right about then.

Andy Hunt: Yes. Beginning of '98 I think it was.

Dave Thomas: Right. And it took, about what, two years? Eighteen months, two years?

Andy Hunt: Yes. A year and a half, of mostly full-time. So we stopped consulting at the time and worked full-time on the book. If you've never written a long-form work before, if you've only ever written emails or blog posts or articles, it's quite a different experience when you're working on something that's going to end up being 200, 300 pages long. We could have possibly done it faster or more efficiently perhaps.

But, you know, Dave and I would literally get into heated discussions over individual words, over the structure of a sentence. Not because we're just both control freaks. Although, I mean, okay, there's maybe a little bit of truth to that. But, because it makes a difference. You call this name that thing or you call this something else, and suddenly, it makes a difference to people. It makes a difference to readers.

We even had to put some disclaimers up front in the preface saying, "All right. We're going to use a couple of words a little differently from common usage. And, here's why." So, we really kind of tackled it at a very fine-grained level because we really wanted to get it right. You can push patches and releases to software a lot easier than you can to a mass market, hardcover, or paperback book. So, we really kind of wanted to get it as right as we could with what we knew at the time.

Dave Thomas: One of the other reasons it took a long time is that we settled into a scheme. We tried initially to write the same section together, and that was just miserable. So, instead what we would do is, one of us would write it. Then the rule was, you handed it to the other person, and if they loved it, you were done. If they had just minor changes, okay, you'd make them. If they had major changes, then suddenly it was their responsibility, and they would take that section on, and then pass it back to you to do the same thing. We had sections that probably went through that process five or six times.

Andy Hunt: Probably. I mean, not a lot, but there was a handful, where they were clearly problematic, trying to find our right voice and really articulate what we wanted to say well.

Dave Thomas: So anyway, the original question was, you know, "Why did we do it?" And the why was that we wanted to get just some of these what we thought were pretty basic ideas out there. And, we finished. We published it. That was kind of about it. We're not marketing people, and we didn't get out there and like you know, do the book tour or anything. But, it just kind of caught. It was kind of interesting to see what happened. And fairly quickly, it got to be quite a popular book, which surprised us.

And as a result, well, as a result, we met you, fine folks. Because, once that happened, we started getting conference invites. I believe the very first conference Andy spoke at was in August 2000. Wasn't it?

Key takeaway no. 1

The Pragmatic Programmer started life as a primer to help teams get on the right track before Dave and Andy came on-site to fine-tune the process.

What happened after the book was released?

Andy Hunt: I believe so, one of the early, like a second or third JAOOs. It was quite early in the game.

Dave Thomas: We were up in the balcony. In fact, that was also the conference at which I learned to take my shoes off when I was speaking. Because, you put us onto a makeshift stage, which I think was made out of old fruit boxes, and it was very, very squeaky. So, I took my shoes off so I didn't make as much noise. I discovered that I speak better with my shoes off. I think I'm more connected to the earth, or the fruit boxes, or whatever. So, anyway. So, that was that.

We then got involved in the "Manifesto for Agile Software Development", which is turning out to be a relatively controversial thing nowadays. And then we basically just got back down to doing development for a while.

Andy Hunt: Well, and we did more of our writing, because right about then too, we were working on a project for a client. And it was a sort of data mining market-y thing. The situation being what it was, we needed something that was sort of like Perl, in that you could get in there and put together the prototype really fast, and get fast feedback from the client and turn it around really quickly. But, Perl, especially at the time, had really no nice features for encapsulation or object orientation.

So wouldn't it be nice if you had something kind of like Perl, but cleaner and easier to work with? We hunted and looked for a fair while. Every couple days or every week Dave would send me a link, "Hey, what about this? I stumbled across this thing. What do you think?" Well no, that has this wrong with it, or I don't like this aspect of it, or whatever. You know, programmers are very particular about their programming language.

Dave Thomas: Yes. But, you still use vim, so you know, what can I say?

Andy Hunt: Yes. Old habits die hard. So, one day Dave sends me this link to this thing that he stumbled across out in Japan, called Ruby. I'm looking at it going, "Hmm. All right. This looks promising. This could be something." One thing led to another. We loved the language, right out of the gate, we thought this was ideally what we needed for this particular client, but also something we could use in general, you know, one of our consultant's secret weapon chest.

But, the drawback was, there was no documentation on it in English. The only doc that existed was in Japanese at the time. Neither Dave nor I speak any Japanese. Although, I think you tried to learn it at some point.

Dave Thomas: Oh, I gave up. My head just can't handle it. No, it's funny. I have this problem. I can't hear things properly. I can't hear English properly. If I'm at a party, I have to lipread. I can't literally hear what the people are saying. I could not differentiate the sounds in Japanese. I tried the same with Chinese, exactly the same. I could never learn Japanese.

Andy Hunt: Fortunately, as we're reading through the Ruby source to try to find out, okay, what does this actually do in the circumstances, we were delighted to find it was very well written, very concise. You could literally just follow the chain of execution and get a good understanding of what the language was doing, at a fundamental level. So, I forget how it came about, but somehow one of us got the bright idea that, hey, maybe we should just write a little tiny language reference for this cool new language.

Dave Thomas: That was because we had an idea for another book. We wanted to write a book on executable design, which nowadays would be called, I don't know, cucumber. And, we were looking around for a language in which to express this. And, the language we turned up with was Ruby. And, we found that when we started writing all this stuff about expressing your ideas in code using Ruby, we'd spend a lot of time explaining the Ruby code, and not the actual subject of the book. So, we thought, "Well, let's separate that out, and create a separate thing," which was kind of like, I think the initial idea was going to be like a couple of appendices which were describing the Ruby language.

Andy Hunt: It was going to be small.

Dave Thomas: Yes, it was going to be small. 600 pages later, we kind of finished that. So yes, I guess the problem is actually once you write a couple of books, I think either you swear you will never write one again, or you can kind of get into this thing where, I guess it's called masochism, but you get to enjoy the process.

Best way to learn new things

Dave Thomas: You get to enjoy the fact that you are forced. Normally, in your normal life, you take short cuts. When you are programming, you don't always understand 100% of what you're doing. This particular thread works or this particular library is good for doing this, and you just like plow through it. That's kind of not very satisfying. I much prefer to understand what I'm doing. If you're writing a book about something, well, you better understand what you're doing. So, writing books like that is a really great way of making sure you just fill in the gaps. You can't paper things over. We kind of got addicted to that. We got so addicted to it we ended up creating our own publishing company.

Andy Hunt: I just want to emphasize that, I think one of the best ways to learn any subject, is to write about it. It doesn't have to be a book.

Dave Thomas: Or to speak about it.

Andy Hunt: One of the first things I do if it's a new language or something I'm trying to figure out, I'll make myself a cheat sheet because I'm a novice at this language. How do you do an assignment? How do you call a function? How do you do concurring? You know, whatever the thing is. I just start making a cheat sheet. It's that act of writing down those important bits that so you have a reference for when you need it that information again. Then you go back and look at it a few times. That really helps kind of cement it as you're working with it now.

It's kind of an easy path from that once you start taking notes and start understanding it, and understanding the interconnectedness of the bits of the system, and then suddenly, out of nowhere a book pops out. It's not quite that easy, but it kind of feels like that sometimes.

Dave Thomas: Yeah. Mike Clark has an interesting approach to that, where he teaches himself a new language by writing tests. That means that he always has kind of a reference if you like to what he's been doing.

So anyway, many years then passed. And, it comes up to be the, what, the 20th anniversary of the initial book. And that fell in 2020, so there is a lot of twos and zeros in that, which we took to be auspicious.

Key takeaway no. 2

One of the best ways to learn something is to either write or speak about it.

What has changed in the 20th-anniversary edition of the book?

Andy Hunt: We actually got a request from the publisher, as we do every so often.

Dave Thomas: Yes. I was going to say, we get one every two years.

Andy Hunt: You know, that it's up for a reprint. They print a whole batch. They run out of stock. "Well, it's a reprint coming up. Do you have any errata that you want to address?" And then, as Dave said, we start noticing, you know, the clock on the wall. It's like, "Huh. Gosh, it's been 20 years. Maybe we should do something about that."

Getting back to I think the first question, "Why did we write the book?" The first one was to solve developers' problems that were common, the things we were seeing in the world that people were doing that, "Gosh, that hurts. There's an easier way to do it. Try doing it this way." And, 20 years later, it's been very instructive to see how much is exactly the same. Nothing has changed. You know, the names have changed. The tech has changed. But the problems, the wrong approaches, the things that cause us difficulty, are largely identical.

There are some new players on the scene. There are things that we have to worry about now we didn't have to worry about as much 20 years ago. Security, privacy, these sorts of issues.

Dave Thomas: Concurrency.

Andy Hunt: Concurrency, new technology issues. Not just new tech like a new language or a new framework, but new fundamental ways of doing things. More concurrent applications, running builds in pipelines instead of having that old build machine in the corner. So, there are the obvious tech changes. There are societal changes that have happened. But, there is an awful lot that's, it's just still us. It's still people. And, we're still making, very similar to mistakes that we were making 20 years ago.

Dave Thomas: Yes. I think that's really interesting. The biggest changes in the book are largely tech. Not being prescient. Obviously, we made a couple of bad calls with tech. Some of the references to tech we made were just totally out of date. But, I think to me the changes that I'm proudest of are the ones based on...although people are kind of the same, they're different too. People are, I think more aware of the impact that software has. Back then, software was still kind of just there. It was really important. But, it wasn't something that people, in general, talked about.

Key takeaway no. 3

Tech and society have changed, but we are still people making the same mistakes we were making 20 years ago.

Ethics in software

Andy Hunt: Well, if you were at a cocktail party and someone says, "What do you do?" You could get away with saying, "Oh, I'm in computers." And that was generic enough, it's like, "Oh, okay. Fine. Don't want to hear about it." You say that now, and they look at you like you are, you know, not quite right. It's like, "Well, what do you do exactly?"

Dave Thomas: Right. Exactly. If you think about like with the COVID-19 stuff, I think Bob Martin made the point that what we're doing now, and the way the world is handling that is to a large extent predicated on having things like this video conferencing system that we're talking over. Nowadays, there are open source versions of just about anything. That allows people to be doing things like working at home, having their own tools locally. It's an amazing world.

With all of that comes a whole bunch of responsibility. One of the things we wanted to bring out in the book is the fact that as developers we can no longer just do the old Nuremberg defense of "I was just obeying orders." We actually have to be conscious of the stuff that we are doing. Try to anticipate. We'll never be able to fully anticipate, but try to anticipate, bad consequences as well as good consequences of the stuff we're doing. There's very much a social responsibility that developers have now taken on and part of the cost. Being a developer I think is probably one of the best careers there is. I love it. But at the same time, it comes with a price. It comes with the price of continuous learning if you're trying to keep up. You have to keep up with what you're doing.

It also comes with the price that what you do is no longer just like playing in the basement and creating spirits that move around the screen. What you are doing is changing the world. And, you really don't get too many opportunities if you get that wrong. So, you have to think very carefully about the roll-on effects of what you are doing. That's something we're only just beginning to work out. I think it was important enough that that became the last chapter in the book.

Andy Hunt: Well, exactly. It's kind of funny because it reminds me of the early ages of industrialization, the stories from the factories were pretty horrific. You had young children working the machines. There were no safety mechanisms. A lot of large scale tragedies, because there really wasn't any concept of worker safety, because it was all new. As a civilization, we didn't really quite know how to handle that yet.

I think that's where we are with information technology and computer science and all. It's still new to us. The whole field is, depending on where you count from, 50, 60 years old. It's embryonic. We know nothing yet. We're just starting to figure out the impact of these things. When we first wrote the book, it was barely out of the days of you could type "vi main.c" and compile your a.out and whew, make your spirits go a couple of years later. And that was sort of all.

Now write a couple of lines of code and you could be part of toppling a government or starting a revolution or any number of things really positive or really negative. It's kind of all right there and largely under our control. We don't really know how to handle that yet. We're getting there, but we're just starting.

Dave Thomas: Yes. It's really easy to fall into the "do what's fun" trap. And quite often the problems that we're given are kind of interesting problems. How can you have a billion people exchanging messages in real-time? Not a trivial problem. And, a whole bunch of people will spend many hours trying to work through great solutions to that, without thinking too much about, "Well, what actually happens when they do?"

Andy Hunt: Well then, like in an arms race situation. Right? I mean, we've always had that with something as innocuous as spam. Someone figures out a better way to deliver a malware package to you. Then, here is a defense. And then, here's a way to get past the defense. And so on. But now, that's amped up because you can now do the incredible. It’s getting more and more realistic every day. For example, the deep fakes, where, "Did that person really say that?" Now, how do you detect that? You used AI to create this. Now, what do you use it to detect what has happened and declare that this was fraudulently made? It goes on and on.

Dave Thomas: Yes. You're right. This is actually kind of depressing because as we've been talking I've been thinking about all the bad things that could actually happen right now, given our reliance on computers particularly, as we're all encapsulated in our dungeons. So, we should move on to something more cheery. We should.

Key takeaway no. 4

Software is changing the world and we should be considerate of the impact we are making. It comes with the price of continuously learning.

The most fun part of the new edition of the book

Dave Thomas: We're talking about getting things a bit more cheerful. What is the most fun part of the new book for you?

Andy Hunt: The most fun part? I really enjoyed the fact that we were able to keep a lot of the old stories. Because, as this book first came about, a lot of the content came from things that we would do out in the field talking to customers. We'd come up with these little anecdotes about stone soup, about boiled frogs, about all these sorts of little memorable bits to help get the message across. The things that we were describing, again, we might have to change the tech a little bit, but the principles were still sound. So, we were able to keep a lot of these metaphors and colorful stories going.

And to me, that was really cool because a lot of the things that we talked about in the first edition had become part of the global conversation about programming. People mention the DRY principle literally all the time. And, that was from the first edition.

Dave Thomas: They get it wrong, but they mention it.

Andy Hunt: They get it wrong, but they mention it. And that was another good side effect of this 20th-anniversary edition. We were able to clarify things that people got wrong. So, as Dave mentioned, the DRY principle, people reduced to, "Oh, don't copy and paste." Well, it's not about that. And, you need to read the book to find out what it is about and how to use it effectively.

Things that had happened in the meantime, like our involvement with the Agile Manifesto. It pains me so much these days to see people take the wrong approach to what they claim is Agile. Literally, I've had people come up to me and say, "Oh yes, we're Agile. We do one or two Scrum practices, and we use JIRA. So hey, we're Agile."

Dave Thomas: And, "We don't write documentation."

Andy Hunt: "We don't write documentation. Yeah, baby." You are completely missing the whole point that it's about fast feedback. It's about doing something small, getting feedback, and steering. It has nothing to do with any particular Scrum or XP practices, or anything else. It's about organizing your work and getting fast feedback. That's the central tenet, the central core to it.

Initially, when Dave and I started this, I wanted to say, "Okay. Let's just not even talk about Agile at all. Let's just leave it out of the book. Let's just move on and talk about these technical and these sociological issues." But, we had to put at least a few things in there. As with the DRY principle, we tried to clear things up a little bit. It's like, "All right. Here's what this really means, and here's how you can use this effectively and actually get work done in a better way, better fashion." That's really, to me, that's the most fun part of the book, is taking a murky subject, whether it's Agile, whether it's concurrency or something else and trying to distill it and clarify it so that people will read it and go, "Oh, that's what everyone's talking about. I get it now." That to me is the best part.

Dave Thomas: For me, actually I've got to tell you something that I've just noticed. And that is, you know how people mirror other people? And, I've just noticed that when you were talking and you move your head from side to side, I'm tending to mirror your head moving. But, it's probably, when it's going to be played back, it's going to look ridiculous because I'm guessing it's going to be flipped around. So, it's going to look like I'm opposing your head.

Anyway, my most fun part actually was after the book was written. Because I have always wanted to get a Pragmatic Programmer done as an audiobook. It has always been, I don't know, a daunting job. The natural thing would be for Andy and me to read it and we just didn't want to do that whole thing. Turns out we know someone who is an actress who is happy to be the voice of the book. So we put together the audiobook using her in a kind of interesting way. She kind of breaks the idea of narrative. Because, every now and then, like the book, she will stop and ask questions and things like that, which was very interesting to do.

But, the most fun part of it, and this is going to sound so trivial it's ridiculous, but this really was fun. At the very beginning of the book, we have a story about the lawns at Eton College in England, about how they are kept so pristine. The story is about a tourist interviewing the gardener. So, I wanted to get voices for that. Now, getting an American voice for the tourist was easy. I'm surrounded by them.

But, getting a good English voice for the gardener was tough. And I thought, "Well, this is the Internet days, so we must be able to find sound ware." Sure enough, there are services where you can buy 30 seconds of someone's voice. And it's dirt cheap. I went through like maybe, I don't know, 100 different voices until I found exactly the one I want. I sent him the script. And next morning, I woke up, and in my inbox were a couple of files that had a couple of readings and different things. I just thought to myself that we really have arrived in an amazing time, where one day I can think, "I need someone with an East London accent to read this." and the next morning wake up and five dollars poorer, I have exactly that. Again, that's due to software. So, I think in the midst of all the hassle we need to be quite pleased that we are doing some stuff right.

Key takeaway no. 5

The best part of writing the second edition was being able to use 20 years’ worth of feedback to refine (and correct) what we said in the first edition.

Preben Thorø: It has been tremendously inspiring listening to you. Thank you so much for being here today.

Andy Hunt: Thanks for having us.

Dave Thomas: Yes. Seriously.

About the authors

Dave Thomas is a computer programmer, author and editor. He runs The Pragmatic Bookshelf publishing company. Dave coined the phrases 'Code Kata' and 'DRY' (Don't Repeat Yourself), and was an original signatory and author of The Manifesto for Agile Software Development.

Andy Hunt co-authored The Pragmatic Programmer, alongside several other books and many articles, and was one of the 17 original authors of the Agile Manifesto and founders of the Agile Alliance. He and partner Dave Thomas founded the Pragmatic Bookshelf series of books for software developers.

Other interesting talks

Agile is Dead- Dave Thomas