********************************
Please, read before posting
********************************
SECTION I. Introduction
In the world of programming, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer.
The first thing to understand is that programmers actually like hard problems and good, thought-provoking questions about them. If we didn't, we wouldn't be here
Programmers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true.
SECTION II. Before you Ask
Before asking a question a, do the following:
1.Try to find an answer by searching the archives of the forum you plan to post to.
2.Try to find an answer by searching the Web.
3.Try to find an answer by reading the manual.
4.Try to find an answer by reading a FAQ.
5.Try to find an answer by inspection or experimentation.
6.Try to find an answer by asking a skilled friend.
SECTION II. When You Ask
Prepare your question. Think it through. Hasty-sounding questions get hasty answers or none at all.
Choose your forum carefully
Be sensitive in choosing where you ask your question. You are likely to be ignored if you:
•post your question to a forum where it's off topic
•post a very elementary question to a forum where advanced technical questions are expected, or vice-versa
Use meaningful, specific subject headers
The subject header is your golden opportunity to attract qualified experts' attention. Don't waste it on babble like 'Please help me' Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description instead.
More generally, imagine looking at the index of an archive of questions, with just the subject lines showing. Make your subject line reflect your question well enough that the next guy searching the archive with a question similar to yours will be able to follow the thread to an answer rather than posting the question again.
Write in clear, grammatical, correctly-spelled language
Expressing your question clearly and well is important. Spend the extra effort to polish your language. It doesn't have to be stiff or formal. But it has to be precise.
SECTION III. Don't TYPE IN ALL CAPS
Don't TYPE IN ALL CAPS; this is read as shouting and considered rude.
If you write like a semi-literate boob you will very likely be ignored. So don't use instant-messaging shortcuts.
Be precise and informative about your problem
•Describe the symptoms of your problem carefully and clearly.
•Describe the environment in which it occurs (machine, OS, application, whatever).
•Describe the research you did to try and understand the problem before you asked the question.
•Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
Do the best you can to anticipate the questions a respondent will ask, and answer them in advance in your request for help.
SECTION IV.Volume is not precision
You need to be precise and informative. This end is not served by simply dumping huge volumes of code or data into a help request. If you have a large, complicated test case that is breaking a program, try to trim it and make it as small as possible.
This is useful for at least three reasons. One: being seen to invest effort in simplifying the question makes it more likely you'll get an answer, Two: simplifying the question makes it more likely you'll get a useful answer. Three: In the process of refining your bug report, you may develop a fix or workaround yourself.
SECTION V. Describe the problem's symptoms, not your guesses
It's not useful to tell programmers what you think is causing your problem. So, make sure you're telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis. If you feel it's important to state your guess, clearly label it as such and describe why that answer isn't working for you.
Describe the goal, not the step
If you are trying to find out how to do something, begin by describing the goal. Only then describe the particular step towards it that you are blocked on.
Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this.
SECTION VI. Be explicit about your question
Open-ended questions tend to be perceived as open-ended time sinks. Those people most likely to be able to give you a useful answer are also the busiest people (if only because they take on the most work themselves). People like that are allergic to open-ended time sinks, thus they tend to be allergic to open-ended questions.
You are more likely to get a useful response if you are explicit about what you want respondents to do (provide pointers, send code,..). This will focus their effort and implicitly put an upper bound on the time and energy a respondent must allocate to helping you.
SECTION VII. When asking about code
Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for. Posting a few hundred lines of code, saying "it doesn't work", will get you ignored. Posting a dozen lines of code, saying "after line 7 I was expecting to see <x>, but <y> occurred instead" is much more likely to get you a response.
If you simply want a code review, say as much up front, and be sure to mention what areas you think might particularly need review and why.
SECTION VIII. Don't post homework questions
Programmers are good at spotting homework questions; most of us have done them ourselves. Those questions are for you to work out, so that you will learn from the experience. It is OK to ask for hints, but not for entire solutions.
Follow up with a brief note on the solution
Send a note after the problem has been solved to all who helped you; let them know how it came out and thank them again for their help
Your followup doesn't have to be long and involved; a simple "Howdy ' it was a failed network cable! Thanks, everyone. - Bill" would be better than nothing.
In fact, a short and sweet summary is better than a long dissertation unless the solution has real technical depth. Say what action solved the problem, but you need not replay the whole troubleshooting sequence.
Besides being courteous and informative, this sort of followup will help others searching the archive of the mailing-list/newsgroup/forum to know exactly which solution helped you and thus may also help them.
SECTION IX. How To Interpret Answers
This sort of followup helps everybody who assisted feel a satisfying sense of closure about the problem. Problem narratives that trail off into unresolved nothingness are frustrating things; programmers itch to see them resolved. The goodwill that scratching that itch earns you will be very, very helpful to you next time you need to pose a question.
If you don't understand...
If you don't understand the answer, do not immediately bounce back a demand for clarification. Use the same tools that you used to try and answer your original question (manuals, FAQs, the Web, skilled friends) to understand the answer. Then, if you still need to ask for clarification, exhibit what you have learned.
SECTION X. If You Can't Get An Answer
If you can't get an answer, please don't take it personally that we don't feel we can help you. Sometimes the members of the asked group may simply not know the answer. No response is not the same as being ignored, though admittedly it's hard to spot the difference from outside.
In general, simply re-posting your question is a bad idea. This will be seen as pointlessly annoying. Have patience: the person with your answer may be in a different time-zone and asleep. Or it may be that your question wasn't well-formed to begin with.
SECTION XI. How To Answer Questions in a Helpful Way
Be gentle. Problem-related stress can make people seem rude or stupid even when they're not.
Reply to a first offender off-line. There is no need of public humiliation for someone who may have made an honest mistake. A real newbie may not know how to search archives or where the FAQ is stored or posted.
If you don't know for sure, say so! A wrong but authoritative-sounding answer is worse than none at all. Don't point anyone down a wrong path simply because it's fun to sound like an expert. Be humble and honest; set a good example for both the querent and your peers.
If you can't help, don't hinder. Don't make jokes about procedures that could trash the user's setup — the poor sap might interpret these as instructions.
Ask probing questions to elicit more details. If you're good at this, the querent will learn something — and so might you. Try to turn the bad question into a good one; remember we were all newbies once.
While muttering RTFM is sometimes justified when replying to someone who is just a lazy slob, a pointer to documentation (even if it's just a suggestion to google for a key phrase) is better.
If you're going to answer the question at all, give good value. Don't suggest kludgy workarounds when somebody is using the wrong tool or approach. Suggest good tools. Reframe the question.
-px
