What actions you should take when you are stuck on a coding problem

thodwris profile image Theodoros Kokosioulis ・3 min read

This post was originally published on June 30, 2020 on my blog.

Have you ever felt stuck on a coding problem? I know it’s a rhetorical question 😛. It’s almost impossible not to get stuck at some point throughout your career as a software engineer and not only once. This is the nature of our job. To solve riddles every day. We accepted that reality when we decided to get involved with code either professionally or as a hobby. Even senior software engineers will encounter unknown concepts for them. If you are in this position I can totally relate with you. I know very well how frustrating it can be. First things first, do yourself a favor and don’t beat yourself up or even worse don’t start having doubts about your existing skills and your experience. That’s something you definitely not need!

Don’t worry though, I’ll do my best and try to help you by giving you some tips that personally helped me go through such situations in the past.

1. Read the documentation

Yes, I know this might sound mundane but trust me this can be most of the time the solution to your problem. The documentation will (almost) always provide you with what you’re looking for. Even if it is poorly written, a simple search to its API could be proved very helpful. Personally, I refer to the documentation before jumping into other mediums. Be sure you have a clear understanding of the input, processing, and output expectation of each code unit and how that matches the principles on the documentation. Many times I have started working on something without even reading the documentation in the first place believing that I’ll figure it out by myself and had nothing but an undesired result.

2. Break it into smaller chunks

This is the first principle of software engineering. I’m quite sure that you have never worked on something complex enough and you managed to get it to a satisfactory point without breaking it into smaller tasks. This is how we go from A to B point. We have the big picture in our mind but in order to achieve the end result, we go step by step and build around it.

3. Search Google

We definitely can’t neglect the help of the Google search. They say that a good Googler is a good software engineer as well. That’s 100% true but that, only, is not enough by itself. It’s not only the Google search per se but the fact that you have to know exactly what to expect on the results. You’ll become more experienced on that as time goes by. You’ve probably seen that before. You searched for something and you didn’t get back what you expected from, but when you modified your query you finally got the answer to your problem.

4. Ask for help

Don’t be afraid to ask for help. No one born to know everything at the beginning. Colleagues, stack overflow, Facebook communities, and slack groups are one of the best mediums you could address your problem to. Always a second pair of eyes can make the difference. What may appears to be elusive for you might be obvious for someone else. If you need instant support from an experienced software engineer I highly recommend using codementor.


I hope you found these tips useful enough! Let me know which one(s) you use often and what other approach have you taken to tackle this situation.


markdown guide

Non-tech ways to solve tough problems where the answer isn't in the documentation or online:

  1. Talk it out and type it out: speaking and writing itself is a tool for thinking. Putting our thoughts into real sentences, we have to think logically and it helps us find gaps in our reasoning.
  2. Go for a walk. Literally get up and move yourself. Motion stimulates the mind.
  3. Disconnect: let the subconscious take a stab. Try doodling, playing a game, cooking, or sleep on it.

I am constantly amazed at how effective those are at breaking me out of stuck problems.


Amazing tips! Thank you for these :)


I apply third when I'm really stuck and surprisingly work every time. I can be stuck the entire day but after walking the solution comes out fast.


I second Wayne's suggestion of a break. And make it a literal break, step away from the computer, don't just switch to a browser or something.

For the "ask for help", don't forget about rubber duck debugging, that might be enough.


For the visual learners out there, I would make a small addendum to #2: if you're having problems with the execution of a function or can't quite get an algorithm to do what you need it to do, draw it out! Make a flow chart of the process and even add some pseudocode to help get the idea across. It has helped me plenty of times and there's nothing wrong with drawing out a solution to your problem. Really nice article, some solid advice here!


Your advice is super helpful as well!


Great article! The real pain is when you're stuck on a problem with less known lib or plugin without a huge community. But fortunately, they are active on GitHub issues very often :D


I'd add… 5. take a break, go do something else, and return to the problem with a fresh mind.