No-one likes bugs, and while we can’t entirely avoid them, there are some tried and tested techniques to squash those little pests. In today’s show, we dive into some of these strategies. While Mike’s initial reaction is denial and he runs the code repeatedly, there are other techniques as well, like writing tests, Googling, and reading the docs. These all have their merits and we delve into what they are. We also discuss how talking to a rubber duck or a toddler can help you work through a problem or even just how stepping away from the computer and hitting that mental refresh button can help you on your debugging quest. Along with this Mike and Dave, both share some of their debugging experiences and which tactic they are going to make greater use of. Be sure to tune in today!
Key Points From This Episode:
Transcript for Episode 161. Debugging Strategies
creat
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live from the boogie down Bronx. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.9] DA: Dave Anderson.
[0:00:12.3] MN: Today, we’re talking about different debugging tactics. I imagine as you’re programming, throughout life, there’s going to be a time where you run into a bug and these things happen all the time for me at least.
[0:00:24.7] DA: I have never seen a bug. But you know, I think I would find these very helpful if I ever did see a bug in a program. Like if they truly exist.
[0:00:34.4] MN: Man, no, lucky you. You never seen or walked into a bug. Bugs all the time. I’m bugging all the time.
[0:00:40.5] DA: No, no software I’ve ever used or programs has had bugs.
[0:00:45.0] MN: Oh man.
[0:00:46.5] DA: I don’t think this will be interesting episode for me at all.
[0:00:49.5] MN: Well, we’ll have different debugging tactics for you to follow so that when you do eventually run into a bug, Dave, you’ll be able to understand the different things you can do or cannot and we’ll get into that.
[0:01:04.5] DA: In all seriousness, I saw this like comic online the other day. I kind of loved how silly it was but it also like was actually very true and informative and it’s from a comic called FAS and The Furious. I guess functions as a service.
[0:01:24.0] MN: Yeah, FAS and The Furious.
[0:01:24.9] DA: FAS, yeah, it’s just titled, debugging tactics.
[0:01:31.0] MN: I mean, it has some really good point and I think we could definitely walk through a lot of them as you go throughout the episode. Shout out to [inaudible 01:42] who came up with the comic. We’ll definitely leave some information on the show notes.
Dave, you’ve never ran into a bug before so I guess I’m going to do a lot of the – what I do, what is the things I run into.
[0:01:54.7] DA: I feel like I may have taken the premise too far actually.
[0:01:57.8] MN: Yeah. You run into a bug the first time and me personally, I just don’t believe it because I felt like I write my code is perfect. So, I may – if it’s like – say I’m dealing with something – Say I’m dealing with some JavaScript, I’ll reload the page and see that something’s not happening and I don’t believe you. I’ll reload again. Command R and then –
[0:02:21.3] DA: That may be actually where I am right now. I’m just not believing that there are bugs but –
[0:02:25.5] MN: And then it’s like, “Oh, t’s still not there. Let me do a hard refresh,” and then I command shift R, that’s like the really hard refresh you want to do. And then when it’s not there –
[0:02:36.0] DA: That’s like command shift R is like, you clear the cache as well, right?
[0:02:42.4] MN: That’s like the hardcore reload. That’s when you mean business; when you hold down that shift button.
[0:02:48.1] DA: I mean, that kind of makes sense though because like, if you turn it off and you turn it back on again and it works then there’s something wrong with state. You save something and stay like the cache or in memory and it goofs you up.
[0:03:05.5] MN: Yeah, If I’m getting goofed up in that regard, I’ll make sure I write a test, figure out how could I cover that particular part so that future Mike doesn’t have to deal with that again because that would suck.
[0:03:18.2] DA: Yeah, I guess if you can reliably reproduce that situation through some different inputs or like, just doing the same thing, like 10,000 times, a lot easier to do that in a test than in person.
[0:03:35.0] MN: Yeah.
[0:03:36.9] DA: I did exaggerate before and I have seen bugs before in my life, I admit. There was one not too long ago that we’re working through where it was a race condition in like processing a status.
So, there were two database transactions happening at the same time and depending on which one resolved first, that’s like what data you would see partially but there are multiple tables involved. Different – it would be inconsistent. I was just trying to reproduce manually but after we did that, a colleague of mine wrote a test and it was like, “You’re a genius, so much easier.” Now we can just run in as much as we want.
[0:04:25.6] MN: And then the test is there to cover you. It will cover a future Dave and future colleague. Thank you future colleague or past colleague.
[0:04:33.4] DA: Yeah, past colleague, yeah.
[0:04:34.0] MN: Past colleague.
[0:04:35.2] DA: Okay. The thing that I really like about this technique area is probably like the joke in this comic that we talked about from FAS and the Furious. There’s two axes on this chart. And there’s like the Y axis is like how effective it is and the X axis is how often I try it and like, run the same code again, hope it magically works and that was like all the way on the right doing it all the time, not very effective.
[0:05:05.7] MN: At all.
[0:05:08.2] DA: Sometimes. Maybe.
[0:05:09.5] MN: Yeah, but then, say you ran the same code again and again, you run into this bug and the bug is still there, that’s where you – where you need internet access, maybe you got to go to Google, you got to check out what’s going on and you go on your Googling and you search for the bug or the issue that you have and pray that it’s on the first page.
[0:05:30.0] DA: Oh, totally. Yeah.
[0:05:31.5] MN: If you find that you’ve ventured too far from the first page, you might need to try difference set of string or sentence to try and figure out the bug more specific. I never find my answer in the second or infinite page beyond that. It’s rare that I got to go to page five.
[0:05:52.5] DA: Like click into like the seventh O in the Google.
[0:05:59.5] MN: Goooooogle. No, your answer’s not there ladies and gentlemen. You got to try different.
[0:06:01.4] DA: All the good stuff has a good SEO. I don’t know, you got like the Stack Overflow, top up there, right? It’s always there. You don’t even put Stack Overflow in there and I feel like Wikipedia like sometimes I’ll put a wiki in there but Stack Overflow is just going to happen.
[0:06:22.3] MN: Yeah, that reminds me of the times where I used to purposely install like Ubuntu like when Ubuntu wasn’t as supported as much and I needed to find drivers for my video card on an Ubuntu operating system and it would be on page five like the answer. But that would be insane, I’m never doing that again, I have a child, I want things to be fast. I’m not dealing with that. No.
[0:06:47.6] DA: Right, yeah, it should just work now, right? Yeah, I guess it’s like kind of an art, like figuring out like you’re saying, if you’re ending up in the fifth page like, somebody out there has a Google flu and they’re going to get that on the first page, they’ll figure it out.
[0:07:02.7] MN: My Google folder was not strong at that time, at all.
[0:07:06.8] DA: Yeah, you got to hone it through experience. There’s like the firstin sync, the copy of the whole error message. But like, then it’s like, well, you know, your class name’s in there and so that’s not helpful, you get no results at all for that. So you got to be like pretty smart, there’s the specific part of the error message that’s like good.
[0:07:30.6] MN: I find that and according to this comic that it can be effective and I try a lot. Like when things don’t work, I’m just going to Google and try to get the first page. Hopefully that SEO is rocking.
[0:07:41.4] DA: Yeah, even like when I probably should be bookmarking things like good blog posts or something like that, I’m always Googling it. Like there’s some CSS tricks article for Flexbox and Flexbox is great, I use it all the time but I always forget what I should be doing and you know, first page results, I’ll just Google it like Flexbox help me.
[0:08:08.5] MN: The Flexbox is definitely one of those examples where I always fudge it up and got to go to the internet to do that.
The next tactic to follow is to read the docs and I imagine that’s like the next step that I tend to go to as well. All right, I need to find out what was the developer’s intention for this to work and why am I not seeing the behavior I expect?
[0:08:32.8] DA: Yeah, I imagine you probably see the docs in the first page of results a lot of the time too.
[0:08:40.0] MN: Yeah, I imagine that the SEO for that definitely comes up. Like you would write the framework or the particular package or gem that you’re u sing and then you write the bug and then continue on and hopefully that’s like the first thing that comes up on Google.
[0:08:54.7] DA: Right, the docs and like GitHub, README or –
[0:08:58.8] MN: Yeah.
[0:08:59.4] DA: I mean, I guess like if you’re really going deep, I’ve definitely done this a couple of times where the docks like don’t quite have all the information I need so I’m like going to go GitHub and like, maybe look up the source code and look at the comments in the code like see what the method signature is. Try and dig a little bit in there.
[0:09:23.5] MN: Yeah, that’s a really good tactic because then you can definitely see what the code is actually doing, not just what they intend to do and what they say it does.
[0:09:35.5] DA: You got to be pretty mistrustful of like the library code though of like checking out that –
[0:09:41.6] MN: I mean, the library – the docs are just comments, bro. We spoke about comments lying to you and I think that’s kind of what happened.
[0:09:50.0] DA: That’s true, yeah.
[0:09:51.5] MN: The docs are good place to look for things and in the event that you may not know, may not expect the thing you want to see.
[0:09:59.9] DA: Yeah, I guess some things have docs, like the internet like they have like the RFCs and things like that that are the formal docs of how it works. But those are like pretty awful to read if you’re a human being.
[0:10:18.1] MN: This whole like – There’s a lot going on.
[0:10:20.7] DA: Whereas it is resolved. But the MDN website is basically the informal internet docs in my mind and there’s super helpful for learning like every single level of how webby things work from CSS to DNS and like HTTP requests and all kinds of crazy stuff. I didn’t even know how good the docs were there until I had to actually write things for DNS and networking.
[0:10:56.9] MN: That’s awesome.
[0:10:57.6] DA: Super helpful.
[0:10:59.4] MN: Here’s one that I need to do more often. I need to buy one for the desk or I can just shout out loud. But talking to a rubber duck and by line by line you go over and explain each thing that your code is doing. And we often refer to that as a rubber duck debugging and talking to a rubber duck is pretty good. I think that definitely has been ways where I don’t do it too often but when I do, I’d be like, “Oh, there it is. I forgot a semicolon,” or some craziness that happened.
[0:11:35.6] DA: Yeah, I got a rubber duck right here actually.
[0:11:37.5] MN: Hey, we need a screenshot of that. Hello, show me that. We need to take a picture of that bad boy. Oh yes. Got them.
[0:11:47.9] DA: Yeah this is actually my fiancé's rubber duck, but I have a green one with a Mohawk. This one is more traditional yellow rubber duck.
[0:11:55.4] MN: Oh yeah that one. He’s a 10x rubber duck is that what it is? The Mohawk one?
[0:12:02.2] DA: Yeah. He’s 10 yeah maybe.
[0:12:06.9] MN: The Mohawk rubber ducky.
[0:12:07.9] DA: He’s got an amazing number on him and he’s yeah. I like having him out. He is pretty good. He listens very well. But especially like in these times when I can’t go talk to a colleague because he can talk to a colleague and have the same effect because it is just like the act of explaining it where you have to figure out how to express it in words and by just figuring out how to say what the thing is like you just use part of your brain that you weren’t using when you were just chewing on your keyboard or banging your head or whatever. Yeah so you know. But rubber duck, useful from home.
[0:12:54.1] MN: Yeah rubber ducks are great. Here is a quote though from a Reddit user, anonymous, I guess. “Talking to a rubber duck is really effective until he starts talking his problems to you,” so.
[0:13:07.2] DA: Yeah, I feel like that is not far off some days but –
[0:13:12.3] MN: So, your rubber duck is talking to you about problems, you need to check yourself and that rubber duck, so be mindful of that.
[0:13:19.7] DA: Right, let me check my tattoos. So yeah, if your duck is talking to you then you’d better get yourself a vacation. Check our deep cut episode number nine from the tats, vacations.
[0:13:34.7] MN: Oh, man, yeah you definitely need to take a break. Don’t get yourself burned out and take a vacation.
[0:13:41.3] DA: Yeah, which I mean honestly like taking a break is super effective.
[0:13:47.7] MN: It is a micro-vacation essentially.
[0:13:51.9] DA: You go outside, yeah?
[0:13:53.7] MN: Yes, go outside, take a walk, be safe as you do it but stepping away from your computer definitely is a thing where I feel like I should do more often and I don’t but I find that to be really effective or you know if it’s 4:45 and you in run into the issue, just step away from the computer for the day. Come in tomorrow with a fresh brain and figure it out.
[0:14:18.1] DA: I still remember how when you were interviewing me like so many years ago it’s like burned into my brain. I was like struggling with something really small and silly and they’d be like, “Okay, Pomodoro break,” we did work for 25 minutes, we’ll take five minutes off, get some water and I come back and I’m like, “Oh, okay it works now.” I just needed to do this one thing.
[0:14:47.9] MN: Yeah take a break, definitely for five minutes.
[0:14:49.6] DA: It seems so far away from figuring it out before that.
[0:14:53.8] MN: Right. I think like if you can try a lot of avenues and I think the best when you have done enough definitely take a break, go for a walk, walk around, come back fresh mind will definitely alleviate. And I have read this before in Time, if you have a problem or you are running into a bug, go and take the walk. Walk around, take your break and if you come back and you still can’t resolve it, at least you went for a walk. That is the mantra I’ve been trying to follow as of late.
So definitely take breaks, definitely if you have struggled with taking breaks definitely follow the Pomodoro technique, you know 25-5 or 50-10 will definitely help with that.
[0:15:39.3] DA: Yeah, totally and speaking of breaks, why don’t you use a breakpoint?
[0:15:44.8] MN: Oh, that is a good one too. I like using breakpoints in different programming languages, debuggers and how do you say in Java, with your IDE is one way to do that. I had to do that in a Java project recently. Definitely using the JS debugger just by slapping a debugger right in the code base. So, it just stops everything and then stops right there and I can debug that way is pretty good too.
[0:16:11.8] DA: Yeah, I really love the Chrome debugger. It is super awesome. Although you can also just click in the gutter on the console or the code view and put breakpoints in there. I forget that you could do that sometimes. But especially if you have an IDE that can be pretty nice to do that because then you don’t have all of these 20 break points at different levels where maybe you know, maybe I may have committed a debugger statement once in my life, you know? It may have happened.
[0:16:53.0] MN: It may have gone into production for sure. For sure.
[0:16:56.5] DA: I mean it is no big deal but you know?
[0:16:59.3] MN: Only programmers like browse through websites with their console open anyway. So, it wouldn’t stop them. It wouldn’t stop them at all.
[0:17:06.4] DA: Maybe it could put a little hello message there where it’s like, “Hello, thank you.”
[0:17:11.2] MN: Yeah, thanks for debugging, we’ll see you next time. Yeah, I think debug – using breakpoints is really, really effective. I think the one that I use the most and I guess I should have mentioned this the first time is definitely print statements because I know for a fact I’ve committed a counsole.log into production many a times just to figure out whether this thing is working or not by accident.
[0:17:38.9] DA: So, there is like some random website that’s just screaming like “Yooooooo.”
[0:17:44.6] MN: Here is a good one, “Yo, what am I?” That’s a really famous one of mine, what am I?
[0:17:50.3] DA: What am I?
[0:17:51.2] MN: Really, what am I and then it is like the variable name and then it is usually undefined and then now that is printing in some website in production.
[0:17:57.4] DA: I mean yeah. But you know if you are going to compare like printing to like using a breakpoint, it’s like you got – I don’t know. Sometimes I forget about breakpoints or I am a little lazy and I am like, “Let me just print the variable,” but then when I do that like two or three times for different variables and I’m like, “Wait, if I just used a breakpoint, I can look at the whole like local variables and you know that or like step through to different function or I don’t know.” Yeah, breakpoints are like print statements for like everything all at once.
[0:18:38.6] MN: Yeah, you could print statement anything on that breakpoint when print statements are just the one thing that you care for. But I find myself using the print statement way too much and if I have ever worked in your code base there is probably one in there right now, my apologies. I apologize.
[0:18:54.4] DA: Oh no. I believe that would be a fun calling card to leave where you just leave a print statement.
[0:19:03.4] MN: Somewhere.
[0:19:04.7] DA: Yeah like as a consultant. It is just like a trail of print statements.
[0:19:08.8] MN: Call me.
[0:19:10.8] DA: It’s like Morse code or something like.
[0:19:13.3] MN: Oh yeah, all right given from this list Dave what debugging tactic would you start to implement more of, do you think?
[0:19:21.8] DA: You know Googling, just more Googling.
[0:19:25.4] MN: Just from straight up using the Google. That is a good one, I mean just go straight to the Google someone probably got the answer that you need and that will definitely help you out.
[0:19:35.4] DA: I mean I feel like what I really would like to do a little more of is like reading docs a little bit more. Like there is some good useful information there. So, I am going to start doing that. Actually, I got to read the Django docs right now so.
[0:19:52.5] MN: Yeah, I think definitely doing more rubber duck debugging. That would probably be helpful for me. I’ll probably going to start grabbing my son and then just start yelling at them line by line what my code is doing, hopefully that works.
[0:20:07.4] DA: I love that idea and you know I was thinking about that like you know, he’s so lucky. Not only does he have all of these cool toys, you know you are hanging out, you got all of your podcast stuff and clicking your mouse and hanging up on your Zoom calls.
[0:20:21.3] MN: Right, his grandparents.
[0:20:22.4] DA: Or whatever but like also you know, it can help you debug all of these really hard problems.
[0:20:29.0] MN: Right, he is listening, but he is not retaining anything as babies would just like a rubber duck. And hopefully he doesn’t learn any of the bugs that I run into he has to deal with it.
[0:20:41.1] DA: I mean you just wait like his first memory is going to be just you printing your –
[0:20:48.1] MN: Semicolon that is his first full word.
[0:20:51.8] DA: Semicolon. Oh okay.
[0:20:53.3] MN: Semicolon, yes, because I keep forgetting semicolon in my codebase or something crazy. Else statement, undefined is not a function, like.
[0:21:02.3] DA: Oh no, no, no.
[0:21:04.2] MN: Hopefully it is not the case. I’d be interested in hearing any other debugging strategies that are out there. We’d definitely leave the comic strip in the shownotes as a shout out to the person behind FAS and the Furious, just so we all can learn and use this chart to our advantage and to get better at debugging as we’re writing software.
[0:21:24.6] DA: Yeah definitely print it off put it in your desk right next to the rubber duck.
[0:21:28.8] MN: I’m going to do that right now.
[END OF INTERVIEW]
[0:21:31.5] 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:
The Rabbit Hole Episode 9: Vacations
