How Developers should ask for help

Back in October ZDNet Australia posted a brief video interview of Tom Kyte describing How developers should ask for help (linked by Eddie Awad). I thought I'd mention it now since I was talking to a few colleagues at the recent AUSOUG Conference and they don't recall seeing the video.

When I was first learning Oracle, I spent about 20 minutes every morning reading entries on AskTom and learned a lot! You also get a feel for someone's personality when you continuously read responses to questions posted by all varieties of people. Frankly, Tom's a witty fellow. I especially like his oft used analogy of comparing apples to toaster ovens.

I also empathise with some of his pain in responding to questions that simply don't provide enough information. I must say I particularly agree with Dan Wilson's reply in the comments section. Regardless of the forum to which you may be posting a question, it's so important to provide a context, frame of reference, ins and outs etc.

Put yourself in Tom's shoes - what information would you like to receive from someone asking you a question about a technological problem? Do you want to hear "Why doesn't this query work?" or would you like to be provided with a really simple test case that provides you the ability to tinker straight away?

I also liked Tom's explanation of why he doesn't respond with RTFM. Not only is it important for everyone to learn by doing, it's also important for people to learn how to effectively find the correct documentation themselves - which should be the first step to nutting out a problem before you even consider approaching anyone. I'm passionate about documentation, and technical queries on Oracle functionality spurred me into writing my presentation on documentation usage.

Another analogy I find is when my eldest child tries to tell me about something in a book he's reading. Unless he puts it in context for me, I'm not really going to understand why it's funny. Or perhaps when I ask my father how to do some handy work around the house. I might ask him specifically how to do something, but if I don't even give him the bigger picture, he may not know to explain the even easier solution using different tools I wasn't even aware of.

This concept applies true to so many fields and situations.