Getting stuck in a programming problem is a very common thing.
For example, when you are learning to code or a new programming language or face a new problem, you have never solved before.
Doubtless, the best way to approach the problem is first to understand it thoroughly.
But the fact is, at some point or the other, you will find yourself frustrated.
And that's a part of the coding life-circle:
Challenge to solve -> Find a solution -> Get Frustrated -> Try harder and Go crazy -> Take a break -> Moment of Enlightenment -> Solve and Repeat.
So I really think it is better to try and deal with frustration than try not to be.
If you are stuck with something, it just probably means that you're overheated trying to think for a solution.
Take a break, calm yourselves down. Clear the clutter in your mind and start over by following the next steps to shift from "Try harder" mode to "Moment of Enlightenment" faster and before going crazy about the problem:
Rubber Duck Method
First, try fully understand the problem you are solving. A time-tested and adorable way to do this is to use the rubber duck method. Often enough, talking through a problem out loud will lead to a lightbulb moment. If it will not, then explaining the problem to a rubber duck is at least a great way to practice clear communication so that when a colleague gives you a few minutes of their valuable time, you can get right to the point.
Stack Overflow
Another step is posting a question to Stack Overflow. This is the most preferred and favorite method for many developers because, at some point in time, the familiar problem with the same context was already solved a while ago.
Use debugger
Debugging is a matter of reducing uncertaintyβonce you know where the bug is and how to fix it or where the solution might be applying to approach the problem, then making the change is (usually) trivial. The most efficient way to reduce uncertainty depends on what you already know.
Googling things
No one knows about everything, and it would be a waste of time to memorize things you do not use that often. So every developer ends up googling on a semi-regular basis. Herewith, it is vital to know what to google. It means, having a good idea of what approach should be taking and what bits of knowledge to look up to get the pertinent information to solve the problem.
Ask others for help
In a work environment, someone else has may have come across the same problem and can give you useful tips or even the full explanation of how to approach the task. Because engineers are humble in general.
Moreover, the value of programming to a business is the finished product - the faster it gets done, the more profit will be made. Struggling alone might waste not only your time but also money of the company.
The best junior programmers are those who never hesitate to reach out to their peers for advice. The best senior programmers are the ones who willingly share their knowledge and mentor their junior colleagues.
When learning to code or develop software, websites, or apps, we usually will get stuck with a problem or a bug that refuses to be resolved, no matter what we do.
And if you are looking for tips that might be helpful to find the solution you need and not only about coding, you will find them in my weekly newsletter (+bonus networking cheat sheet).
Besides, keep reminding yourself that the great thing about computers, is that they always do "exactly" what you tell them to do.
So, if they are not doing what you expect them to do, work out what you are telling them to do. Once you know that, you are halfway to solving the problem.
Photo by Pixabay on Pexels
Top comments (20)
My thought on this as a senior developer who wants the junior developers to become great and amazing developers:
Please ask another person fast!
Don't sit it there and get frustrated and almost tilt.
I ask my juniors probably at least once every 2 hours if they don't have me anything to ask.
Usually, it is easier to talk through the problem with another person. The rubber duck method is excellent but the rubber duck does not calm you down or asks questions back.
But another human can do this.
I agree with most of this, but I would caution junior devs on not looking to someone else to give them the answer right off the bat. Fighting through a problem yourself, even getting frustrated, is actually a good thing (even though it isn't pleasant). I learn more from those situations than I do from when the answer comes easily. (The frustration itself helps ingrain it in my memory!)
In other words, when you ask for help, you should be ready to tell them What You Have Tried.
Gentoo style π
Now I'm thinking what would be Arch Linux style π€£π€£π€£
Like Gentoo but from a lower hanging branch π
Haha yeah your right π€£
You are 100% right!
I don't tell them just the answer.
I never give them the answer.
At some point, they went the wrong path and I just guide them back to the point where they made the error and then guide them on the right path to the solution.
So I ask them what the problem is and let them explain. This helps them to get the frustration out. Then I ask them what they think is the problem. Then we try their solution together and usually it does not work. So even if I by this point know the solution I will ask them what they will do next and why and so on. I hope you see the pattern.
If they then tell me that they googled for 2 hours and were sitting there for 2 more hours frustrated of course I will help them. At this point, something went wrong completely.
And yeah I tell them that frustration is part of the job also part of the fun to solve the problem :)
I was taught the 20 minute rule and it's been really helpful. Basically when you're stuck try everything you can think of for about 20 minutes. Google stuff, try stuff, try to talk it through on your own... and if you're still stuck ask for help. I usually try to spend 5 minutes making sure I can accurately explain the problem to the person I'm asking.
It's been a huge thing because it's easy to just ask for help without trying yourself and it's also easy to sit there feeling like you haven't struggled enough to justify asking for help yet.
You are right! You should struggle for a little bit!
Give that brain some work :)
Just don't tilt!
For some people, it is hard to find that line where they tilt.
Great article!
I want to make an addition for in case you are stuck while debugging:
Take nothing for granted. Question everything. Oftentimes you skip lines assuming them to be too simple to break. When necessary go line by line through your code, including the obviously correct ones. Gather as much information as possible.
I've told this story a lot but when I was working on a React project when I was learning I was getting so frustrated because something just wasn't working. I struggled for like an hour and then asked for help. Two hours later I had like 6 people in Zoom with me when we finally realized instead of "component" I had typed "compontent" and we were all just skipping over that line when we were looking for the problem.
Great story!
I could relate to that. If one is new to a topic there is this feeling of being lost. And if then things do not work, you get frustrated and feel more lost.
But being into a topic and overlooking a simple typo drives you nuts :D
Amazing Conclusion to a Process that people have naturally followed but sometimes have failed to understand. I personally agree to taking a break method is what has always worked for me. I think as you have explained it does point to the fact that patience is a key to success.
One thing i`d like to add that has personally helped me is, repeating the process from start, starting from scratch with the problem. What i have observed is that people get too scared of using
Ctrl + A : Select All and in Mac CMD + A
And Then Delete
Lolx, kinda sounds funny but for me, when i am stuck lets say half way down a problem, i just trash the code aside for reference, and then restart the whole process from the very base and to my amaze it is always some step i might have missed that solves in the problem, this thing also worked with hardware aswell.
Keep up the good contributions. Your ideas generate more ideas for me to write on as well.
Regards
Adding to this. I usually use one of the below;
Walk away - if you're a perfectionist,the best thing you can do is to abandon ship, totally let go, don't worry, your hyperactive brain will work tirelessly in the background and bubble up the solution.
Read a good novel - most devs and software oriented peeps only read documentation and tutorials! Seriously! find books to read that have nothing to do with whatever you are currently working on. I recommend the Hitch hiker's guide to the Galaxy (I read it every year).
Perfectionist here π. The problem with this is that no software is perfect and perfectionism is impossible to achieve, at least from your own highly subjective perspective. In the end, it all becomes a wild and annoying snark hunt.
Cannot emphasize enough how important is to take breaks especially after being frustrated when something doesn't work.
Coming in with a fresh mind the next day might be all you need.
I totally agree and unless you learn how to detach yourself from the problem at hand, you'll get caught up in an infinite stress loop that sometimes culminates in performing the following:
Oh yeah definitely don't want to do that lol
I can second all of these!
Too true. As I mentioned in my other comment, frustration helps the experience and resulting knowledge stick in my memory.
Thank you, Ilona! This is excellent.