Today's episode is the first of a three-part Pragmatic Folks series and we are joined by Dave Thomas and Andy Hunt to talk about the 20th anniversary edition of The Pragmatic Programmer. This new edition was not only an opportunity for them to revise the material, but also to revisit their thinking and see how ideas have changed over the course of twenty years. Their seminal publication codified processes which people had been doing without having a vocabulary for it. An example of this is what they call rubber ducking, which is a useful technique to use for problem solving. You can either use someone else or yourself as sounding board for problems and through listening to the problem out loud, a solution can more easily be found. It is so easy to think that by continually working and not taking a break that you can find a solution, but despite being counterintuitive, getting a change of scenery or switching gears will likely help you reach the solution. They provide some tips and tricks on what you can do to switch it up when you feel stuck in a rut. For this and much more, join us today!
Key Points From This Episode:
Transcript for Episode 256. Pragmatic Folks Part 1 - Feedback Loops
[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. My co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.3] MN: Today, we have some pragmatic folks in the building.
[0:00:13.8] DA: Yeah, we’re going to be talking about our pragmatic, common-sense, programming techniques and pragmatic concepts, yeah. We have Dave Thomas and Andy Hunt who need no introduction. But, if you’d like, you can give yourselves one.
[0:00:27.7] MN: Go ahead.
[0:00:28.8] DT: I’m Dave Thomas.
[0:00:29.9] AH: I’m Andy Hunt.
[0:00:31.4] DA: Hey, thank you guys for coming on by and you know, thank you for all of your hard work on the 20th anniversary edition of Pragmatic programmer.
[0:00:41.0] AH: Thanks for having us, it’s been a really interesting and fun time getting back to the old materially old stuff, we really haven’t consciously looked at in a long time. I will read it every couple of years maybe for some reason or other, but we hadn’t been in there and working on it for 10, 15 years really.
Really interesting opportunity to go and sort of almost open up a time capsule in a way and kind of you know, voyage back to those days of the late 90s. Different languages roamed the landscape and –
[0:01:17.1] MN: Seinfeld was on the air.
[0:01:20.7] DT: It’s kind of an interesting ability to commune with an earlier version of yourself and to some extent, see how things have changed not just like in the industry but also within your own thinking. Some stuff back then that made like a lot of sense at the time. Some of it just became outdated and some of it is kind of like, you know what?
“Having thought about this for the last 20 years, I wouldn’t say it that way, I’d say it differently.” That was really quite an enjoyable part of the experience.
[0:01:49.7] DA: Yeah, I would say a lot of the concepts that are in the book also feel very brand new.
[0:01:54.3] DT: Yeah, if you actually look at the content in terms of what’s changed, there’s probably about one third of the topics are brand new that didn’t even exist in the first book. And then, of the rest, probably about 80% have been either mildly or viciously changed, depending on the kind of topic.
[0:02:13.1] AH: I think it’s really probably fair to say, I don’t think a single page, a single full page of content escaped unscathed.
[0:02:22.6] DT: Definitely not.
[0:02:24.7] AH: We had to go through and edit the low-level stuff such as the technologies that we referenced because we talked about programming languages and environments that don’t exist now and people would look at it and be, “what are you talking about? It doesn’t resonate, I don’t know what that is.” We had to change the sort of – that was a kind of a low hanging fruit, if you will to go through –
[0:02:46.0] DA: Right, that’s kind of like an obvious thing that you look at and it’s glaring but I do feel like a lot of the concepts that are in there, the core nuggets of knowledge and information. You know, I have my old copy here with me and things like rubber ducking. It’s just so common sense and it’s very strange in that it just works and having that label on it like really helps.
[0:03:13.5] AH: You know, it’s funny you mention that because both Dave and I have gotten this comment a lot over the years that we put a voice to things, we put a name to things that people sort of knew about, maybe did, maybe heard about but didn’t have any kind of taxonomy to call it. We named these things, we named these practices that we did that other people did that were common and you know, where we could, we’d put a cute story with it and make a nice metaphor, attach a name to it and that I think made a really big difference, it made it sticky, for people.
Though they would remember it so they would talk about it so it would become a more explicit, yes, this is a thing that I do, instead of the sort of tacit knowledge oral history kind of thing that just gets passed around and you know, some people do it, some people don’t and I don’t know what you're talking about, right?
This really helps sort of bridge that kind of tacit world. Yes, this is rubber ducking, these are tracer bullets, this is the dry part. This is you know, one of these other things that we sort of codified.
[0:04:21.0] DA: Yeah, for people who aren’t familiar with rubber ducking, that’s the concept that if you have a computer problem, you have a totem, like a rubber duck or just the wall I guess and you just talk to it and describe your problem and hope that it can give you the answer and normally, just by explaining it, you end up at the solution.
Or, you could also talk it out of person as well, I guess.
[0:04:44.9] DT: The idea of the rubber duck is it’s a proxy if you don’t have a person because really, it works best when you’re talking to somebody because then you put the extra effort in to think about what they’re listening to and it’s that that actually I think makes the technique work.
[0:05:01.3] DA: Right, yeah. I find that often, when I explain the problem to someone, then the solution just kind of comes to me and I’m like, “I’m very sorry, thank you for listening.”
[0:05:12.7] AH: That’s the workflow there because when you're explaining it to someone, you’ve got to sort of go one step back of your assumptions and, “oh well, did I actually check that? I think this is this way or this variable is set or this thing was called. Is it really?” The m ore you start to kind of go back to the assumptions and the things that you think, you start, “oh, of course!” It pops right in and you know what the –
[0:05:36.4] DT: Yeah, I think it’s even deeper than that though. I think that if you look at the book, there are quite a few tips that other explicitly or implicitly say you have to learn to trust your gut, trust your instincts. There’s a whole bunch of research that start up that really, your conscious brain is a really thin and relatively stupid layer.
[0:06:02.8] DA: Is that a personal insult?
[0:06:05.0] DT: No, I wasn’t necessarily looking directly here at the monitor but I mean, general, one’s conscious brain is a stupid layer on top of where the real work gets done, which is the below the level of conscious thoughts. That’s where you’ll constantly – you know, if you were a wolf, that’s where you’d constantly be looking for prey and this kind of stuff without necessarily thinking about it.
And when you’re a human being, you’re coding, you know, that’s where you’re keeping in purpose and so caught a bit of the book is about various techniques, again, explicit or implicit that help you surface that information and rubber ducking is one of those techniques where it’s like – I’m sure everybody here has had a problem when you go to sleep with this problem going around and around your head and in the morning, you wake up and you know what the solution is.
It’s like, your brain worked it out while you were sleeping, there was no conscious thought involved, but you actually managed to surface the thing. The same thing happens when you’re rubber ducking. Because as you’re talking and as you’re explaining stuff, something in your brain is kind of like almost like you’re two people, the fact that you’re speaking means that it comes out your mouth and back in your ears and your brain is listening to that. No, I’m serious.
[0:07:19.5] MN: Yeah, no, I never thought about it like that but yeah, that’s why I’m laughing because it just makes so much sense.
[0:07:25.4] DT: Something your brain is listening and the fact that it’s listening means it’s triggering all of those neurons that would get triggered when it was listening normally. And then you get the associations for me and it’s dragging out of your subconscious. All these things that you actually know, but you actually can’t get to.
[0:07:41.3] MN: It’s all about those agile feedback loops. It’s the tightest feedback loop, just talk to yourself.
[0:07:47.9] DT: Here’s a fun tip for you right? You know, talking about this sort of rubber ducking thing and listen to yourself. Do you ever notice that you get these great ideas in the shower or on the commute on the way home or somewhere where you're not in front of your keyboard?
There’s actually an interference mechanism there when you’re sitting, typing at your keyboard and trying to have the sort of breakthrough, this sort of thought, it’s not going to come as easily. The instant you step away from the keyboard and walk away, I mean, have you ever had that happen? You’re walking down the hall, walking out to your car, it’s like, “of course, it’s whatever.”
[0:08:22.8] MN: Yeah, I’m a big believer in like Pomodoro method, just like doing 25 on five of because like, my brain needs that to be great.
[0:08:30.2] DT: Yeah, I think that there’s two aspects there, the Pomodoro is kind of like recharge yourself a bit and yeah, there is the benefit of the gap in there but the – even when you’re in the middle of a 20 or 25 minute, whatever you do sprinting here. I think it’s still important to be able to kick back and learn techniques that let you not consciously focus on stuff. I mean, when you think about like great athletes and stuff, they are not consciously thinking about where they put their feet, you know? And there is a really interesting, I can’t remember who it was now. There is an essay about a basketball player and he was one of the greats and his big thing was he could pass behind himself and he would know a player was there. And people asked him, “how do you know that when you throw that ball over your shoulder there is a player there?” And he was like, “I have no idea. I can’t tell you.” Right?
There is no conscious thought going into it and one of the reasons that we say get good at using your tools is that when you get to the level where you don’t have to think about how do I delete this word or whatever it might be, you’re freeing your brain up to kind of like day dream a little bit in the same way that the basketball player isn’t thinking about his feet and by doing that, you’re leaving it kind of surface in the midst of your regular work.
[0:09:55.8] DA: Yeah, it feels a little silly, but some days I’ll get in and I’ll do a little typing exercise on typeracer.com or something and I will try to beat some people in typing out some words and it really helps a lot because then the words flow and then you know I feel more connected with the computer and I am not touch typer by any means. I am not perfect but just getting that muscle memory in and getting some of the automated thing.
[0:10:23.2] AH: You are describing that as a warm up exercise get going. I think it is important here even with the Pomodoro, if you’re sitting there slaving away, stuck on a bug, stuck on a design decision, you know you are not getting it, you are not getting a break through, you’re not getting an idea, step away from the keyboard. Just stand up, turn in a circle, put your feet up, close your eyes.
[0:10:43.6] MN: I walk around the office, if possible.
[0:10:45.7] AH: Yeah, don’t walk around with your eyes closed that would be a bad combination, one or the other but you know that sort of just getting away from the symbols, getting away from the screen and the keyboard for even 30 seconds and you can find that all of the sudden stuff will pop in because you have given it that breathing room to let the asynchronous processes in your brain come to the fro. So yeah that is the hot tip for the day when you’re stacking up the problem, step away from the keyboard.
[0:11:14.8] DA: So, you don’t get to programming, don’t program.
[0:11:18.3] DT: If being able to type continuously is a measure of productivity then you know there is no need for programmers. I mean what we actually add in terms of value is the thinking part. So, stepping away from – oh, here is a slight variant on that. If your work environment frowns upon you entering a lotus position and going “ohmmm” all the time, pick up the pencil or a pen and start scribbling. So, if you are working on some problem, see if you can find a way of picturing it.
Draw boxes and lines or circles or whatever it might be and you’d be amazed at how that switch of focus helps you think about it as well.
[0:11:55.5] AH: I absolutely agree with that and in fact, it is funny one of the questions you all asked was about our favorite common sense programming techniques and something that I used to be much better at and I have kind of gotten out of the habit is just leaving a paper notebook open next to you while you’re programming and it might be you just jot down those couple of command line flags that you just looked up that you are going to need in a minute.
So, you don’t have to store it in your memory. It might be “oh, don’t forget I got to go back and check this.” Just a little note to yourself or as David was just saying, you’re stuck in a problem well, what does that look like? What if I looked at that backwards? What if that is reversed a bit? How does this connect to that and just make – I mean we’re not talking about a UML by a gram or anything. Just jot down some visualization of what you are working at.
Take a couple little notes. You know it doesn’t have to be a big formal sort of thing, but just it’s a little bit of exo-cortex there. You know a little bit of extra brain processing power and that really makes a remarkable large difference for being such a small thing, such a common sense thing.
[0:13:01.2] DT: Yeah, I got into the habit a long time ago of keeping it’s called an engineering day book but what it really is just I mean, I got a book here that I got from Amazon. I get packets of 10 of them or something and I just scribble notes in it. If there is stuff like a site that I visited that I needed to remember later on or if I make a phone call for someone and they give me a RMA number or whatever it is, I just stick it in there and now I forget about it.
Because it means that I can always go back and find it later on. But I also use it for just doodling and you know taking the kind of pictures that I was talking about and it’s invaluable. Remember the number of times you can go through the book, you’ll find half a picture, which means that halfway through it suddenly I went, “ah, okay I understand.” You know? And then move on.
[0:13:53.1] DA: Next thing, yeah, I like that concept a lot. I very specifically remember reading that section of the book, talking about the engineering practice of like competing to see who can fill the most of these logbooks and data and put them on the shelves. It sounds very satisfying having this tangible physical trace of all of the thoughts and hard work that you have put into your job.
[0:14:16.2] DT: When I was writing that section, I actually came across some of the books that I have written in the 80s and it is actually kind of stunning to see how different I was and also have much the same as I am to Dave Thomas that was writing back then. It was kind of fun.
[0:14:32.2] AH: Well some of that is actually really funny. You go back and look at some of these older notes back then and I am amazed to see how many people’s names and phone numbers are written in, you know? Some are good or some officemate or whatnot. It is just filled with phone numbers. It was so important and I am trying to think, “what is the last time I actually literally typed in a phone number for anything right?” You Google for it on your phone, you click the link. Who types the number in?
[0:14:59.3] DA: Yeah, the only time I ever have to type in a number is if I am getting on a conference call and I don’t have the link to call me and then I feel so begrudged. I feel so enraged, the entire time every digit.
[0:15:12.8] AH: It’s throwing knives and bear skins. I used to have to type, you know dial a phone, right? We still say that even though –
[0:15:18.1] DA: Right, yeah. The WiFi is out in my airplane. It’s awful.
[END OF INTERVIEW]
[0:15:23.8] MN: That was the end of part one to our pragmatic folks’ series that we currently have. It was great having both Dave Thomas and Andy Hunt in the studio. Well not really in the studio but recording remotely.
[0:15:35.3] DA: In spirit.
[0:15:36.4] MN: Oh yeah, in spirit. It was great. The one thing I want touch over is the idea something that I learned from speaking to those individuals is the idea of how important doodling is. I thought that I need to have a notebook next to me now just so I can just write some things.
[0:15:52.3] DA: Yeah and you have an excuse to be like, “I am just using my brain.”
[0:15:55.6] MN: Yeah, I’ve got to doodle or draw some – not UML diagrams per se, but I thought it was really interesting to be able to write out the path of the development of the work that you’re doing and I thought that was very interesting that I haven’t done in a very long time. So, I need to pick up the habit.
[0:16:12.1] DA: Yeah, I enjoyed learning how the most agile feedback loop is just talking to yourself. Just listening to yourself speak.
[0:16:19.1] MN: Like a crazy person but that’s okay. We’re all crazy and that’s all right.
[0:16:23.9] DA: Yeah that is how we got there. Yeah so, the first of three parts of the pragmatic series that we have, the pragmatic folks series. The second part looking forward to it. It is going to be about owning your environment.
[0:16:35.6] MN: Yeah, it is up to you as a programmer to own your environment.
[0:16:39.0] DA: Yeah, shape it. That is a good discussion and then the last part we get a little more dogmatic.
[0:16:45.7] MN: Oh yeah.
[0:16:46.0] DA: We talk about things that we will not leave on the table and just cap it off.
[0:16:50.5] MN: Exactly.
[0:16:51.6] DA: Okay, so if you are excited to get your hands of a copy of the 20th anniversary edition of Pragmatic Programmer, you can head on over to pragprog.com. The ebook is available right now and the hard cover will be available in late September or early October. If you buy the ebook on the website, you’ll get a coupon for half off on the hard cover, which is kind of cool.
[0:17:18.6] MN: Yeah, I think they had mentioned that that was highly requested. People who purchase the book in 20 years, you have to wait for that hard cover. It’s crazy.
[0:17:28.0] DA: You going to have to wait another 20 for the next edition.
[0:17:30.3] MN: For the steel cover. I guess it’s the steel cover. If you want to contact Dave Thomas, he is @pragdave one everything including Twitter. So, you could follow him on Twitter @pragdave and Andy is @pragmaticandy on Twitter. So, follow him there and if you want to find out what he’s currently doing, he has a blog. It is toolshed.com.
[OUTRO]
[0:17:55.3] 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:
