Talk to the Rubber Duck

*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

Popular posts from this blog

Using telnet to troubleshoot connectivity.... and watch Star Wars

Image
So the teaser I'll lead off with is, at the end of this post you'll know how to watch Star Wars A New Hope in ASCII art form (i.e. text based graphics)... So let's begin. Recently I found myself working on a legacy application such that I had to redeploy the multi-node application into in Infrastructure running in Azure. Two of the models communicate via a WCF binding over net.tcp. While I was operating under the impression that the firewall had been opened up to allow the communication I was a bit stuck on how to validate that the communication was working. So I wandered up to the networking area to chat with our Network Architect. As I often find, chatting with those who have an expertise different than your own requires patience and effort in the area of translation. Even though we both work in the IT field we each have our jargon to deal with, but the price of admission is well worth it. In just a few minutes of explaining my challenge I had been provided wi
Read more

.NET MSTest and DeploymentItem Attribute

Image
I was recently reminded that order of operation can byte you when trying to troubleshoot intermittent unit test failures. First, I’ll be the first to admit that if you want to avoid problems with unit testing it’s best to avoid any dependency outside of your actual code base, things like databases, API and even the file system are best avoided in execution of your unit tests. That last one, the file system, in some applications is really hard to avoid. If you happen to be using MSTest, a helpful attribute for your test is DeploymentItem. This particular attribute allows you to define a file within your unit test project assuming it’s marked as “Copy Always”. With this attribute in place you can then combine this with TestContext.DeploymentDirectory to find this sample file and then do what you need to do. In my particular case I was having an issue with the unit tests failing on the build machine but not locally. After stumbling around for a bit I finally feel back to t
Read more

Example of using LazyInitializer.EnsureInitialized

Image
When looking at making systems more efficient it's helpful to think about being lazy. A helpful tool in the .NET tool belt is the static class under the System.Threading namespace LazyInitializer. In particular this class contains a method  EnsureInitialized This method is very simple to use and provides a convenient way to ensure that an initialization is called only once based on the value of the target property already being populated. For example, if you need to load a file as part of the setting of values in an application you can use the EnsureInitialized method. The following is a derived example of using the class to illustrate the usage pattern. If you are having trouble viewing the below code you can use this link to view the gist github. https://gist.github.com/briannipper/ac2778ccd0d15b4ab217083331419ae7 using System; using System.Collections.Generic; namespace Example.EnsureInitialized { class Program { static void Main(string[] args)
Read more