True story.

When it happens to you not just once but twice, thrice, it’s fair to say there’s some truth to the title statement. That in asking a question, your answer is already half answered. This totally happened to me on multiple occasions on the past few weeks when I hit a wall with my code. Because I hate troubling others and also because I feel personally responsible to try to solve things on my own first before seeking help, I often don’t ask for help until I’d spent almost a day banging my head against a wall. That’s my limit when it comes to debugging. 

What would follow would be me taking the time to upload my code into Github, Codepen or Codesandbox, and taking some time to type out my question, making sure that I give the context, frame it properly, phrase the question with the right technical terms. And then posting it to various maker/coder channels, or directly to helpful folks who offered a hand in the past. Then I wait, for people to reply. Meantime, I continue trying to resolve it. One or two friends might reply, and I try to explain it a bit more. And then what happens next goes right into uncanny valley. Very often, before they can even understand the problem and resolve it, I solve it. On my own. A weird character nested in the code, or a some obscure tutorial or Stack Overflow answer that doesn’t seem related at first glance. 

It’s embarrassing, to say the least.

It’s almost lame, like all the hoo-haa to ask the question, only to answer it yourself. I’m sure my friends feel cheated. But I can’t help myself. 

So perhaps the next time I will do the same thing, but maybe skip the last step of actually posting it out to friends. And then see what happens. Whether I solve it myself or not. Because I believe the break in the process—when I step out of problem-solving, trench-digging mode to an overview mode of framing and phrasing my question—I break the momentum that caused the problem in the first place, and get perspective. That’s usually what we need to squash a bug in the code. 

A break. And perspective. 

That’s why: in asking the question, you already half-answered it. Or the answer is already right at the tip of your tongue, hovering under your nose all the while. All that was needed, was a question.

Ask, and you shall find.

-———

Everyone told me that what I just described was “rubber ducking”. @bhumi did, and another coder friend who helped me out did too. Looks like this is an important rite of passage for any coder. I need to go get myself a rubber duckie.

Today I had to seek help again, but this time rubber ducking didn’t work. @craigpetterson helped me out in the end, and all it took was that dreaded question: “Did you reboot the server?” 

You know how the first thing you should try when your computer/smartphone acts up is to switch it off and back on again? Yep. Same principle, different computer. It was hands-down a mistake that only a rookie can make. One of those laughable yet relieving moments. Luckily I didn’t spend the whole day on it!

Craig mentioned that he used to have a sticky note stuck on his screen, outlining the tips for debugging before he asked someone else for help. The very first point was “Reboot the server”. That got me thinking…if I had to write the same sticky note, what should it contain?

• Reboot the server.
• Rake or migrate db.
• Check the code for syntax errors, missing semi-colons, commas or closing brackets.
• Type out the code if you had copy-pasted over some bits of code.
• Google {language/framework} {error message}.
• Search Stack Overflow.
• Stop all debugging after 30min, take a break.
• Try a new approach after break, whatever it may be.
• Rubber ducking: Write out what you’re trying to do, talk about the error you got, outline the things you tried, paste public code repo. And wait. Don’t send it out yet.
• Continue debugging for 30min.
• Send it out to friends.

That definitely can’t fit into a sticky note for sure! But as a first noob version, it’ll do. For now.