debugger's block

Question

Do you ever run into a bug where you are just out of ideas and don't know what to try next, and you're getting really annoyed? Are there any general ideas on how to break out of this mode?

Answer 1

When I get blocked like that, the best advice I've found is leave for a while. Whether it's going for a long lunch or leave for the day. Come back fresh and take a new look. Most of the time the answer will be staring you in the face. So far a 10 minute coffee break hasn't been enough for me, but your mileage may vary.

Second, talk to your peers. Walk through everything you've tried. Just ask them to listen, and while you're talking it through, a lot of times, the answer will come to you.

Those are just the two that I use most often when I'm debugging blocked.

Answer 2

I usually take a break... if that doesn't work, I sleep on the problem. (Actually, to be honest, I should say that I spend a sleepless night mulling over the problem).

I almost always have a list of possible solutions ready by morning. :-)

Answer 3

I usually take a few steps:

• look at the code that is involved in the functionality that has the bug and place logger messages in a way that they will help me narrow the problem (this allows you to look at the logger later on when you are not that annoyed anymore, and maybe find useful hints :P)
• ask my senior collegues for hints
• call the client to have a clear understanding of when the problem arises

Answer 4

I usually end up in that mood when I didn't take a structural approach from the beginning. By iteratively narrowing the area where the problem can live and trying to write the smallest code base that can reproduce the error, I haven't failed yet.

Answer 5

I think if you run into that kind of problem it is time to do some serious refactoring...

Also it could indicate false assumptions. Try to assume programmatically all that you are 'just' assuming. See to it no method-invariants are broken of any methods that are in the stack.

Answer 6

Others have mentioned taking a break or "sleeping on it". This technique is known as (amongst other things) Incubation. Once you embrace the idea you can take it further too.

One important aspect as to really leave the problem behind, confident that you'll have answers later. The dangerous otherwise, especially if sleeping on it, is that you'll be worrying over it up to the last minute, then this becomes an endless cycle that your mind gets caught in overnight. You'll probably end up waking up not too well rested having dreamt many circular dreams. Do this too much and it's a path to depression.

Answer 7

• Five minute break

Utterly critical, lest you smash your keyboard.

• Explain the problem in an email to your sister

Or your two year old son. Someone who wouldn't understand a word* unless you explained it very clearly. You don't need to send the email, you just need to be certain that you understand it inside out. You be surprised at how many times simply restating the problem suddenly makes it obvious to you where you went wrong. This is a good way of discovering what your assumptions were about the problem, and how they might not necessarily be correct.

*That link is to an excellent answer by JaredPar on a different SO question.

• Talk to a colleague

By this point you've already 'emailed' the family pet, so you know that you've hopefully covered all the stupid aspects, it's time to talk to a real person. They may have experienced some obscure thing in the past that reminds them of this situation, and they'll definitly have a different perspective. Try to make sure you are clear about what the problem is, not what you think it is. You don't want to bias them. You can and should talk about what they've tried, and explain why you think the problem is in that area (you're probably right) but you don't want to close your mind to their suggestions, even if they don't seem right.

• Look at the code again

By this time, you should hopefully be less violent, and you should be armed with new ideas. Start by re-verifying the bug. A simple step, but I've been frustrated for hours on a bug that was in our test script and not in our code. Once you've verified the bug again, start at the top. Verify EVERYTHING. Put a breakpoint at the last point you are 100% confident in, and then work your way forward until you find that the output is broken again. That's a huge success because you now have a hopefully smaller code block to investigate. Then, if necessary, pull in a colleague to look at the actual running code.

Answer 8

Another good option is to bounce ideas off other developers/team members. Sometimes they will ask you questions you hadn't considered.

If you work alone, it's a good idea to have a few fellow developers who you can chat to to troubleshoot with some different approaches. You'd be amazed how often a fresh perspective can be the breakthrough you need.

Answer 9

Try David Ungars "Shower Methodology":

"If you know what to type, type. If you don't know what to type, take a shower and stay in the shower until you know what to type"

This kind of summons up what the majority likes to do. Take a break ! Doesn't matter what kind of break it is, as long as you are not thinking of the things you were doing before the break. Distraction in any form is good.

Cheers !

Answer 10

I usually take a dry run through the offending method/function, step by step. And don't assume the bug is coming from there, it could be coming from anywhere before it.

Use a proper debugger, don't use a series of printfs.