Andy: The number one thing to do when you’re stuck on a problem [such as finding a bug] is to step away from the keyboard. Take a break. Go walk around the parking lot. Go get a soda. Go get a beer if you’re so inclined. Whatever your environment is, it’s to remove yourself from that immediate L brain track. And this is one of the interesting things I discovered from the research [I did for the “Refactoring Your Wetware” talk]. You know, when you’re stuck on a hard problem, sitting at the computer is literally the worst place to be. I’ve given talks -- many dozens of times now -- and I’ve had so many people come up to me to corroborate the anecdote that you’re sitting there and you’re debugging or it’s a design problem that you just, you can’t get the ends to meet, and how are you gonna work this out… . And they’ll sit there and sweat bullets for some arbitrary amount of time and then, in disgust, go walk off to the bathroom, the parking lot, go home, whatnot, and halfway through the parking lot, bang, the answer hits them. You know? Or, worst case, it will be in the shower the next morning or on the commute or whatever it is, and it just asynchronously pops into their head.
That brilliant idea popping into your head will not do it most of the time when you’re sitting there pounding on the keyboard in frustration. You know, it just blocks you from doing that. So the number one advice I have when stuck is stop. You know, take a deep breath, literally take a deep breath, ’cause that actually does help re-oxygenate you and get things kicking along a little bit better. Mom was right when she said, “Stop, take a deep breath, and count to 10.” There are actual real physiological reasons you should do that.
Ed: Okay. Well, what about reproducing the bug or writing a test case, an automated test case, adding a test case to the test suite?
Andy: Oh, yeah, yeah. Yeah, you do all that stuff. That’s the currently approved way to do a bug: have a test case that will demonstrate it conclusively first. Before you touch it in code, make sure you can reproduce the bug via a test case. Then go in, fix the code, and then re-run the test case to make sure that it’s fixed. But those are the easy ones. That’s Agile canon and certainly the best way to go about it. But what do you do when the bug is more elusive than that? You know, it’s non-deterministic. You can’t reproduce it well. There is a race condition somewhere, some area deep down somewhere, and you really don’t know all the constraints that apply to it. That’s where it gets a lot more interesting, and that’s where you need to try what you can and then when you’re just not figuring it out, walk away from it for a little while.