A good answer is more likely to come from a good question; a bad question is more likely to be ignored or to result in irrelevant answers.
Tell us your problem/goal, as well your solution. In most walks of life, technical or non-technical, if we know the reason for the question you will probably get a better answer. Either the answer will be more pertinent to your needs, or perhaps it can suggest a better alternative that you haven’t even considered. Don’t ask “Can you give me a lift into town?” Do ask “Can you give me a lift into town, so I can replace my broken frobnitz?”. The answer might be “There’s a spare frobnitz in the attic”, thus saving time, money, the environment – as well as making some space in the attic.
Say what you know and don’t know. It encourages us to answer, and it demonstrates respect by avoiding wasting everybody’s time:
- we’ll realise you have already attempted to help yourself (and how), and only then are asking us to help you
- you won’t receive a “STFW” or “RTFM” response; too often those responses are perfectly reasonable, even if they are terse
- we won’t waste time suggesting things that you have already tried, and which have failed
- we won’t waste time making points you already know
- we won’t waste time giving answers that you won’t understand
- we won’t feel you’re asking us to do your job or homework for you. N.B. people are often willing to help you with your homework
- we’ll realise this isn’t a spur-of-the-moment question, and that the answer is important to you
Choose a good title. People skim titles and only look at the message body if the title looks interesting and they think their response might help. Don’t have a title like “Help, my car sometimes doesn’t start”. Do have a title like “VW Beetle intermittent starter motor: repair or replace?”
Ask the right question. Giving the right answer is easy. Asking the right question is more difficult – but is more interesting and rewarding. The answer to the right question will either cause you to go this way or that way, or will illuminate aspects that you didn’t even realise you needed to know.
Isolate the problem. Don’t dump your entire design on us. Do find the smallest test case that illustrates the problem and which we can reproduce. Just doing that can often lead you to isolate the problem yourself – and in the long term that will help you far more than a simple answer.
Bugs usually aren’t bugs. Or usually bugs aren’t where you think they are. This is especially true with C and C++; for an amusing exposition of some of the issues, see Yossi Kreinin’s C++ FQA, of which my favourite is the “const correctness” section. Unfortunately there are far more that he doesn’t touch on, not least w.r.t. memory models and inter-processor communication.
Examples of non-technical questions including suitable phrases can be found in Josh Kaufman’s How to Ask Useful Questions.
As you might have guessed, Eric Raymond’s How To Ask Questions The Smart Way was the inspiration for this page. It is still worth reading since it contains many good points, but over time it has become a bit too bloated for my taste.