DEV Community

How Do You Get Unstuck from A Difficult Problem?

dev.to staff on September 10, 2023

Welcome to Code Chatter, your go-to series for conversational coding insights. What makes this series of questions different from all the others? W...

Read full post

sahra 💫 • Sep 10 '23

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 • Sep 10 '23

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.

Ryan Brown • Sep 10 '23

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.

Praise Idowu • Sep 11 '23

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.

Mitchell Mutandah • Sep 11 '23

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! 🤣🦆👍

Mihnea Simian • Sep 11 '23

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!

Oscar • Sep 11 '23

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.

Nicolus • Sep 16 '23

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.