How Do You Get Unstuck from A Difficult Problem?

Welcome to Code Chatter, your go-to series for conversational coding insights. What makes this series of questions different from all the others? Well, truth be told, not much, but they're still thought-provoking and fun. Join us as we explore the coding world, one witty question at a time.

When facing a particularly difficult problem, bug, or design issue, what strategies do you use to 'unstick' yourself?

Follow the DEVteam for more discussions and online camaraderie!

The DEV Team Follow

The team behind this very platform. 😄

Comments

[Nicolas Bailly]

An approach that works well for me is a variant of rubber duck debugging: I open stack overflow and start writing my question by following the guidelines (explain the problem in detail, and what I have already tried to solve it). Usually when I do this I realize I didn't try every possible solution, I try a few more things to add it to the list and show that I've done my homework, and I eventually find the solution and delete everything I've written.

Also use a debugger to run through the code. For me the debugger is an essential tool.

[Oscar]

Just take a break. I always forget to because in the heat of the moment, it's common for me to think that grinding out a problem for the next 4 hours will be easier than just taking a break. That's not normally the case though, so just take a break.

[Mihnea Simian]

Rubber ducking to the point of peeling off all the noise and specifics. Once you reach the essence of your issue, you can start looking for knowledge (or better, experts) on the matter.

Mine was a concurrency issue in between http clients when dealing with cookies in a shared cookie har. Yikes!

[Mitchell Mutandah]

I have two favorite strategies: taking a relaxing walk 🚶‍♂️ and teaming up for pair programming 👫💻.
Has anyone ever tried the "Rubber Duck Debugging" 🦆?
If at least five folks vouch for it, I might just get my own rubber duck companion! 🤣🦆👍

[Praise Idowu]

First of all, I try every possible scenario in my head. I use the print() statement to find the source of the error, I comment out some portion of my code to be able to identify the code causing the error. If it is a small code(not often) I use Python Tutor visualizer. I run tests and most times if I don't understand the error message I paste it to chatgpt to interpret it for me and identify what is causing the error. Sometimes I would have to paste my code too.
I also use Google and Stack Overflow to find people who once had similar problems.
After trying for long hours I am still stuck. I take a break. Most times I just sleep and I dream about the problem.
The moment I find a solution in the dream I wake up and implement it.
Sometimes I might not dream about the problem. When I wake up I use a fresh perspective to tackle it.

And if after everything I am still stuck. I ask for help. I reach out to people in the dev community.

[Retiago Drago]

in no particular order:

• take a step back from the problem
• ask ChatGPT / BingChat for the problem
• applied the final solution

Until I solve the problem

[Ryan Brown]

some of all of these, in no particular order, within a loop (not shown here)

• ask if anyone else has solved it (ddg, your co-workers, your friends, even the documentation or relevant literature when desperate)
• walk away from the problem for a while (do other tasks, literally walk away and get a coffee/tea/soda/water)... extend to the next day if needed.
• Rubber-Duck it... if no actual duck is available, substitute other non-technical resource. Explain the situation as you would to a non-technical resource. Listen to their interpretation of the problem and their ideas for solutions. (this also works better if the non-technical resource is a human you have good relationship with, like a spouse or bar-tender)
• Break it out into smaller pieces, ensure each smaller piece does what toy think it's doing. (this is part of "check your assumptions", don't take your instinct's word for it that the value you expect to be passed is actually what was passed and so on)
• Add more logging/tracing, perhaps something is coming out of order when NOT in a debugger. (I've had this where the act of hitting a break point gave an asynchronous task the time to complete as expected while when run normally it had not yet; Also I've encountered cases where a framework [dotnet 1.1! ] would behave differently under some cases when walking though with the debugger attached than it did normally.)
• Invert the issue if you can. Try to accomplish the opposite, see how that works. Get the idea for it. Trying to block a specific connection? Instead block all and try to allow it. This could give you the perspective to re-reverse the solution to what is intended.

[Mike Stemle]

I usually try to break it into pieces. If I’m having a problem with code, I’ll usually try to write a test to exercise the problem. Small test programs are much easier to use a step debugger with. I usually go there pretty quick since it’s so effective.

I also, unironically, love rubber duck debugging. 🐤

[Jean-Michel 🕵🏻‍♂️ Fayard]

I take a break, write down why I'm stuck, and talk with a human about it.

[sahra 💫]

When trying to solve a difficult problem, I usually take a break. I walk away from the problem for a while. During that time, my mind is more settled and Ideas to solve the problem just easily flow in.

[Arthur Kh]

The key to solving difficult problems is communication. Communicating with your team or friends always provides a different point of view and can suggest effective solutions.