I was reminded today that you can become stuck with stupid when you are too close to the problem; no matter how simple the problem. Fortunately there’s a very simple technique that can help you extract yourself from that hole and stop you beating your head against the keyboard. This problem solving technique will help you.

Traditional problem solving can eat a lot of time and budget. It’s difficult to know when to reach out to seniors. So what do you do?

A good technical consultant will first try to solve the problem, but will be aware of time eating into budgets. When they’ve spent enough time, they’ll reach out to a peer or a senior and walk through the problem. It’s at this point that you expect the conversation to include:

• What the problem is. State this clearly and concisely. If you can’t explain the problem, go back and walk through it again until you can.
• What your observed outcomes are. This will often help to highlight what the likely paths through the logic are.
• What you’ve done to diagnose the problem. This helps to avoid running through previous troubleshooting steps.
• Be prepared to do a show and tell, demonstrating the code and the problem.

That first step is the key one. The others are sugar to help make your colleague’s life easier, but articulating the problem is key. It is a mechanism to stimulate your thinking around the nature of the problem. I’m sure you’ve encountered a scenario where you take a problem to somebody and as you start explaining to them, you hit that “Oh!” moment where you realise exactly where things have gone wrong, how to fix it and usually about 10 improvements you can make to the code.

But what do you do if you don’t have a colleague available in those dark moments of the night when you’re tip-tapping away at the keyboard? It’s a technique I read about a few years ago and that I’ve lost in the ease and convenience of Slack and Teams and other instant office connectors. It’s called rubber duck debugging. It consists of a few simple steps:

1. Obtain a rubber duck. By legal means.
2. Place said duck on a convenient location on your desk.
3. When you run into a problem, ask the duck if it has a few moments.
4. If it has, explain to it, step-by-step, what your code is doing.
5. At some point, you’ll realise that no, it’s what you want the code to do. Not what it is doing.
6. Give the duck a pat on the head, thank it and fix your code.

This helps you not only articulate the problem, but also avoid explaining how you embarrassingly forgot to put output after the output parameters in a stored procedure call and couldn’t work out why you were getting no results back.