Duck, Duck, Done – InApps 2022

There are moments in computer programming that I can only describe as euphoric experiences. Time melts away as the code flows freely from your brain and out through your fingers into the terminal. Everything compiles cleanly, no errors, and the brilliant chunk of code you just wrote does exactly what you wanted — and, even better, expected — it to do. At times like these, a person can reasonably throw up their arms in a V for victory and maybe throw in a few celebratory desk chair spins. At these best of times, being a coder is beyond merely fun or enjoyable: it is legit a form of spiritual ecstasy.

Then there are the worst of times. You’ve been stuck for hours, even days, trying to track down one… single… bug. You stare and stare, analyzing the same section of code over and over (and over) again, and still can’t figure out why it fails. Nothing works and life is miserable. You begin fantasizing about your next job, which will be in fast food service. Swapping the phrase “Uncaught TypeError: Cannot read property” for “Would you like some fries with that?” suddenly feels like the only possible career move. StackOverflow is no help. Banging your head on your desk is no help. Your coworkers are no help (they all fled when the desk/headbanging started, anyway). IS THERE ANY HELP, ANYWHERE????

Enter the duckie.

Getting back from “no go” to a state of coding flow — or, at the very least, things more or less working — might seem impossible, but this is an experience every coder goes through. And, as programmers, we are very good at solving problems. One clever tactic we’ve come up with for tracking down the bug(s) currently causing us to stare into the abyss involves a cute lil’ rubber duckie. Yes, the kind you take baths with.

Unfortunately, the ducks do not have magical powers to solve your issue. What they do is just sit there, perky but inert, while you explain your code and the problem to them. The trick is pretty simple: explaining the problem to someone (or something) else forces you to think through it logically and break it down. Which makes it easier for you to understand your own code and, more to the point, easier to find the fix. Grabbing your rubber ducky and explaining to them what your code should be doing, and what it is in fact not doing, is very often an effective debugging technique. Definitely more so than headbanging.

This technique was mentioned for the first time in the classic software engineering textbook The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. It has since spread like a dank meme to all corners of the internet and being applied to all sorts of problem-solving professions, like automatic fire sprinkler design, and not just computer programming.

But no matter where applied, the basic mechanism is the same: the critical part Ask The Duck problem solving is to totally commit to asking a thorough, detailed question of your nearest soft plastic Anseriformes Anatidae. Though really any person or inanimate object, real or imagined, should also do the trick. It’s just that the act of verbally walking someone through your conundrum, describing it step by step, in context and with relevant details, will often lead you to your solution.

Why not just show a coworker and ask for their suggestions? Well, because just asking someone else to solve your problem is just plain lazy. If you aren’t willing to put the effort into fully explaining the problem and what you’ve tried so far in terms of solving it, why should anyone else? Plus you’re interrupting them at their own work, trying to get them to do yours. Really, just talk to the duck. Trust me.

Honestly, you don’t even need a duck, real or imaginary, though rubber duckies do make an entertaining desk accessory. Sans duck you can still leverage the Ask The Duck problem-solving technique to figure out problems all by yourself. How often have you been seriously stuck on a coding problem, failed to turn up a useful solution via Googling the error code, and in desperation started writing up a thorough, detailed question for Stack Overflow… only to figure out the answer to your own problem before you’ve even finished describing it? For me, this has happened more times than I can count and honestly is probably the way I end up solving most of my seriously sticky issues.

That process arose back when knew just enough about JavaScript to understand what I wanted to do, but not enough to just go make it happen. I would spend ages scrolling through Google and StackOverflow, rephrasing and researching my question over and over, hoping to finally ask it in the right way to turn up the perfect solution to my conundrum. Besides being a monstrous waste of time, if I did find something like a ballpark solution, I then had to launch an epic trial and error one-woman hackathon, attempting to modify someone else’s code to suit my own situation.

A friend send me a rubber duck coding meme as a joke when I was super mega stuck not too long ago, tormented to near madness by //(unknown): Script error. (Pro tip: this is what gets generated when an uncaught JavaScript error crosses domain boundaries in violation of the cross-origin policy.) In plain language, any errors that bubble up to the window.onerror handler will, instead of being caught in try-catch, get reported as simply “Script error” — offering not one iota of other useful information. This is a browser security measure intended to prevent passing data across domains that otherwise would be blocked from communication. Googling this perfectly blank Zen koan of an error message got me nowhere, for several days on end. My sanity was slowly shredding to bits when the duck meme hit my private Slack channel.

It was fortuitous timing. First I laughed. Like a duck could help. But my usual “Google the error message” debugging strategy was going exactly nowhere, and I was ready to try anything. So, feeling slightly ridiculous, I started talking. Out loud. To an invisible, imaginary yellow toy duck. Feeling fairly idiotic, I began describing I described the context of the problem I was experiencing — I had not gotten as far as the error message itself — a likely solution hit me. Setting the Access-Control-Allow-Origin header to * in order to allow the resource to be accessed from any domain, and then Set crossorigin=”anonymous” on the script tag in the HTML source. It worked.

Looking back, I realize I had been going about solving my issue all wrong, trying to find someone else’s explanation or code snippet to get my own code to work. It’s a classic newbie coder mistake. What I actually needed to do was the opposite: make MY code work for ME. Talking to the duck is what finally made me flip that very necessary switch.

Problem solved! After I got done victory dancing around my desk, I opened a new browser tab to order myself a proper rubber duckie. I think I’ll name him Squeakers.

Feature photo by Joshua Coleman on Unsplash.