--- title: 'Debugging: Getting Unstuck' teaser: 'For that crucial tipping point when, after a frenzied blaze of code scouring and log surfing, you realize you''ve made no progress towards finding that pesky fiendish bug. ' tags: debugging,debugging series 2021 author: Jesse Bailey published_on: 2021-04-09 --- > This post is part of our [Debugging Series 2021] Within 25 minutes of the bug surfacing in production, the frustrated developer throws up their hands. 4 mice strike up a frenzied string quartet in the corner of the room. This is it, this is the moment when one of two things will happen: 1. They (the developer in question, not the mice) will double down on their previous attempts at finding the bug. They will repeat steps they've already tried but forgotten or not tracked in their maddened frenzy. They will continue spiraling downward into a whirlwind of chaos and mental exhaustion until, with their last gasp, they will expire moments before the [heat death of the universe]. 2. They will stop, look away from the screen, take some deep breaths, and perhaps apply a different approach to getting unstuck. By doing so, they see things they didn't before. They forge ahead with new confidence. The aforementioned quartet switches from [Night on Bald Mountain] to [Vivaldi's Spring]. All is right in the world. You've likely had the experience of going down trail #1. I personally have kept stock and I believe I'm at around 7-10 heat deaths (good thing that developers, like cats, have multiple lives). It goes without saying that we should avoid these types of dalliances. I'll say it anyway: we should avoid these types of dalliances. Let's examine a different way to move forward. [Night on Bald Mountain]: https://www.youtube.com/watch?v=iCEDfZgDPS8 [Vivaldi's Spring]: https://www.youtube.com/watch?v=mFWQgxXM_b8 [heat death of the universe]: https://knowyourmeme.com/memes/the-inevitable-heat-death-of-the-universe ## Trail #2: A different mentality 1. [Take a break](#take-a-break) 1. [Talk to a duck](#talk-to-a-duck) 1. [Ask a Human for help](#ask-a-human-for-help) ### Take a break Software development is an intense cerebral process that requires a lot of focus and attention. Often while spending large amounts of mental attention on development tasks, unhealthy physical and mental health habits crop up. It's important to keep in mind that [we are Humans] interacting and working with machines. We have Human needs that the machines don't share. It might all sound quite obvious, but it's surprising how quickly we are able to ignore this fact when there is pressure behind shipping a feature or fixing a bug. If it's been a while since you've eaten, you are thirsty, you haven't gotten up from your chair in a long time, or you are sleep-deprived and need to rest: stop and take care of yourself. There is arguably little more important than your well-being and it isn't finding this current bug. Furthermore, not attending to these needs will leave you with less physical and emotional energy and diminished brain functioning (especially [sleep] which is connected to all the above). A short routine you can use to disconnect: - Save your progress and document for your future self where you are leaving off and what questions you have - Turn off your screen (close the lid, shut off your monitor, etc.) - Leave your phone/tablet/other connected devices on mute somewhere out of site - Hydrate if you are thirsty - Take 15-20 minutes to disconnect from your work. The exact activity isn't important, only that it helps you de-stress. - Meditation, breathing exercises, yoga or stretching, and taking a brisk walk outside are all good things to try out. [we are Humans]: https://www.youtube.com/watch?v=RIZdjT1472Y [sleep]: https://arxiv.org/abs/1805.02544 ### Talk to a duck So here you are, back at it again, refreshed, and having taken care of your needs. But how do you continue working on this problem when you were frustrated before? How to re-focus on what is happening? Well, would you be surprised if I told you that ducks (specifically of the rubber variety) are excellent coding partners? The process is very well explained on [rubberduckdebugging.com](https://rubberduckdebugging.com/) and you can also find links to explore the history of this fine technique there. The general idea is that you explain vocally to the duck, line by line, what the code is supposed to do. Go ahead and try it; I'll wait. It's actually quite pleasant, isn't it? The process can be attempted with your resident feline or canine friend, but they often have a hard time sitting still and not spilling coffee all over your keyboard. Best to stick with the ducks on this one. ### Ask a Human for help Whether or not it was due to an incorrect assumption on your part or someone else's, all bugs, by nature, are derived from misheld assumptions. Our next post in the series will help with listing the assumptions that start the debugging process. For now, I want to highlight the way inviting another set of eyes into the process can aid us in identifying which assumptions don't hold water (kind of like a duck's feathers, but that's beside the point). You've talked to the duck and, while the discussion was cathartic, that bug hasn't gone anywhere. You still feel helpless as to how to figure out where it is and how it has managed to cause so much chaos on your lovely Friday morning. The next step in our journey is to pause again, take a deep breath, and ask someone for help. In the author's opinion, asking for help is one of the top things we humans are not great at. We might be resistant to ask for help because we believe that "good programmers don't create bugs". We also might believe that "good programmers find and fix bugs quickly". Embedded in these statements is an underlying fear that, because things are going wrong and we are struggling to fix it, we are completely inadequate at our job. Asking for help can sometimes feel like admission and validation of these feelings of inadequacy. We need to set the record straight: **good programmers still write buggy code**. Just because you or someone else introduced a bug into the system does not make you or them a "bad" programmer. Approaching the debugging process with the mentality that "_good_ programmers don't introduce bugs" or "If I introduced this bug, then it means I am a _bad_ programmer" increases the odds that you will overlook a basic assumption because "no _good_ programmer would make that mistake". Likewise, all programmers struggle with finding the root cause of a bug. You are not bad at your job to ask for help. What if, instead of meaning we are inadequate at our job, it just means we don't have the answer for this one instance? By asking for help, we are inviting in opportunities for learning, transparency, and team building. Here is a potential template you can use to ask for help: > Hi there, when you have the time would you aid me in looking over some code > to find a bug we're experiencing? > > Here is the initial bug report: > > - Link or list the bug report, error message, context it surfaced in > > And here are things I've tried and ruled out so far: > > - List the steps you've gone through and what the result has been ## Good luck! Hopefully you've come away from this article with some techniques to help you you get unstuck the next time you are experiencing serious frustration while debugging. I want to point out that many people may _know_ that these are good things to do but don't apply them consistently in their debugging or coding practice. _Knowing_ effective strategies doesn't help you until you apply them. So, here's a friendly reminder to take a break, chat up a duck, and work with your team to debug your system. ## Credits This post is part of our ongoing [Debugging Series 2021] and couldn't have been accomplished without the wonderful insights from interviews with the following people: - [Adam Sharp](https://twitter.com/sharplet) - [Eebs Kobeissi](https://twitter.com/EebsKobeissi) - [Eric Bailey](https://twitter.com/ericwbailey) - [John Schoeman](https://github.com/johnschoeman) - [Mike Burns](https://thoughtbot.com/blog/authors/mike-burns) - [Rick Gorman](https://linkedin.com/in/rickgormannyc) - [Sally Hall](https://github.com/sallyhall) - [Sam Kapila](https://www.linkedin.com/in/samkap) - [Sarah Dawson](https://github.com/knittingarch) - [Sean Doyle](https://github.com/seanpdoyle) Keep tuning in every week for more great debugging tips. Next week, we will dive into listing assumptions when beginning the debugging process. [Debugging Series 2021]: https://thoughtbot.com/blog/debugging-series-2021-welcome-to-the-jungle