On the final episode of our three-part series with Dave Thomas and Andy Hunt, we discuss the nuanced nature of programming and why the idea of a “best practice” is often idealistic and not equally relevant to everyone. When it comes to solutions and approaches in this industry, there simply is no such thing as a one-size-fits-all as each context is different and has its own unique set of circumstances. For this reason, programming teams should aim to be open-minded and adaptable in terms of how they do things, particularly because there are always newer and possibly improved ways of doing. Development is not a linear process and we talk about the need for programmers to know what the intentions behind decisions are so that all role players can be on the same page, serving the same vision. We also discuss sloppy code and the problems associated with unresolved problems and then we get into Dave and Andy’s favorite aspects about their book The Pragmatic Programmer. Be sure to join us for the series wrap-up!
Key Points from This Episode:
Transcript for Episode 258. Pragmatic Folks Part 3 - The Dogmatic Developer
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.1] MN: Today, it is part three of the Pragmatic Folk series. The dogmatic developer.
[0:00:16.8] DA: Yeah, the final chapter.
[0:00:18.7] MN: What are things that we must have on the table, what are some things that we will follow and what are some of the problems of said dogmatic developer?
[0:00:27.9] DA: Yeah, maybe you shouldn’t wear your seatbelt on the burning plane and other important bits of wisdom from Andy Hunt and Dave Thomas.
[0:00:38.4] MN: Yeah, I think you may have heard this before in time but the answer to nearly every developer to a question would be, it depends. We get to learn and have more context on why that answer is a beautiful answer to give to any question that you may need to answer.
[0:00:56.5] DA: Cool. What are some of the techniques in this book that you wouldn’t be pragmatic on that you wouldn’t leave on the table, or just run the other way? You know, for someone to now verging and troll, just get out of there.
[0:01:08.5] DT: The only thing that I would run away from is a team that said, this is how we do it, we know what works for us and we’re going to do it this way until we die. Anything else is totally fair game. If a team says, I don’t want to use version control, I say great, good, try it and see how it works because for all I know, in their circumstances, it might work better, who knows?
I for example, I get into a lot of trouble. I don’t do anywhere close to as much unit testing as I used to do. I stopped doing it for a while to see what would happen because I wanted to experiment to see if it was actually is useful as I thought it was. I discovered it didn’t make much difference. There are things now that I definitely have learned I should test and I do put testing for that.
But I’m doing a lot less. Now, that’s me in my particular circumstances, it doesn’t apply to everybody but it’s an example of where a lot of people get this religion, right? There’s a best way to do something.
[0:02:13.2] DA: The dogma.
[0:02:14.0] DT: The dogma. There is every single – whenever anybody says “best practice”, they’re lying.
[0:02:22.8] AH: We try to tell folks every time you say “best practice”, a kitten dies.
[0:02:27.7] DA: No. We just did the opposite of doggie best practices on our chart board.
[0:02:35.1] MN: That dog is gone.
[0:02:37.4] DA: Don’t tell me that.
[0:02:38.6] AH: You might say – you know what? That’s why it’s called dogma. It’s like saying, how long is a piece of string? You say, this is a best practice. That’s almost meaningless because best practice for who? Under what circumstances, right? There’s not such thing as best, this is engineering, right? At its heart? There’s tradeoffs and consequences.
[0:03:01.2] MN: That’s the perfect engineering answer too. It depends.
[0:03:06.3] AH: It does, it absolutely depends. You know, the people who don’t use version control, it might make perfect sense in their context, in their environment, right? There’s almost no rules that are absolutely in violent, well, you say, you shouldn’t run a red light. Generally, that’s true. Unless you’re driving the ambulance. But then, there’s a protocol for that, you’ve got the flashing lights, you’ve got the siren, there is a way to do that that makes sense in that context.
You should wear your safety belt, the seatbelt on an airplane. Normally, that’s true. There was one very funny time, I don’t know if Dave remembers this but way back in the early –
Denmark? I think it was Denmark. We have done a conference and we’re climbing onto this little sort of prop jet kind of little tiny plane and everyone’s getting on board and putting their stuff in the little minuscule containers and what not and the steward gets on the phone and says, please don’t buckle yourselves in yet, we’re still refueling the plane.
The implication being, you might want to leave in a real hurry if things go sideways. Again, here is a quote best practice you should wear the seatbelt. Well yeah, not always. It depends on the context.
[0:04:22.4] MN: I think it does depend on the context, but I do think like the idea of best practices is like, it worked out for more than average of a given situation but I do agree in an airplane scenario where if you’re flying, you put the seatbelt on but don’t always put it on unless you’re told to do so. I just think that when the word – I guess, best practice is used, it’s like it worked for many people. We shouldn’t think that it will work for you and your particular.
[0:04:54.4] AH: You got to qualify, well, it worked for this size company, this kind of team, this personality. You have to qualify it with where is this known to work and are we doing the same thing, right? One of the arguments we make in the book is, you’ll see people these days saying, “We want to be like Netflix”, okay great. Hundred thousand servers and we’ll talk. I mean –
[0:05:18.2] DA: Right, what works at Netflix, that’s a Netflix-shaped problem that they’re solving, it’s not a you-shaped problem.
[0:05:26.5] AH: They didn’t do it that way when they were smaller or when they were starting or five years ago and they won’t do it the same way five years from now. That’s the whole point. That gets back to this whole thread of being dogmatic versus pragmatic, right? We didn’t call this the dogmatic developer, right?
[0:05:46.5] MN: I would buy that book too though, if you guys want to write that.
[0:05:48.9] AH: The staple first, we’ll put it on. This is the trap that it’s so easy for us to fall in to because you get comfortable, you get used to your tools, your language, your methodology, your way of doing things, the TNE reports you fill out. Whatever it is, you get used to it, you get comfortable with it and then you really don’t want to change. Change is mentally expensive. You have to throw out your old models, relearn new ones and somewhere inside your brain, a little manager is saying, dude, that’s expensive, I don’t want to –
[0:06:23.1] DT: It’s worse than that, because if what you’re doing is following the rules but then it’s not your fault.
[0:06:29.9] AH: Yeah, exactly, good point.
[0:06:31.9] DT: If what you want to do is to try to change stuff, then if you’re in an environment that punishes mistakes, you’re not going to do that, you’re not going to make changes. There’s a nice quote, something along the lines of perfect or perfection is the enemy of good. It’s so true that if all you’re doing is you’re assuming you’ve reached some best practice, if you have perfection, then what you're really saying is, nothing is ever going to change.
If this is perfection, then it will be foolish to consider any other way of doing things. You should always be saying, this is just the way I’m doing it today and I want to – You know, any time you find yourself doing the same thing in terms of like a process or a technique, whatever else. For I don’t know a month, choose a timescale. Then deliberately change it.
As long as you have feedback in place to say whether the change is better or worse, change it. See what happens. If it’s worse, okay, you may have put yourself back half fa day or over a two-week span. If it’s better, you may have learned something or make you more productive for the rest of your life.
[0:07:47.1] DA: If it’s worse, you may have learned something about why it’s worse too, right?
[0:07:49.8] DT: Exactly. I was actually reading a quote about the guy who developed the – during the Second World War, the German Luftwaffe was bombing English cities and the English needed early warning radar and they actually were very lucky in that it just invented the technology but it was brand new and really flaky.
The guy who actually kind of ran the project told his team, explicitly, that they have to develop imperfect equipment. He said, the actual quote he had was “Give them the third best to go on with because the second best comes too late and the best never comes.”
[0:08:33.2] DA: Yeah, I totally feel that and for me, that’s one of the things I really like about pair programming because if I am by myself then I could find myself in that trap and that’s a good way, having someone else there who is like impatient with me is a good way to jigger me out of that mentality.
[0:08:50.1] DT: Again, this is a good reason why you need to have this continuous discussion with the users because it might be, we need it tomorrow, I don’t care how rough it is or we’ve got six months, this should be beautiful, this should be pristine, you know, we don’t need it till then. Okay, fine, whatever. It just depends and you got to find out.
[0:09:13.0] DA: Right, have that conversation at least. Don’t assume.
[0:09:17.0] AH: There’s a great phrase military, commander’s intent. Commander’s intent is the idea of that trying to ask the questions and find out, all right, what is the actual goal we’re trying to achieve here? Because the commander might say, we’re going to take that hill, well great, are you going to throw all your men at it, throw all the infantry at it and try and take it? Then suffer great casualties?
Well, no. The reason we want to take that hill is it’s a diversion because the real action is happening over here somewhere. Okay, now we have a different strategy. We’re just going to make some noise, we’re not going to you know, take any risk, lose any lives, you have a very different strategy, very different decisions to make because the intent of the action is different. Even though the actual – you know, the requirement if you will is still, take that hill but the intent behind it is very different and now you make very different decisions.
[0:10:07.0] DT: It allows people to make decisions.
[0:10:08.7] AH: Yeah, absolutely. That’s the key point. Again, this kind of linear notion of development of we just tell you what to do and go type it, that has never worked, that’s not the model, that’s not how it functions. It has to be a conversation and the developers have to be – have to have this awareness of how this conversation, have to know the intent so they can ask the right questions.
[0:10:31.5] DA: What are some things that you think have changed greatly from between when you wrote the book initially or and when it’s come out now. Is there anything that you had to like throw out completely?
[0:10:44.0] DT: Absolutely. We threw out some low level stuff but I think one of the ones that struck me the most was at the time, the internet was shiny and new and it was a big thing and literally, the copy edit style of that period said you had to use a capital I for internet because it was a thing.
[0:11:06.4] MN: It’s like a German noun.
[0:11:08.5] AH: Yeah. Something like that. You know, there were some – I hate to say it but there were some mildly embarrassing sections of the book where we would just like, “this internet thing is great, you can download languages and run them on your own computer and it’s all free and you’ve got this community and you know, isn’t this wonderful and” –
[0:11:29.4] MN: It was wonderful, yeah.
[0:11:30.8] AH: It’s still wonderful but now, you can do a ripple of any language you like right in the browser.
[0:11:37.0] DA: Yup.
[0:11:39.6] AH: Download it, you know? It’s not a capital I anymore, it’s just the net and –
[0:11:46.9] MN: Just Google things and —
[0:11:47.8] DA: It’s just in my pocket, you know?
[0:11:50.1] AH: Sure. That and the whole – everything that came with that you know, it’s easy enough to say okay, that’s the – it’s been a big change, the ubiquitousness, the pervasiveness of the net. But even just looking at not having that build machine sitting all dusty in the corner, being able to drive deployment through version control which of course you have. Just you know, getting a tag and then some machine in the cloud for Western Virginia is the case maybe.
Since they’re in compiles and pushes it and just all, it’s all off and done and you know.
[0:12:25.3] DA: Yeah, the cloud is a magical place. West Virginia, yeah, exactly.
[0:12:30.4] AH: Everything associated with that is just that has been a really, I think, a really huge c-chain of just the ubiquitousness of the net and being able to do that kind of thing. I mean, you couldn’t do it 20 years ago.
[0:12:44.9] DT: But, at the same time, we have a section and the underlying message is don’t program by coincidence which is don’t consider a program finished if it’s suddenly miraculously started working and you’re not 100% sure why. At the time, you know, there are many examples of that and one of the examples in the original book was when you were using Microsoft Windows early versions like 3. Whatever.
The sequence that you needed to get out some graphics actually on the screen, very much dependent on your context but you were basically invalidating rectangles and refreshing and kind of stuff and there were probably a dozen separate calls that each had some influence on there. I remember times. I mean, the actual thing in the book comes from my personal experience where I would sit there and I do invalidate nothing happened.
Saw that in an article and another call and another call. Suddenly, it would just bust into life. I would have no idea why, you know, what did I do? But, I felt I didn’t have the time to investigate and so I would just like leave it like that and move on and the next time Ii wanted to draw something, I would cut and paste a six random lines. Yes, now move forward to 2019 and we have exactly the same thing. It’s called stack overflow and developers just sit there and you know, many developers job is basically like people doing patchwork quilts. You know they will get out there and get scraps of code and they’ll stick them together and if they work, it’s a miracle and God help them if they ever have to change it.
[0:14:23.7] DA: It’s artisanal. You can’t change it. It is just a beautiful tapestry. It’s perfect as it is, it’s art and that’s what I like to say when I see a method that’s 300 lines long. I’m like, “That’s just art right there” good job.
[0:14:37.6] DT: Oh man.
[0:14:38.7] AH: Change in functionality in that I wouldn’t want to.
[0:14:43.1] DA: Yeah, I had a thought.
[0:14:44.6] AH: Half report of nothing that just trans native, a piece of code David and I saw years and years ago where the fellow had a 60 page four loop.
[0:14:56.1] DA: Double spaced?
[0:14:58.5] AH: Right? If you printed it out on actual paper it was about 60 pages of code. So that’s – what would that be? Maybe 3,000 lines. That was called the beetle math but you know?
[0:15:10.4] DT: It was 11,000 lines from beginning to end.
[0:15:13.4] MN: Ooh, no.
[0:15:14.0] DA: It was the best of times.
[0:15:15.1] AH: It was the worst of times. I mean to go to a log cabin that my father built.
[0:15:21.4] DT: Think about it, I mean yes that’s horrendous but it also means that somewhere there is a team that produced a compiler that actually successfully compiled 11,000 lines of code, which is really pretty miraculous.
[0:15:34.9] MN: Yeah, oh man.
[0:15:35.4] DA: Yeah, I mean I understand where that comes from where like you’re afraid to touch anything. So it is just whatever is there stays there and my stuff is over here and design patterns and things like that I guess arose from the need to standardize the way to interact with them windows and gooeys and things like that in a more sane way than copy paste and replicating the behavior and like the open closed methodology where you don’t have to modify your existing code nor to making up yours.
[0:16:10.0] AH: But you do. Of course at the end of the day you do and even your own code, I mean it does take a certain amount of courage to say, “All right I could just both this little thing over here on the side and ignore this big stinking pile here in the middle”, it takes some courage to say, “No I am not going to do that. I am going to fix this” or try to or die trying you know? What you need you know, I can’t say always do that. You know charge the hill man, take courage.
No, I mean it depends obviously but you know where you can. If you have a choice between just staying to my little thing over here or fixing an obvious problem, yes you should try and fix the problem and this is something we talk about in the book with the broken windows because if your project has these things that everyone knows is broken you know this isn’t a case of you just disagree with someone else’s approach but everyone knows this thing is broken and everyone is afraid to go in there.
Because it is dark and scary and you don’t want to fix it, you know that is a broken window. Then you break something else, it’s like, “Well okay, that’s okay we just add this to this bucket.”
[0:17:14.6] DT: Yeah but you see it is not just a broken, that is an entire derelict apartment building is what that is. The broken window is the first three lines of code that somebody writes that is clearly bad not bad in terms of they are a bad programmer but it is going to lead to problems and they say, “Okay I will live with that because it is only three lines of code and I am really busy at the moment and I got a deadline” and blah-blah-blah and so they’d leave that code in there.
And then the next person comes along and they go, “Ugh that’s pretty ugly but it is not my code. I am not going to fix that right now because I got other things to do. So I am just going to add another three lines to it” and you know, you go from one broken window to two broken windows through an entire apartment block on fire.
[0:18:01.1] DA: Yeah, we had a podcast episode with a friend of ours called “Death by a thousand ifs” that is one of my favorites but I’m like, “Oh I totally get it” it’s like what’s another if statement? What is the worst thing that can happen?
[0:18:13.5] AH: Ifs later.
[0:18:14.3] MN: Yeah, a thousand ifs later.
[0:18:17.0] DA: Yeah that’s it. Game over.
[0:18:18.6] DT: Yeah, I like that one because I teach them classes and when students start doing things with if statements I say, “Okay, so think about this, how many paths to your code do you have to tests if you have no if statements?” and they say one. Okay, so you have one if statement, they say two. I said three if statements, they say four. So I say 100 if statements and their eyes glaze over you know? So it is really important.
[0:18:46.2] DA: Yeah, don’t even get to a thousand.
[0:18:47.9] MN: Yeah don’t get to a thousand please.
[0:18:50.3] DT: Into your overflow.
[0:18:51.3] DA: But it really is also like pervasive psychologically like I was working on a code base that wasn’t that large but people were just so afraid to work on it and I put a bunch of effort into refactor it and even after it’s been refactored people are still afraid of it. They are still like, “I don’t trust it” but it’s like, “It’s okay now, you can change it” it makes a little more sense but you know?
[0:19:13.6] AH: Well I mean there is actually a real psychological thing. Fear is contagious. You know it is one of those things and if you’ve had this thing that people learned to avoid because it is a horror, yeah you can tell them we refactored you can even show them but that kind of mental scarring is still there. It’s like, “Oh that’s” –
[0:19:31.1] DA: Yeah it’s true. I don’t live through the late nights that they had debugging problems with the old situation.
[0:19:36.0] AH: And that is why you don’t want to let that snowball start. When you detect those first three lines of code, you got to nip it in the bud. Fix it right there because it is all too easy just to add to the pile and then when you find the pile, it’s like, “Okay guys we got it. We have to fix this. We got to take care of this” because it is not going to get smaller. It is like a tumor right? It is not going to get smaller on its own.
You got to go in there and have the courage, have the strength to proactively take care of it or it is just going to get worse.
[0:20:06.0] DA: Get the options.
[0:20:06.9] MN: So Andy, Dave your favorite section of the book, if you could give us one point or one part of the book that you want every single person to learn out of it, what would that be? Andy, go first.
[0:20:19.5] AH: Well, it’s again trying to pick your favorite one is like trying to pick your favorite child. I love them all, I love the old ones, I love the classics, I love the new ones that we put in and my pitch will change on any given day but I am going to go with one of the new ones, which is “Don’t outrun your headlights”, which is a cautionary tale of programming within your means. If you’re coding thinking, working at the very edge of your abilities, you’ve got no head room.
You have this no room left if it goes wrong, you don’t have any intellectual strength left to fix it, to debug it, to work at it. You can’t fortune tell. None of us can see the future and if you can, I’d like to talk to you a little bit later about the stock market. You know as a species, we are terrible at fortunetelling and yet, we try to do that at all the time. We’re trying to see father than our headlights go metaphorically speaking.
So I think today’s favorite tip is don’t try to guess farther than you can see. Don’t outrun your headlights. Stay within your abilities, stay within what you can test, what you can figure out, what you can get feedback from and if you can’t get feedback from it, it is probably not something you should be working on or talking about yet.
[0:21:37.4] DA: So if you don’t have confidence that the test is working, if you don’t have confidence that the system is working, you have vlogs or metrics or shiny dashboards or something like that then you are probably in the dark at that point.
[0:21:49.5] MN: Dave, do you have a favorite part as of right now on the book?
[0:21:53.7] DT: I do and this is going to sound weird because neither of us wrote it.
[0:21:59.6] DA: That is actually a good thing right? Your favorite thing is the thing you don’t have to work on.
[0:22:02.6] DT: Favorite part of the book, actually probably it is the foreword. We were very, in the original book, Ward Cunningham was kind enough to write a foreword for us and at the time, he was a very established figure in the industry, very well respected and we were very, very lucky that he agreed to do that but going forward, the important thing certainly to me I think to both of us is that what we are writing here is like living advice.
It is not just like too old codgers sit down and say, “Back in my day, this is how we did things” but instead we really want to inspire all developers and particularly new developers to try and do this and so, we were really lucky we got Saron Yitbarek, which I think have you guys interviewed her yet?
[0:22:47.4] MN: Yeah, we have.
[0:22:47.8] DA: A friend of the show.
[0:22:48.9] DT: Yep, she’s fantastic and her life is dedicated to supporting and encouraging new people entering the industry giving them the tools and the perspective that they need to succeed and so when she wrote the foreword, first of all we were very lucky that she agreed to do it, but her foreword is actually very I think on point when it talks about the issues of being a new developer, and that’s exactly what it was that motivated me at least to update the book.
[0:23:21.0] DA: Cool, awesome I am digging it.
[0:23:22.2] MN: How can people acquire the 20th Anniversary of the Pragmatic Programmer?
[0:23:28.4] AH: So the 20th anniversary edition was available in e-book as of May 8th 2019. You can head over to pragprog.com and find it from there. You can purchase the e-book, which comes in PDF, ePUB and Moby formats. It will be out in hard cover late in September, early October sort of timeframe in stores a little bit after that and this time, the first edition was paperback but one of the comments that we got over the last 20 years was kind of a funny complaint.
People would be like, my copy is so battered and dog eared and it’s got pages turned down and sticky notes and I’ve loaned it out to friends who drove over it and it’s got this things happening. These are some well-lived books, copies out there. We figured we give it a little bit more armor, a little fighting chance this go around and so the 20th anniversary edition is a lovely hard cover, out in the fall.
If you purchase the e-book now, you’ll get a coupon for half off the hard back when it’s available and there’s details on our site about that.
[0:24:39.4] DA: Yeah, we’ll definitely put the link in the show notes.
[0:24:42.0] AH: Yeah Dave, I have mentioned to the COO of Stride that we were going to do this interview and he had mentioned that it will be required reading once it comes out at hard copy. Both fill. Yeah, it will be in the library, don’t worry about it, you're going to get a ton of orders from this side of New York. Excellent.
[0:24:59.4] DA: All the dirty orders.
[0:25:03.0] MN: Dave, how can people contact you?
[0:25:05.3] DT: They can just look up pragdave and I’m pretty much pragdave on everything.
[0:25:13.0] MN: Awesome. Andy?
[0:25:14.6] AH: I’m on Twitter @pragmaticandy. Just like it sounds. You know, Andy with a Y. Sort of like that. I’m variations all over the place where you go to my home page at toolshed.com that says what I’m up to lately and whatever fun hobbies I’ve been working on and new projects and stuff like that.
[0:25:34.2] DA: You got a pile of keyboards back there?
[0:25:36.8] AH: I do, they’re seeing me on the video feed here so I got a pile of keyboards in my office.
[0:25:41.3] MN: Pianos.
[0:25:42.2] AH: When you're sitting there and you’re stuck and you just need to go and hit some keys for a few minutes.
[0:25:46.8] DA: Start appreciate.
[0:25:47.1] MN: Yeah, the keyboard that they’re referring to is the piano keyboard, not like a typing keyboard which is really cool.
[0:25:52.5] DA: That’s important to note, yeah.
[0:25:54.1] MN: Like a programming, right?
[0:25:55.4] AH: Right. Yeah, I’ve got 12 programming keyboards here on different systems. I actually have done that in the past but that was back in the old days.
[0:26:04.2] DT: The Rick Whitman of coding.
[0:26:06.9] DA: Good stuff.
[0:26:07.4] MN: Lee hackers.
[0:26:08.9] DA: It was wonderful having you guys on.
[0:26:10.5] MN: But thank you so much.
[0:26:12.4] DT: Totally our pleasure.
[OUTRO]
[0:26:14.1] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
