Help, I'm stuck!
As programmers, we will invariably run into a problem we just can't seem to think our way around. Maybe it's a solution we thought was elegant but actually led us down the wrong path, or maybe it was a seemingly simplistic problem that wasn't so simple after all. Beginning developers as well as experienced developers will all get stuck at some point or another. Whatever the case may be, it happens to us all. So let's take a look at some tactics to help us get moving again after hitting that coding wall.
Sketch it out
Sometimes it helps to sketch out what you're trying to accomplish. Sketch out all the systems, services, or pieces of code you will need to talk to and see what needs to happen along each step of the way. Until you can visualize what needs to happen, your brain may be struggling to help you find the solution you're looking for.
Take a walk
Other times, your brain may just need a little reset. When you've been locked in combat with, well, yourself, take a break. Go for a walk or listen to some music. These things can help your brain focus on something else instead of the problem at hand. Sometimes, this mental switch can help you utilize a different part of your brain to attack the problem and help you come up with a solution.
Work on some other aspect of the problem (or a different one altogether)
If you’re stuck on a particular piece of a problem but another piece is available to tackle, you can do that one instead. Working on something tangential can get your mind thinking about all the things that need to happen for the other piece. Or at least you won't feel like you're completely stuck and at least making some forward momentum on the larger problem.
Or another way to get your brain to shift gears and work on the problem subconsciously is to tackle a different issue altogether. This way you are still moving forward on things that need to get done and giving your brain time off so to speak.
Grab your ducky (or cardboard cut out)
This is one of my favorites problem-solving solutions, and it goes by several names--Cardboard Programmer and Rubber Ducking are just a few of them. How it works is fairly simple: if you don't have someone to explain your problem to, grab an inanimate object you can talk to--a cardboard cutout of someone, a rubber duck, a stuffed animal, whatever it might be--and start explaining your problem. Talk through the problem as if you were trying to explain it to a colleague. As you verbalize (or in some cases write down) your problem and possible solution, your brain switches into another gear.
As you do this seemingly simple act, you may hit upon the right answer to your problem. I used to have a supervisor that served as my "Rubber Ducky." Many times, I would walk into his office struggling to find the right solution to a given problem, typically within just a few minutes of explaining the problem and the issue with my solution, my mind would land on it, all without him having even said a word or asked a single question. Now, my development journal fills much the same role for me as I hold a dialogue with myself, going over the issues and how all the pieces will fit together.
Break down the problem into smaller parts and solve those first
Another option is to try breaking your problem into chunks. You may have started off with a large problem, for example: "We need to connect our new microservice into our payment service so that we can accept payments when a user signs up." There may be several questions that spring to mind:
- How do I connect with the payment service?
- What kind of data does it expect? What does it return?
- How will I get the data from the user that I need to send to the payment service?
Once you've gotten a list started, then you can start to break it down even further. What kind of objects will you need in your service? What about making sure your methods are small enough to be tested?
Or maybe what you're stuck on is a complex algorithm. You are doing your best to write something that is elegant and performant. Maybe what you need first, though, is a big clunky thing that isn't all that performant but actually works. Having something that works helps you see where you can improve and refine and make sure it still works.
Write a test first
I'm a big fan of test-driven development, or TDD as its also known. With TDD, you start with a test first; you write a test against a specific aspect of your method, one that will fail first. You then begin to iterate on your code until you can get it to pass. Once it passes, then you move on to the next test you can think of for the next method, or a negative test (one that should fail). Keep iterating and building out your function, class, service, whatever it might be until you feel satisfied.
Oftentimes, writing the test first forces you to think through scenarios you would not have thought of in the beginning, and it guides you through changing your interface before you have a lot to change. Doing TDD also forces you to break your problem down to the simplest solution first that passes and then expanding on this.
Pair with another programmer
Pairing with another programmer is another excellent tool for getting unstuck. Much like Rubber Ducking, this forces you to first explain the problem, a possible solution, or an issue that you're having. Then the act of watching as someone else drives, stepping through possible solutions, can open up other avenues neither of you saw.
Wrapping Up
I've personally used all of these, some of them multiple times in a day. It helps to work through your problems with others, even if they're not real like the rubber ducky ;). No one of these is a given go-to for me; it always depends on the situation at hand as to which method I will choose. If no one is available immediately, I may write down my problem and solution, or talk it out out loud, or I might sketch out something on a whiteboard to try and poke holes in it. If someone is available, I might ask to do a quick Zoom video, or if we're in the same office, I might go over and chat with them in person, or grab someone to sketch something on the whiteboard together. Hopefully, these will help get you unstuck on whatever problem you've been having.
Sign up for my mailing list and get your free ebook
"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project
Top comments (0)