DEV Community

Ben Halpern
Ben Halpern

Posted on

What's the best thing to do when you've run into a debugging dead end?

So you've hit a wall. What is the best course of action in this situation?

Top comments (57)

Collapse
 
thatonejakeb profile image
Jacob Baker

Turn off the computer and go for a walk.

Collapse
 
drewtownchi profile image
Drew Town

This is the easiest and best thing to do. Let your brain work away from the screen. The amount of problems I've fixed by not working on them for a bit is staggering.

Collapse
 
ronaldoperes profile image
Ronaldo Peres

Yes, this is one of the best thing to do.

Also if you get stuck like for 20 minutes, ask a friend for help.

Collapse
 
seniru profile image
Seniru Pasan Indira

Good answer, sometimes time can give you the solution

Collapse
 
kmwill23 profile image
Kevin

Sleeping works too! And video games.

Collapse
 
s_aitchison profile image
Suzanne Aitchison

Make a cup of coffee > Explain the problem to someone else > Have a mid-sentence brainwave > Run away back to desk and fix in seconds > Have existential crisis about why that took so long

Collapse
 
danondso profile image
Dublin Anondson

This so much. There's just something extra about talking to a person instead of a duck.

Collapse
 
s_aitchison profile image
Suzanne Aitchison

And the face-palm moment that inevitably follows πŸ˜‚

Collapse
 
cassidycodes profile image
Cassidy

This always works for me too! I try to explain the problem like ours the first time I’ve ever seen it.

Collapse
 
kayis profile image
K

I am going to solve this problem with weed

Collapse
 
nestedsoftware profile image
Nested Software • Edited

I think this summarizes my usual process for debugging tricky problems:

  • When working through various scenarios, make sure to carefully document each step. Make sure to alter only one thing at a time and check all possible combinations of things that may be causing the problem.

  • Break the problem all the way down to its fundamentals - sometimes that may mean starting from scratch and adding code bit by bit until the problem manifests itself.

  • Take a break: It's amazing how new ideas can come along when you're taking a walk or are in the shower!

  • Research: Look for answers online

  • Ask for help: Ask someone who may be able to help, either online or in person

  • Workaround: Is there some way to solve the problem without attacking it directly? Maybe there is a way to solve a slightly different problem that will still produce the desired results, or at least get close enough to get past the current bottleneck.

Collapse
 
karataev profile image
Eugene Karataev

Start asking questions: Why am I doing this? Am I happy? I can't solve this, I'm an impostor. I better work with wood or open a bar..
Oh, that was a typo! Great, keep coding

Collapse
 
buphmin profile image
buphmin

Ask someone else too look at the problem with you. Sometimes they will see something you didn't since they don't have a ton of assumptions on how it will work.

Collapse
 
olistik profile image
olistik

Stop locally and restart from the simplest working context.
It's almost like performing a git bisect.

0: disable/comment almost everything so that you have the simplest context;
1: test if the context behaves like it's supposed to behave;
2: if it does then re-enable/uncomment half of the things back and GOTO :1;
3: if it does not, then if the problem is self-evident, fix it and RETURN πŸ₯³;
4: if it does not, you already know that the things just restored are responsible for the issue. You can pinpoint the issue even further by disabling/commenting half of the things you have just restored and GOTO :1;

The key point here is that you waste a few minutes in order to get to :0 but avoid wasting several hours finding a bug that is probably way above the context you're looking at.

It can appear vague but it's a debugging process that can be performed in a wide variety of contexts, not just source code.

Collapse
 
dfockler profile image
Dan Fockler

I always start with asking myself "What assumptions am I making about what's happening?" Most of the time this leads to me realizing I don't understand how something is actually working and that my assumptions created some false understanding. Bugs on computers are almost always deterministic at small scales. So, if you can dive far enough down the abstractions you can find the bug.

Collapse
 
tarasnovak profile image
dataPixy πŸ§šβ€β™‚οΈ

I highly recommend a cup of jasmine tea w/honey & meditation sess.

Collapse
 
karfau profile image
Christian Bewernitz

If you dont want to leave your train of thoughts by leaving the desk/computer (yet):
Use the help provided by rubber duck (can also be a text editor or colleague if you prefer):
Explain everything you did so far, as you would need to in a stack overflow question or thorough bug report.
In most cases I do that, the missing piece get's obvious.
If you have the patience to write it down and it doesn't help you can of course ask that question here or somewhere else, or file that bug...

Collapse
 
fossheim profile image
Sarah

Take a break. I either:

  • Go for a walk
  • Work on another issue
  • Get coffee/water and take a social break
  • Have some food

And then when returning to it with an empty head, I sometimes start from scratch again depending on the issue.

Also breaking the problem down in separate tasks, and logging everything along the way. And when things are split up properly, comment out everything and try each function by itself.

Collapse
 
fjones profile image
FJones

Try a different approach.

Been using your debugger all throughout? Try some dumps - even just to confirm what your assumptions are. The inputs really are in that range? This particular function returns what I expect?

Dumps didn't work? Static analysis. Write out the branching. Look for things that seem overly complex or too easy - try and rephrase them in pseudo code and, again, confirm your assertions.

Still no idea? Run through it backwards. What needs to happen so you get the expected result? What would have to happen to produce the result you're seeing?

Break the problem down. Talk to someone else about it. Take a walk around the building.

Essentially: change your frame of mind and reference. Work a different angle until the suspicion kicks in - the tiny moment of "wait... Surely it can't be that!"

Collapse
 
jwp profile image
John Peters

Keep at it no matter what, but try to get rest before next session.

We had a bug once that took 1.5 years to determine the root cause.

And we had another one, where the vendor of the software told us after a year of reporting the issue, they could not find root cause. The main reason on this one was that nobody knew how to read a system dump trace which was our only way to show them the error.

Collapse
 
schwad profile image
Nick Schwaderer

Something I heard from a mentor in a coding school five years ago.

Ask yourself:

Could it be simpler?

The number of times that I have lost hours of awful rabbit-hole coding when it was just a typo. Or my server wasn't running. You wouldn't believe it. This advice applies for me time and again.

I keep morale up by reminding myself I've made it this far coding, no bug has destroyed me (yet).

Collapse
 
fultonbrowne profile image
Fulton Browne

Turn your computer off, scream, get some coffee and listen to music until you solve your problem.