So you've hit a wall. What is the best course of action in this situation?
For further actions, you may consider blocking this person and/or reporting abuse
So you've hit a wall. What is the best course of action in this situation?
For further actions, you may consider blocking this person and/or reporting abuse
Luciano Jung -
Renan Ferro -
Michael Tharrington -
Arjun Vijay Prakash -
Top comments (57)
Turn off the computer and go for a walk.
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.
Yes, this is one of the best thing to do.
Also if you get stuck like for 20 minutes, ask a friend for help.
Good answer, sometimes time can give you the solution
Sleeping works too! And video games.
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
This so much. There's just something extra about talking to a person instead of a duck.
And the face-palm moment that inevitably follows π
This always works for me too! I try to explain the problem like ours the first time Iβve ever seen it.
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.
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
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.
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.
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.
I highly recommend a cup of jasmine tea w/honey & meditation sess.
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...
Take a break. I either:
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.
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!"
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.
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).
Turn your computer off, scream, get some coffee and listen to music until you solve your problem.