Every so often, I run into a tricky problem that proves to be a little extra difficult to solve. Sometimes that problem is a product of working in a complicated domain, and other times it feels like I’m close to the answer but it’s hard to pull the pieces together. Like many developers, I’ve found solving these especially tricky issues to be a gratifying part of the job.
When facing one of these problems, I naturally tend to toil away at the computer until I uncover a solution. Unfortunately, that behavior doesn’t typically lend itself to finding an answer efficiently. As a consultant, it’s important to monitor how you spend your time. Being able to resolve these tricky problems quickly is almost always in the best interest of the client.
When I start to feel stuck, here are five things I like to do to get unstuck as quickly as possible.
1. Take a Break
This is my go-to approach. I’ve noticed that a few minutes away from the screen works wonders for me. Even stepping away for a moment to grab coffee gives me the time I need to refocus. I often find myself returning to my desk more motivated and ready to attack the problem from a whole new angle.
2. Rubber Ducky Debugging
Rubber ducky debugging is a problem-solving technique where you explain your code to a rubber ducky (or some other inanimate object). The idea is that, by explaining your code aloud, you cause yourself to stumble upon the issue or into a solution. I’ve found that this approach works very well because it forces me to consider the problem from a new perspective.
Since I’ve been working from home lately, I sometimes take the opportunity to explain my code to my wife or our dog, which I find fun (although they likely don’t share that sentiment).
3. Pair
We pair frequently at Atomic, but not all of the time. If I’m not currently pairing, and I start to feel stuck, I’ll sometimes reach out directly to someone for help. Two heads are better than one! Chances are the person you pull in can bring a fresh perspective that will shed new light on the problem, leading to a solution.
4. Utilize the Braintrust
One of the great things about working at a company like Atomic is having access to a wealth of knowledge. With so many talented developers, it’s nearly a guarantee that if I reach out to the dev channel on Slack, I’ll get great suggestions that will help to get me back on track. It’s also likely that someone will have dealt with the same or similar issue. In those cases, setting up a quick meeting to discuss can be incredibly helpful.
5. Recognize the 5 o’clock Bug
While this could have fit into the “brain break” section, it’s so prevalent that it deserves to be highlighted individually.
By around 5 p.m., it’s natural to be tired. Sometimes our brains are more fatigued than we even realize. When dealing with a tricky, end-of-the-day bug, sometimes the best approach is to leave it for tomorrow.
I learned this one the hard way. As I mentioned, I tend to toil away until I solve the problem. Years ago, I recall spending hours one evening trying to figure why my build was failing without having any success, only to solve it in fifteen minutes the next morning.
I urge you to focus on the importance of swiftly navigating situations where you find yourself stuck. Keep these approaches in mind. Remember that different situations may be better suited for different approaches.
I can suggest another approach I learned from “Why programs fail” by Andreas Zeller: Set yourself a time limit (10 or 15 minutes); If you can’t solve the problem by then, switch to a more systematic approach, that Zeller calls the “Scientific method”. Take notes for every step.
Repeat the following steps until the problem is solved
1. Form a hypothesis (… fails because of …)
2. Run an experiment to confirm or falsify the hypothesis
Approach 5 “Recognize the 5 o’clock Bug” works sometimes, but in some cases you are only able to solve the problem in 15 minutes because you toiled for some hours the day before.