This episode is sponsored by DataDog with 350-plus integrations as well as metrics, logs, traces, and APM. DataDog enables your team to quickly find and fix issues before they escalate. Visualize your microservices architecture with the service map, spot unusual trends with the log patterns view, and monitor the availability of your services with synthetics. Start a free 14-day trial of DataDog today and receive a complimentary t-shirt by visiting bitley.com slash data.dogshirt.
That's bitley.com slash data.dogshirt. Start. Hi, this is Scott Hanselman. This is another episode of Hansel Minute. And today I'm chatting with Andy Hunt and Dave Thomas, authors of the pragmatic programmer from Journey Mental Master. Now in its 20th year, how are you gentlemen? We are well. Thanks for having us. I noticed Andy, you get an Andrew, and I just got a Dave.
I mean, you know, so you know what's funny is that that's that's one of the other combinations because when we first wrote the book, it was Andrew and David because you know we were young trying to make a name for ourselves. And then all the books we've written since then have been Dave and Andy or Andy and Dave. And so we still get kind of random permutations. Is there a preferred one? I don't know. I guess my dad is Dave. So I'm afraid I got a little sloppy there. No, that's what I go by.
Andy and Dave and Andy. This is 20 years old, which feels impossible. I mean, it feels fresh. It reads fresh. Did you know when you were writing it that it was going to be a seminal work? Do you sit down and say, you know, let's write a book, but let's make it a seminal work. Or did you just slap the keyboard and it turned out that way? The only person in history who said, I'm going to write a best seller was Jeffrey Acher. And he wrote one because he was bankrupt and he needed the money.
I think otherwise it's just, I mean, you write the book, you write and you see what happens. I mean, I think both of us were stunned when it took off because for us, it was an exercise in really as much as anything else. Trying to clarify our own thoughts and put down what was to us kind of like common sense that our clients at the time weren't really seeing as common sense. So it was almost like a crystallization of a set of notes when we wrote it.
So you're writing it down to explain it to yourself. Make sure that what you think you know is what you know. Yeah, and to our clients. We kind of got, we went through a period where we were going into on-site. And just about everybody we went to. Typically as a consultant, you don't get brought in with things are wonderful anyway. But the people that we were brought into all had the same kind of problems. Their builds weren't consistent. They were shipping code that hadn't tested.
They were designing things in such a way it was impossible to change them. And so we thought, well, let's save ourselves a bit of time and heartache by just jotting down notes we can give to them. And that kind of turned into the pragmatic programmer. Yeah, I mean, the original thought was we didn't even seek out to do a book to begin with. We were just going to write a white paper. Literally just some notes just to save us a little time going into the next client.
And projects grow in scope, right? So the little white paper became more of a full-fledged book. But that was our intent. We had no notion that this would be popular at all or any kind of best seller. We were like, wow, we can actually get this printed and published. That's really cool. And we figured, you know, our moms would buy a copy and maybe a few friends, but not much more than that. It sounds like you're trying not to repeat yourself.
In this case, you're being dry because you're like, you know, people keep asking us this. We should probably just make a fac. And then we can hand it to the client when we're like, welcome, you've just hired us. Here's the, here's how we work. Yeah, basically, basically. And then as Dave said, as we started looking at that level of project, like, well, okay, we have a chance to make this fac, this white paper. What are the most important things that we could say?
You know, we don't want to waste time talking about, well, you know, you should format your code this way or adhere to the one true brace style or, you know, that level of stuff. So it's like, well, what do you want to say? And what is the most important? And how can we say that? How can we convey that in a way that people will remember it and understand it and, you know, really grok it?
Because as much as I'd love to, you can't go in and tell people you have to brush your teeth in each or broccoli. And, and you know, that, that kind of advice. It's like, yes, that's true. But people tune out. They won't, they won't necessarily hear that. Well, and if nothing else, you got to eat your broccoli and then brush your teeth. Otherwise, there's no point. Order is important. Absolutely.
Order proper. Yeah. And I think the other thing that was really beneficial to us was that at that time, we were working with a really wide variety of clients in a whole bunch of different industries, different languages, different operating systems. And so there was no one's eyes fits all. So we were kind of forced to go back a level and look at it from the kind of, you know, the meta level, if you like, of what are the underlying concepts as opposed to what are the tools?
And I think that's possibly one of the reasons that we, we were lucky with the book is that we didn't make it specific or too specific to one set of technologies. When you're working in software, and especially or object oriented software, your people are always saying, if you can name it, you can claim it. People will spend days trying to name the right class. If they get to, if they say the name right, then they'll understand it and the design will just fall out from it.
How important was it to call it pragmatic? When you discovered that word pragmatic, you didn't call it the dogmatic programmer, you named it the pragmatic programmer. When you nailed that word, was that the word that you needed or was that just a title? Absolutely. The word we wanted because, and I had almost forgotten this till I saw some interview from back in the day, but at the time, like with Twitter today, or Reddit, there was a lot of discussion on a use net on Comp.
Comp.Object and some of these other news groups. There was a long running argument slash discussion about whether programming was craft or not. All the kind of the follow on arguments. If it's not, is it art? Is it science? Is it engineering? Is this is it that? The answer is yes. It's all these things in measure. But in particular, there was a strain of thought at the time, which virulently persists to this day, that is very dogmatic.
It says, you must abide by this principle and you must do this and you must do this this way. And we looked at these and we're like, well, yeah, no, it doesn't work like that really. Yes, a lot of the time this principle can be helpful. This practice can be helpful. This paradigm can be useful, but not always.
And you need to know the difference. So we very much push deliberately against what we perceived as the dogmatic approach and approaches being pushed at the time said, no, you've got to look at things in context. You've got to be able to apply these lessons where and when they make sense. And I think a lot of that we tried to capture in the book of trying to give that sense of, you know, this is what you need to look at to evaluate.
Is this the right thing to do here in this context? You can't just blindly say, I'm going to use, oh, oh, I'm going to use functional programming or I'm going to use scrum or I'm going to use clothe, whatever it is. It has to fit the situation. Yeah, that's absolutely true. I mean, I think one thing I like to put up on slides is there's only one universal rule. And that is that there are no universal rules.
And I think that's that's very, very true. And I think one of the things that we try to be is and it's harder on our readers because what we're doing is we're pushing back on that we're trying not to say do this. We're trying to say here are the options. Here are things that other people do.
Now go work out what works for you because there are no two developers doing the same thing at the same time in the same environment, etc. So it's pretty much guaranteed that there's no such thing as a best practice.
We've been talking at my job about how to interview people, especially now that there's this new fresh generation of developers coming in and a lot of people have been pushing back on whiteboarding interviews and pushing back on how we interview people because they feel that it is asking a bunch of trivia.
And one of one of the bosses proposed that we're less interested in people who have the answers and more interested in people who know the right question to absolutely that's a really good way of putting it. And the other thing from my personal experience is that some of the best developers I've hired couldn't program at the time. I mean, nowadays you can get productive in a couple of months up to a level where you're paying back your salary.
So I think you're looking at the personality. Absolutely. I had the very same experience. One of the one of the best C programmers I ever met had an advanced degree in botany and he used to go on literally like expeditions into the Amazon to collect some, you know, where I was looking for bugs. Oh no, it's plants. I'm sure there were bugs involved, but no, it's absolutely. It's your part of personality, but your outlook, that kind of insatiable curiosity about the world.
I mean, if you're willing to go traips into the farthest jungle with headhunters, actual headhunters who like cannibals, not the scary kind who try to get you jobs and stuff. You know, if you're willing to traips out into the jungle to look for plants just because it's cool. You know, yeah, you're willing to read a few man pages, you know, look up a few things on the web, figure out how stuff works.
But it's that driving curiosity, hey, this is neat. How does this work? What's behind this? Where did this come from? Can I use this? You know, that's really the driving force, I think. Well, you bring up an interesting point here because we're here in a podcast with with with all due respect to all three of us, a bunch of older programmers. We've probably got 100 years of programming experience between us.
And Dave just said, well, you know, you can get up to speed in a couple of weeks and you know, start paying back your studying. It's interesting. It's one of those things where it's like the game of go, right, where it's a minute to learn in a lifetime to master. I'm not hearing from either of you any kind of what they call these days gatekeeping where it's like, well, you know, you need a software engineering degree and a master's thesis before you can start writing that HTML.
I'm hearing an enthusiasm for people to start programming right away and just start asking the right questions. So I let you into a little secret. I am teaching, currently I'm teaching two classes undergraduate level at SMU. Just to well, for two reasons, one of them is I want to corrupt the youth. So, you know, I'm teaching them things that, you know, like functional programming that they wouldn't get otherwise.
But the other reason is I have this nagging feeling that particularly computer science education is really poorly serving both the industry and the student in that these people are coming out of university with tens, maybe hundreds of thousands of different things. And there's a thousand of dollars of debt and yet in terms of the value to the industry as a whole, they are really not that much different to people who go through an eight week or whatever boot camp, eight month.
I guess it is boot camp in that they aren't being shown the real world. And what they're being shown is like, you know, various ideas on how to do certain things in C++ or whatever it might be. And I mean, for example, I teach people in the third, fourth year and the master's students and pretty much universally, not a single one of them has ever been shown any form of testing so far in their course. So it's, yeah, you're never going to get me saying, oh, yeah, you need a degree in this.
You know, I would much rather hire somebody who had the right attitude and who I liked and who was smart and who could talk to people and then show them how to code. I agree 100% in fact, I think it seems to me and both, you know, here's a reveal, both Dave and I have have kids in and just about to be out of college, you know, studying in these areas and looking at the various degree programs and, you know, the contents and what they teach.
I get this strong feeling that most computer science programs are there to teach you to become a professor, a teacher of computer science, you know, and not practically actually get out in the world and be a software developer to be a problem solver.
And that's really kind of disappointing. I know the, when my son went to college, they had the attitude and the introductory courses that here you were coming into college for the first time, you want you're declaring your major to be a computer science and they start with the assumption you basically had never seen a computer before.
And here's the keyboard and you know this level of instruction it's like they missed the fact that this generation has been playing on their iPod iPads since they were, you know, toddlers or whatever, you know, they're very comfortable in the digital age.
These people have had, you know, these kids have had summer jobs programming in Python or PHP or what have you they're coming in with a certain base level of knowledge and the regular programs are like, no, you've never seen one of these magic devices before, you know, starting from there.
And you know, again, in four years with everything else to trying to teach, yeah, they don't cover testing, they don't cover working effectively in a team, they don't cover things like version control that are just, you know, hygiene really I'm expect brushing your teeth. I mean, this is just how you do things. And that's, you know, often not not part of their experience.
I mean, fundamentally, I don't think they teach programming in the in the broader sense, they teach how to code in certain languages and typically that is motivated by I'm going to teach you data structures or I'm going to teach you, you know, algorithm speed or something like that. But in terms of just general good things to do when programming that never gets taught and that's a, that's a big shame.
I mean, that reflects the overall problem, right? And you hit the nail there in the head. It's like people still identify themselves as I'm a Java programmer. I'm a C++ programmer. You know, I want to go to school to learn programming. No, the, as you said, you know, you can learn that in a couple of weeks, a couple of months at a bootcamp. What you need to learn is problem solving.
How do I attack and solve this problem using technology, using computer languages, using algorithmic constructs, using, you know, development paradigms. How do I solve these class of problems? What tools do I use? That's really the heart of the matter. That's, that's the first part. But then, then that, after you get more experience than the second part is being able to recognize the problems. Yeah. And that's, that's never too.
I've been teaching my now teenager, some of the fundamentals of hygiene, the thing that came up yesterday was the importance of deodorant. And I was trying to explain to this, this young person, how important this was. And then I realized that, you know, if you don't have a person to do that, you're just going to smell. How would you know? Yeah. How, how could you have discovered that? And I think that we, we assume so much that this is, this or that is discoverable.
And that's asking a lot of someone to go and discover that when we could simply show them, hey, there's a way to do this that's understood. And maybe you could do it this way. Yeah. Absolutely. Hey, friends, summer's longer days and slower pace invite us to pick up a book, follow our questions and try our hand at something new. The work of modern software developers is evolving in ways that are both challenging and rewarding.
As a developer, it's essential that you cultivate a security mindset and to help, we've put together a collection of information security books, podcasts, blogs, and hands-on exercises recommended by Vera coders across our development security and product teams. From a just published page turner to classic frack articles, there's something here for everyone who's interested in becoming more security minded.
So dip your toes in or take a deep dive, visit www.vira code that's v-r-a-code.com slash reading. That's Vera code.com slash reading. I noticed that on the chapter three of the, of the book, you have a whole section called the basic tools and you go right off the bat and you say, look, the power of plain text. But I don't remember learning how to edit text in college. I was taught how to use punch cards. So that's almost the same. But no, I mean, again, again, it's, it's.
So, okay, here's an interesting Andy talked about his boy who went through effectively. It was basically like it was a cybernetics or computer science, small of those kind of engineering, you kind of things. My son, my oldest son took a liberal arts degree is relatively fluent in ancient Greek, some Latin, some French. He can argue philosophers until your eyes drop out.
And because I was into programming, he was vehemently not into programming for a long, long, long time. And he got out of college and discovered that there aren't that many openings for liberal artists out there in the job market. And was basically hanging around looking for for stuff to do and got involved programming an Arduino to he was trying to sense muscle tension so you could produce like an artificial hand.
And he kind of got into programming that way and decided he liked it when did a really fantastic course at a bootcamp. He's now, programming, he's been basically he's probably paid more than twice the next time his student that graduated in his class, totally enjoying himself.
And getting back to editing text, he was taught using official studio code. And he has gone through this conversion to the dark side. And he's now, you know, beating me up because I use VS code and he's saying, oh, no, no, you should be using VIM and T-mux and blah, blah, blah.
And this is someone who had really never even seen a editor until a year ago. So that side of things is, is I think there's lots of different levels, you know, and I think that that sort of thing, the editing text stuff is absolutely fundamental. But what we're trying to get to in that chapter is not so much the, this is how you edit text, but it's how the fact that if you have stuff in text, then it's accessible to all of your tools.
Whereas if instead you have tools specific data, then you're limited to what you can do by what the tool can do. And that's kind of an underlying principle, if you will, that runs through the whole book are these subtle little things that you might not think about, but that if you do them correctly, they help keep your options open in the future.
And as a species, we were terrible at fortune telling, you know, we think we're decent at it. We think we can, we know, oh, this is how, you know, this class will be extended in the future, and I'm going to build it to be maintainable and extensible and nonsense, right? None of us know what's going to happen six months, 12 months, 18 months from now.
So anywhere we can, we try to do whatever we can to be as flexible, keep our options open, right, keeping things and playing text, well, we can use it any number of ways in the future. We don't need to know what those ways are, but we're ready for it.
It's been funny now that I've got so many years doing this to watch people go back and forth between name equals value to XML to Jason and now YAML, and I try not to be the older programmer and go, you know, that's just adorable as I watch people reinvent these things as we all come back eventually to just name value pairs or, you know, I and I files as they say.
Exactly, yeah, but it doesn't just apply to things like configuration. So, for example, we wrote the first edition of the book using latte, which is basically text files, right? Yeah. And the publisher was a guest at this, they wanted us to use word. And then they were going to take the word and back then they were going to import it into frame maker and make a book out of that, of course they were.
And we said, OK, but if you do that, then how do we make changes? And they were, they were like, what? We make the changes. Why would you do that? They wanted to make the frame maker, the authoritative source and then throw away your original source. But here's the real cool thing. So skip forward 20 years, and we're going to do it again. We had exactly the same conversation with the publisher. And in the end, we are in transit in transit enough to win.
But now we're faced with the fact that we'd produced this incredibly complex latte system. And we, in the meantime, have developed our own publishing company and we actually had a pretty kick ass system around. And obviously we didn't accept latte, but it was in plain text. So a couple of rubies scripts later, a latte actually quite happily fed into our plain text based production system for the news, the new stuff.
And that's the benefit of plain text, right? You don't have to think about the future because, you know, ASCII is ASCII and is always going to be ASCII. You know, it's funny that you mentioned that I was working with in Apache Spark system recently, and it was many, many hundreds of terabytes of data, but it was all CSV files.
And some of the more, what they thought of as being more pragmatic people were having trouble understanding the scope and reconciling the size hundreds of, you know, terabytes with what their CSV files. Like, I can't open them in them, but they are giant. And but there's a benefit for that because when it's all done and it's a hundred years from now, it's the CSV files that are going to save us all.
Yeah, absolutely. Yeah. Yeah. Well, I mean, CSV is it's incredible to me that I mean, when did Excel first come out like early 80s mid 80s or something? Yeah. CSV is still the only lingua franca of business in the United States or in the world. And you know, all this talk about EDI and everything else. People just email spreadsheets to each other. Okay. So is this a truth because we are old or is this a truth and we need to teach everyone this truth because it's the pragmatic truth.
I think I think it actually it's that it is a pragmatic truth. Now if we went the other way and said, okay, this is a truth because we're old. That's where we say, well, bash scripts forever, baby. Because I've got shell scripts that are 30 years old that still work perfectly fine. And I've got code and something that doesn't work once. You've got those working. Did you? I did. I was going to bugs in them, but yeah, yeah, well done. Actually, I wouldn't call them a truth.
I would call them. It's an observation. Because a truth implies that it's my way of the highway. And you know, I don't believe that. I think that they're likely to be lots of different opportunities for doing different things in different ways. For us to date, plain text has been our savior. Which is great because it gets back to the original root of the conversation, which is about pragmatism where you might feel something is a truth.
And someone comes up with a better truth and go, okay, well, that's the truth now. But in this case here, it is a proven thing because it is just like scientific method. It's a theory that has been proven time and time and time again to be a useful thing. And this is what works. And that's really, I mean, that really probably should have been the tagline to the book. This is what works. But I think also no, no, no, it's not this is what works. It's this is what worked in the past tense for you.
You could even say this is what worked in the past tense for us. Yeah. On these projects at this time. And then here we are over specifying the specification. And now the name of the book is the pragmatic programmer. And this is what worked in the past tense for us at these specific times of these projects. We hope that you have similar success. Exactly. .com. Yes.
You made the funny joke about, about bash scripts and Dave said are those working. And that brings me to the chapter on software entropy. This idea of software rot. I am personally right now actively trying to get a 15 year old blogging system that uses XML for its back end. Up and running cross platform on all new software. And I'm just trying to get the thing to build. Mm hmm. And I like nothing's really changed except basically everything has changed. Yeah.
It's it's it's insidious because I actually had an opportunity to pull a an old. It was either an iPhone or an iPod touch. Some old bit of gear out of the drawer that was maybe seven eight nine ten years old. And I couldn't even connect to any websites on it. Oh, certificates. Because certificates because the SSL protocols have changed because you know enough little bits of the plumbing have changed that oh that's old it's insecure.
You can't even load you know modern websites on an older bit of gear. And you would think well okay got its HTTP HTML nothing has changed. Well, think again, you know enough has changed that you can't get there from here. I mean coming back to your your XML thing. The other thing is we tend to have this kind of rosy view of life was simpler back then. And so you could say well it worked in the past, you know as if it was a no brainer back then. Why isn't it working now.
But we all tend to forget that getting it to work in the past also involved downloading 17 different versions of the back some elements that you found the one that was compatible with whatever software you were using. You know always incompatible with this version of red line and therefore I got to change this and you know.
And so I don't know about you, but one of the reasons I switched from Linux to a Mac was I just got so sick of spending at least half of my day dependency managing the whole time. So you know it's it's if you imagine you had one of those systems back then that you had just managed to get working you got all dependencies right. And you hey Scott stop doing that for a month.
You'd go spare on me because you know at the end of that month right three things to be out of date and we're working 15 years to forget it. I mean you know just you know re-write it. Well so there was a Ruby script buried in the thing that apparently tidied up and did some cleaning of my XML files and it was using like Ruby 2.1.4.
So it was trying to go an app to get that version of Ruby and it's not available. So then it's like I don't know what the semantic version rules are for Ruby if I could just go to 2.1.3 or 6 or 7. And I ended up shaving the yak for about three hours trying to figure out which how to get a Ruby script to work because of versioning because of rot because of.
And of course we've all had the experience where a repository disappears off the internet entirely it's off where can't even be downloaded. But then the children the kids today will tell you that it's all about containers and I should be doing everything as a container and having my build system live.
You know basically in amber just freeze dry it in amber like a bug in amber and have my whole build system there which which is fine until you have to interface with the rest of the world like with the phone in the drawer and then the rest of the world has moved on and it doesn't matter which you got in amber you're still going to run into problems. Okay so then what's the pragmatic thing to do the pragmatic thing to do is to say that software rot is a real thing.
If you don't touch a piece of software it will gradually stop working which is kind of really counterintuitive but it's absolutely true. So if there is software that you suspect that you want to be using for a long time you're going to have to put some effort into it in the same way that you know if you live somewhere you're going to do a maintenance every now and then otherwise it's going to like fall apart.
Same thing with your software and part of that maintenance is the code but to me the most important part of that maintenance is thinking about the data.
And do I have backups do I have backups in a format that I can use if I lose the original and you know all these kind of questions are things that you're always asking yourself as part of the ongoing maintenance issue so I think the pragmatic approach is simply don't do it don't just leave a bit of software and then come back to it and hope is going to work because it won't. Well see now you feel like I need to go get my zip discs and make sure that they still work.
I think my job is here so yeah those backups on VHS tape yeah that's yeah no I actually had a whole set of backups on some incredibly expensive that storage that I bought. Right and I had like I don't know like a $1,500 of that drive and I had about I don't know 20 or 30 backup tapes and when I moved house I looked at those and threw them away because I just thought okay this is like never ever ever going to work for start had a scusy interface on it.
This is never going to work what's the point right I've never actually gone to these tapes throw them away and I think that's that's kind of like to some extent one of the things that we do roaming software is we tend to revere it too much a lot of the stress that a software if you consider to be disposable.
Yeah some bits of software like if you're writing software for a pacemaker it probably pays to get it right but a lot of software really yeah you don't have to worry that much and if you have to throw it away you have to throw it away and start again that's fine. And so I think if you could bring the cost of experimentation down and the cost of replacing down then a lot of those stresses go away.
Yeah that's one of the points we make in the book is that you know it might be better to think about writing software knowing that you're going to replace it rather than trying to invest in fortune telling say well how how might this be extended in the future how could this be more maintainable yeah let's forget that because you have no idea you don't know what's going to happen but you know worst case scenario whatever does happen you're going to have to rip this thing out so okay how can I make it easy to rip this piece out when it's no longer functioning.
Now you've got better coupling cohesion Applehood mother pie all those things right yeah just figure it's going to change in such a way that you're not going to be able to fix it great so let's toss it out throw it out right so in the context of my blogging system what I need is the 20 years of XML files and graphics I need the the blog whether it's word press or ghost or whatever I don't really care.
Yeah if I'm I went through the exact same thing as you did and I had XML then it turned into what was it textile and then it turned back into XML for a while and then it went marked out you know and the most important thing has to be retain enough semantic information in the data right I can reconstruct it and ultimately all I care about in this context of my new migration is my URLs because I drop off the end so as long as I don't change the text.
As long as I don't change that and I've got the same data hopefully it'll be a it'll be a good experience and hopefully I will be able to have the pragmatic programmer 20th anniversary edition updated how much updated is this book how much did you change is a lot's changed in 20 years we changed a lot of a lot of different levels so you know on the one hand we probably made edits at least several edits to every single page I know I know.
So I think it's a great experience to have the same language that escaped and some of that was just the low level obvious stuff right so we've been talking about corba and RMI and you know exciting new languages like Tom and interesting languages like Eiffel and right then the audience is what I've never heard of these things.
Yeah so there's a lot of technology obviously that didn't you know survived the passage of time and there were a lot of tips where the tip is still spot on like like the dry principle or no broken windows or whatever but we have found better ways to express it better ways to talk about it we've discovered people taking the advice the wrong way maybe we expanded on the dry principle a bit because that's good.
Come to mean to a lot of people don't copy and paste and it's not about that it's about duplicating knowledge so you may have a literal copy of something in two different places and that's fine because it's serving different purposes it's in a different context like we were saying before that's not a drive violation.
We had some advice in the first book of saying like well you should use metadata to push decisions out of the code so you don't have to recompile and redeploy if you just need to change some bit of configuration right great advice we had some people take that to the extreme and their application had 40,000 configuration variables in it but you told me to do it Andy.
Right exactly so you know there was there was things like that where we'd gotten feedback years and figured okay well this is something we should clarify we should you know tell the story we should mention you know a drop will cure you if you drink the whole bottle you're going to die.
Yeah so we went through and put skull and cross bones on quite a few things so we did that kind of housekeeping and as Andy said that was pretty pervasive we also took out fair few tips and instead of some nuance partly because the world has changed so for example the first edition kind of touched on concurrency but back then the idea of how to do it.
The idea of having 16 calls in a laptop was like you know Star Trek so the world has changed and so we beefed up we have a whole new chapter now on concurrency and also the world has changed in terms of socially that the the ethics of programming is becoming more important. The ethics of personal interactions become more important and so we've added content to try to address both of those things.
And in general you know every now and then it's a tip that I just really really really wanted to write you know over the over the intervening 20 years yeah well all I wish I'd have put that one in and so now we have the opportunity to put them in so probably about or about third Andy is brand new.
Probably about that and yeah some some topics weren't even a concern back then so we have a whole new section on security issue because back in the day we were just struggling to get the stuff to run right we didn't have to worry about you know deliberate attacks from bad actors locally or around the world or what it might be so you know that's a whole new landscape that I'm sure 20 years from now when we do the 40th anniversary edition
will have a lot more to say right with a whole section on AI and making sure you don't make sky net exactly exactly please don't know it'll be a whole section on how not to upset sky net right right. A big off switch you need a big off switch. Fantastic well thank you so much Andy Hunt and Dave Thomas for chatting with me today always a pleasure thanks for having us.
The book is the pragmatic programmer from journey into master and it is now in its 20th anniversary updated version there'll be links in the show notes you can pick this up it is great for everyone whether you've been in software for 20 years or 20 minutes I encourage you to check it out. This has been another episode of Hansel minutes and we'll see you again next week.