How To: Ask Questions The Smart Way
closed account (z05DSL3A)
Abridged version of the work of Eric Steven Raymond
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.
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.
Prepare your question. Think it through. Hasty-sounding questions get hasty answers or none at all.
When You Ask 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.
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.
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.
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.
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.
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.
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.
Last, and not least, 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.
How To Interpret Answers 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.
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.
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.
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.
Prepare your question. Think it through. Hasty-sounding questions get hasty answers or none at all.
When You Ask 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.
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.
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.
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.
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.
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.
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.
Last, and not least, 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.
How To Interpret Answers 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.
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.
Last edited on
closed account (z05DSL3A)
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.
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.
Last edited on
Great article. I think the no homework questions part should be put in large bold font though. Good job on the article again.
Wow is this school or an online forum? I am a programmer and when people ask a simple question its easy, I give them the simple answer. Of course you could just be arrogant enough to take 20 seconds out of your life to answer that simple question. People come to forums for help. If they take the time to make a post, its always nice to take the time to post that simple error to send them on their way. Honestly who does all those steps before asking a question. People will obviously search the web (thats probably how they found this website) and then perhaps... maybe if they know what they are doing, search the archives. There is no 'smart' way to ask a question. There are only people who think their 'smart' because they believe the answer is 'simple'.
When it comes down to it, people will ask questions, which you may feel to be good questions or bad questions. But at the end of the day, you can answer the question (either with a good attitude or with a bad one) or you can just not answer it and leave it until someone else answers it. To this day, I have yet to find a simple question on ANY forum that has been unanswer by someone. End of Story.
I agree with the homework and follow up part though. But the rest of the article is rubbish.
Steve
When it comes down to it, people will ask questions, which you may feel to be good questions or bad questions. But at the end of the day, you can answer the question (either with a good attitude or with a bad one) or you can just not answer it and leave it until someone else answers it. To this day, I have yet to find a simple question on ANY forum that has been unanswer by someone. End of Story.
I agree with the homework and follow up part though. But the rest of the article is rubbish.
Steve
It's more of a guideline. Otherwise every day we end up with 20 people posting the same question because their tutor has used the URL of this site as a possible reference.
e.g "I am creating a program that grades students, can you please send the code to blah@bah.com. Thanks! Some Foreign Dude!"
We are volunteers. And by giving out answers for free we would not be promoting that people actually go out and try to learn something for themself (god forbid!). It's only going to get worse for them when they get a job as a developer so they might as well learn while they are at Uni (funny enough.. to learn!).
Think of the forum not of a place of answers, but of a place that gives advice to help you find the answer. If you post a well thought our question, with code that is giving you problems, and an accurate description of the error. Then by all means you should (reasonably) expect a post with a solution to your problem and a brief explanation of why that specific error is occurring so you can prevent it in future.
e.g "I am creating a program that grades students, can you please send the code to blah@bah.com. Thanks! Some Foreign Dude!"
We are volunteers. And by giving out answers for free we would not be promoting that people actually go out and try to learn something for themself (god forbid!). It's only going to get worse for them when they get a job as a developer so they might as well learn while they are at Uni (funny enough.. to learn!).
Think of the forum not of a place of answers, but of a place that gives advice to help you find the answer. If you post a well thought our question, with code that is giving you problems, and an accurate description of the error. Then by all means you should (reasonably) expect a post with a solution to your problem and a brief explanation of why that specific error is occurring so you can prevent it in future.
In the original post, the author says that people who ask a simple question may get some attitude. More specifically it says:
Giving anyone who asked a simple question a hard time is unacceptable in my book. I'll treat you the same whether your Steve Wozniak or your starting C++ for the first time.
Of course the
is always an annoying post to read. However its obvious that people would never respond to that question because its not really asking anything other than 'do it for me' which is another case in it self.
We are indeed volunteers, however I volunteered because when you teach something, you learn alot of the little things you might have missed when you first learned it. I also enjoy helping someone out because I have the answer, whether it be simple or not.
Its the internet though, so you do your thing, I'll do my thing, just as long as things get done.
Steve
| 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. |
Giving anyone who asked a simple question a hard time is unacceptable in my book. I'll treat you the same whether your Steve Wozniak or your starting C++ for the first time.
Of course the
| e.g "I am creating a program that grades students, can you please send the code to blah@bah.com. Thanks! Some Foreign Dude!" |
is always an annoying post to read. However its obvious that people would never respond to that question because its not really asking anything other than 'do it for me' which is another case in it self.
We are indeed volunteers, however I volunteered because when you teach something, you learn alot of the little things you might have missed when you first learned it. I also enjoy helping someone out because I have the answer, whether it be simple or not.
Its the internet though, so you do your thing, I'll do my thing, just as long as things get done.
Steve
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.As the author says "what looks like". This is usually just that, and a typical response you find anywhere. The whole idea behind this is for people to understand that asking the question a smarter way is going to be more beneficial from them because we won't have to ask for extra information that if they had followed this they would've provided.
e.g
"my code won't compile and it gives me X error".
99% of the time the first response will be.
"Well, where's your code?"
The whole idea to this is to help people provide us with adequate information, in a suitable format so we can spend less time trying to decipher crap and more time helping them with their actual problem.
No offense but if anyone stopped and read this post they when they needed an answer to their question would end up wasting ten minutes of their time. All that needs to be said is 'Be specific, respectful and patient.' That somes it up for the most part. Then throw in the 'No homework questions'. BAM article done. If people don't give enough information that is their problem. Post the first response of
As long as there is progress people will be happy. But start telling them their post is dumb because someone answered the same question 5 years ago in the archives is just rude.
This article would have been fine if the author never brought up about people being smart, cause all you did was call alot of newbies dumb. Good one chap
Steve
| "Well, where's your code?" |
As long as there is progress people will be happy. But start telling them their post is dumb because someone answered the same question 5 years ago in the archives is just rude.
This article would have been fine if the author never brought up about people being smart, cause all you did was call alot of newbies dumb. Good one chap
Steve
closed account (z05DSL3A)
Where in the article dose it mention anything about say that people posts are dumb?
Title:
Question for you...
If someone doesn't follow your procedure, what way are they posting.
And you also said they would be ignored for these types of posts. Why?
| How To: Ask Questions The Smart Way |
Question for you...
If someone doesn't follow your procedure, what way are they posting.
And you also said they would be ignored for these types of posts. Why?
closed account (z05DSL3A)
skittalz wrote:
Just because the title of the article is How To: Ask Questions The Smart Way dose not mean that all questions asked another way are dumb. If I say the fastest way to the city center is X, it dose not mean that all other routes are the slowest.
And by the way read the first line!
skittalz wrote:
The article says You are likely to be ignored if you:..., this is just a comment on the fact that people do ignore some posts, for example posting a question in the Unix forum that is about Windows will likely be ignored by alto of people.
| If someone doesn't follow your procedure, what way are they posting. |
And by the way read the first line!
skittalz wrote:
| And you also said they would be ignored for these types of posts. Why? |
Last edited on
The point of the article is to give some guidance to those who do care enough about those that might help them.
If you are faced with a problem you cannot solve, and have just spent 2 hours on it without success, then 5-10 minutes reading some helpful advice is time well spent.
You learn how to format and phrase requests, and as any experienced programmer will tell you, sometimes just thinking about a problem and how to explain it can be enough for you to suddenly see the andswer yourself.
And if not, because you are more likely to post a coherant question, with nicely formatted code examples, you are more likely to get a quick and helpful response.
As a final thought, and to answer your last question skittalz, faced with 10 posts and with time to only skip through them and answer 1, it's the well presented question that get answered. That's what makes asking the question in a way that makes it easy to answer smart.
If you are faced with a problem you cannot solve, and have just spent 2 hours on it without success, then 5-10 minutes reading some helpful advice is time well spent.
You learn how to format and phrase requests, and as any experienced programmer will tell you, sometimes just thinking about a problem and how to explain it can be enough for you to suddenly see the andswer yourself.
And if not, because you are more likely to post a coherant question, with nicely formatted code examples, you are more likely to get a quick and helpful response.
As a final thought, and to answer your last question skittalz, faced with 10 posts and with time to only skip through them and answer 1, it's the well presented question that get answered. That's what makes asking the question in a way that makes it easy to answer smart.
| All that needs to be said is 'Be specific, respectful and patient.' That somes it up for the most part. Then throw in the 'No homework questions'. BAM article done. |
I personally love that idea. Short, simple, beautiful, just the way I like my info. Although an article like that would not get the bumps this post has. I have seen this exact article referenced in nearly every tech forum I have posted in (no more than 5 in total).
| But start telling them their post is dumb because someone answered the same question 5 years ago in the archives is just rude. |
I dont think any would disagree with you on that. Some effort should be taken though. Use a forum search, if provided. If the forum does not offer a search bar, spend a minute or two scanning the past pages. I dont think any one would bite your head off of asking the same question that was answered 2 months ago, and is now 30 pages back. It is a different thing when you post a question that was answered 2 hours ago and is still on the first page.
Great article. A++
Topic closed to new replies.