| *See attribution of image at the bottom. |

One of the greatest tricks I have had the pleasure of participating in is that of helping someone solve a problem simply by listening. I'm sure there is a more accurate description of this phenomenon, but in the world of programming it's called Rubber Duck Debugging. I was first introduced to this idea from listening to Jeff Atwood podcasts/interviews as well as reading his blog under CodingHorror.com he wrote about the topic under the title Ruber Duck Problem Solving.

Why the term Rubber Duck? Really it has nothing to do with the rubber duck, the intent is to encourage someone to solve their own problems by working through the very difficult challenge of describing what the problem actually is. It is often surprising to people when they discover that simply the act of attempting to describe a problem helps them to find the answer they were looking for.

So my approach to assist others is by asking questions that I often ask myself to help them work through the Rubber Duck process. For example if a developer where to ask me to help them with a particular bug the questions I ask them are seemingly obvious, but surprisingly, their answering them can often lead to an answer.

So what type of questions should you ask? The most obvious is "what is the problem" this question alone can often help you find the root of the issue and resolve the problem. Let's demonstrate this by way of a contrived example.

A developer is having a problem with her application communicating with a third party API service. So that is the "obvious" problem, but now comes the next question, are you ready... "why is that problem occurring?"

So how can the developer answer this question? Debugging is a great place to start. A great place to start is by attempting to reproduce the issue locally. It's worth noting that in our example this doesn't result in re-producing the issue found on the sever. Now in some cases, such as when the developer isn't permitted to remotely access the server being impacted, there is still much that has been found. How so? We now know that the application is NOT the issue, nor is the API service broken. This points to an environmental issue. So even when you can't reproduce the bug locally you obtain more information. In our derived example the developer now has facts that he can presented to other IT engineers such as networking, security or even server admins to engage with in a meaningful conversation to solve the problem.

Another interesting side effect of engaging in this approach is that you will find you have a broader understanding of how systems connect and interact. Additionally your "Google Fu" is improved as well as you can key in on the specific phrases related to your problem. This is an excellent skill to develop and when you find yourself in the position of the rubber duck you can ask the right questions to help someone else solve their own problem.

So go be a rubber duck.

*By gaetanlee - https://www.flickr.com/photos/gaetanlee/298160434/, CC BY 2.0, Link