Imagine you’ve been tasked with fixing a bug. Or you discovered an issue while implementing a feature. With no obvious solution, you ask around to see if anyone has ideas. Nobody does. Or none of their ideas work. It looks like you’re on your own.
You dive in and try everything you can think of. Hours pass with no apparent progress. Hours turn into days. The deadline is looming. You need something to show for all your effort, but nothing is working. You hate this problem and just want it to be gone. Now what?
Take a deep breath.
Your reptilian brain is not going to help you here. It’s raising your stress levels, tensing your muscles, and generally making it hard to think. Taking a breath sounds trite, but it’s easy to forget when you’re under pressure. When time is running out, it seems the only course of action is to hold your breath and face the problem head-on.
And once you’ve been at it a while, simply taking a breath and trying to “clear your mind” might not be enough. Instead, try shifting your focus to something else for the moment. See if you can fill in a few squares on that crossword in the break room.
Talk at someone.
Even if you don’t have a person to actively pair with to solve the problem, talking through it can help your own brain process things. A good listener can be a person, a rubber duck, or a chatbot of your choice.
Chatbots are rapidly replacing search engines for solving esoteric programming issues. Whereas searching Google or StackOverflow depends on somebody else having experienced (and solved!) the same issue, chatbots can often give you a more direct answer faster. Even if the bot doesn’t solve your problem immediately, the chance that it will at least give you some ideas to try is worth a few minutes.
Get more information.
Once you’ve exhausted all your best guesses, it’s easy to get stuck in a brute-force loop of trying anything and everything. This sort of stabbing in the dark can sometimes work out, but, most of the time, you need more information.
Is there some behavior in the bug reproduction that seems impossible? Add as much logging as you can in order to piece together a comprehensive picture of what’s going on. Or temporarily delete code until the problem goes away to narrow down the cause.
Is there some aspect of the system you’re not very familiar with? It’s worth taking some time to understand the piece of the system most related to the problem at hand. Even if the code itself is readable, keeping a map of a complicated system in your head is difficult. Draw a diagram to help yourself remember the important parts. Tools that generate graphs like function call trees from source code are neat, but usually include too much noise to actually be useful.
Read the documentation.
Reading documentation is tedious. And it’s hard to think about spending hours poring over documentation when you need to solve this issue now. But unless you’re an expert in the tool/framework/language at hand, you will have gaps in your knowledge. And the answer might be hiding in those gaps.
It’s hard to overstate the value of reading documentation, especially if you’re stuck in a loop of guessing and checking. It’s annoying how often the solution to a problem was one configuration setting that I never would have thought to look for.
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — commonly attributed to Abe Lincoln
Spend some time solidifying your understanding of the domain surrounding the problem. Then you’ll be more likely to solve the problem without guessing. You’ll also be able to make sense of whatever you observe in the course of your investigation more easily.
Keep a log.
If you don’t remember what you’ve tried, or what sub-problems you’ve already solved, it will take much longer to find the solution. Find a way to record your progress. Keep details about what you’ve tried, and especially copy the exact text of any error messages. When you inevitably have to backtrack and try something different, you will likely face the same error again.
If I’m working through a code problem, I like to make “checkpoint” commits in Git. These are a lot like WIP (work-in-progress) commits but tend to be much more granular. A checkpoint is like a fork in the road that I might come back to if I hit a dead-end. If I am ever about to abandon a bunch of code I just wrote, I will ensure it’s captured in a checkpoint first. Parts of the code might ultimately still be useful, and it’s nice to have a reference of what I tried.
Come back to center.
Periodically remind yourself of the original problem you’re trying to solve. After a few hours, you might realize you’ve gone down several rabbit trails and are thoroughly stuck in the weeds. But getting there may have given you some new information to attack the original problem. Take a moment to brainstorm about what to try next. You might even realize you were trying to solve the wrong problem all along.
Take a walk.