Admit it. No matter how long you’ve been coding, there’s still a spark of joy you feel when you hit RUN on an application you’re building. You’ve spent hours, days, maybe weeks writing commands that have been doing exactly what you’ve asked – until you make a few simple tweaks and land on an error message.
An error?!? You stare at the screen, incredulous. How could there be an error? Undo! Undo! Undo!
If you’re lucky, you’ll find that missing semicolon in a jiffy or realize a simple caps error with a quick skim. But it’s usually not that easy. There might be a problem with your logic or a function call happening in the wrong place. Watch out for that undefined variable, too.
A million things rush through your head as you dive back into the code, desperately searching for a needle in your haystack. Suddenly your deadline is looming nearer than you thought. And you think you might be making your error(s) worse.
It’ll take you a bit to realize that about five steps ago, you should have turned to a friend for help.
Enter the Duck
Chances are your friends don’t have the time nor expertise you need to solve your problems here. But we’re not talking about those friends, anyway.
For many developers, it helps to tap into the genius of a friend who knows – and says – nothing at all. Like a rubber duck.
The Rubber Duck Debugging method (a.k.a. rubber ducking) forces a developer to slow down and explain his/her code, line-by-line, to an inanimate duck that knows nothing about the program and makes no assumptions about how it works.
How Ducking Helps
First described by Andrew Hunt and David Thomas in The Pragmatic Programmer, the approach works in a few ways:
Step out of the code. It’s easy to get wrapped up trying to solve your problem simply looking at code. Talking through each line of your code – out loud – to your rubber ducky friend can help you see a different perspective or the angle you need for answers to come to light.
Reboot. But not really. How many times have you had a problem that once you walked away and started talking to someone else about it, the problem pretty much solved itself? Same deal here. Switching gears and talking to your rubber duck is like hitting a reset button on your brain. Like most tech problems, a reboot does the trick.
Connect the dots. Explain what your code is supposed to do with your rubber duck. Then test what your code actually does. It sounds painstaking, but the time you spend walking your rubber duck through this trial-and-error process will likely save you time in the long run. Once you start hitting on incongruities between what your code is “supposed to do” and what it actually does, you’ll be on your way to success.
Judgment-free zone. When you walk through your code with a person, you might feel like s/he is judging the way you code – or that s/he will judge you for whatever the problem ends up being. Great news: rubber ducks don’t judge. They just listen. And they’ll give you a squeak when your problems are solved. (Plus, their schedules are usually wide open and they’re available when you need them.)
Ducks Are Our Friends
At Swoon, we believe in the power of ducks. Each of our contractors gets a rubber duck (our mascot, Chuck the Duck) for their first days on the job. We arm Swoon contractors with a tool for success and – hey! – a readymade friend as they’re getting started in a new place, at a new job.
Chuck is not only on Swoon contractors’ desks as a sounding board for awesome work, but a constant reminder that Swoon has their back.
What Will You Name Your Duck?
Swoon is always on the lookout for talented pros who want to find the best job, ever. Have a look at whom and for what we hire and then tweet @swoond what you’ll name your duck (it’s OK if you stick with Chuck) when you become a Swoon contractor. Be sure to use #MySwoonDuck.