Recently I was writing some code and ran into a problem. Same old story. It happens all the time to developers everywhere. I began decomposing the problem, tried to isolate it, Googled error messages, explored different approaches to do the same thing, etc. All of the usual stuff I do when I run up against a nasty bug. But the bug persisted and I began to run out of thing to try.
Help!
When I hit that point I know it’s time to reach out for help. There are usually a number of avenues to choose from when deciding how to get help. If you can find one, you can jump on an IRC channel related to the problem you’re having. There are general purpose developer Q&A sites like Stack Overfow or forums that you can post to. Then there are mailing lists and groups specific to the project/product that you can join.
My personal preference is for sites like StackOverflow but if the community around the technology involved isn’t using that for their primary support mechanism then it’s off to a mailing list or forum. Either way the most important aspect is writing the request for help itself.
Writing
There are a lot of recommendations for writing good bug reports. They’re almost indistinguishable from guides on how to ask for help so there’s a lot to learn from them. Pick one or roll your own and go with it. I find it doesn’t really matter which format you use. But using a format will structure your thoughts and help your analysis of the problem. I usually don’t write the request for help in a linear manner either. I’ll jump from section to section depending on what’s most relevant at the moment.
Once you’ve got the problem out of your head and in front of you, you can dissect the details and your own problem solving. Writing it all out forces you to explain what you’ve already tried, what you’ve researched, and the results. Presented in a logical format it can be quite illuminating. You might identify something you haven’t tried yet, an error message you previously dismissed, or reveal a path you didn’t fully explore.
The later seems to be the case I run into most often. I’ll be reviewing my request for help to see if it makes sense. I’ll imagine what it would be like to explain the problem to some one and what kinds of questions they would ask (“Well why didn’t you try X?”) . The questions send me down a different path that often leads to an answer.
Coda
How many requests for help have I written and never needed to send because the answer came to me in the process of writing the request? Dozens? Hundreds?
I suppose this is my version of rubber duck debugging. The key difference is writing the problem out and structuring the information. It’s this process that so often leads me to the answer.
The best part is that, if you are still stumped at the end, the request is all ready to go. Just don’t wait too long before clicking send!