Now I know what you are thinking. He’s gone mad!! What on earth does a bright yellow aquatic bird made of rubber possibly have to do with Tableau and how is that supposed to improve my viz? Well just bear with me and it will all become clear.
I’ve been rubber-ducking at work for some time now, in an open-plan office so it’s not as dodgy as it might sound. It’s a process that has been common in software engineering and I have started using it with my Tableau work and it’s been a great success. So how does it work with coding?
OK, tell me about the Rubber Duck
Well, imagine you are writing a piece of code to extract some data from a database, perform some action on it, and display the results on a screen. You’ve written the code how you think it should work but when you come to run it you get errors, or not the result you expected. You’ve been working on this code for the last week so know it inside out, but because of the familiarity of it, you cannot see what the bug is. I have a buddy in the office that I turn to in situations like this. I get him to sit down with me and I talk through the code, explaining what it’s supposed to be doing, and why I used this approach rather than that. And without fail, just but explaining it out loud I discovered the bug, corrected it and now the script works perfectly.
And the Rubber duck?
Simple, sometimes there’s no one in the office or you are working from home, or maybe you always code by yourself. The story goes that a software engineer started explaining how his code worked line by line
to a rubber duck that happened to be on his desk and the Rubber Duck debugging method was born.
It’s the simple process of talking through the code that does the trick. I know the code inside and out and know what it’s supposed to do. Having to explain what it’s doing forces you to read the code you have written and observe what it does. My buddy didn’t do anything other than listen, they don’t have to know how to code or what I am trying to do, they just have to listen and let my brain do its thing.
How does this apply to Tableau?
Designing and building a good viz takes some time. You spend a long time looking at the data and working out how best to display it. By the time it comes to publishing the viz you know it inside and out and you know exactly the story that you are trying to convey. You know why you have used each of the filters and how you expect the user to interact with it. And therein lies the problem. You know all this, and assuming that the person who is looking at your viz for the time will also know this just isn’t always going to be the case. You get to the point where you can no longer look at the viz objectively, you cannot unlearn how it’s supposed to work. This is where the rubber duck technique can help you out. Sitting down with someone and explaining to them the logic behind your viz will show whether you have conveyed the story that you want to. Showing them how each filter works will highlight those that are really not needed or those that make no sense. Talking through how the viz is supposed to work and seeing what it actually does makes it apparent where the issues are.
If you work with other people in an office ask someone to sit with you while you go through your dashboard. State what it’s supposed to show, how the filters let you change the view, and how that helps find the story in the data. If you work alone then there are many people in the Tableau community that you can ask to look over your viz for you. A fresh pair of eyes will soon spot glaring problems and if you give them a brief outline of what the viz is supposed to convey, then they can tell you if you are on track.
And if not, get yourself a little rubber duck, sit it on your desk, and explain to it what your viz is supposed to work. If you struggle to explain your design then the duck has done its job.
And as ever, finish with a song, take it away Ernie…
