As programmers we are daily faced with having to get requirements, test things out, etc.

It's practically half our job to know what questions to ask, and how to ask them to get the most concise, actionable answer possible, especially from reluctant users/managers/customers/etc.

How do you ask questions that get answers?

  • Do you mean on stackoverflow, or in general?
    – pkaeding
    Commented Sep 11, 2008 at 18:03
  • Is this a joke post?
    – Outlaw Programmer
    Commented Sep 11, 2008 at 18:03
  • Are you asking about ODBC? (Sarcasm!) Commented Sep 11, 2008 at 18:04
  • Apologies for the close, I clicked it by mistake, it should go away in a day or so
    – waffles
    Commented Jul 22, 2009 at 11:19
  • Similar: meta.stackexchange.com/questions/1472/…
    – fretje
    Commented Jul 22, 2009 at 12:35

13 Answers 13


This is something for the FAQ... it's been beaten to death. Hopefully people signing up for this site will understand... "How to ask questions the right way"


Of course, the people who ask dumb questions are the same kind of people who won't read that article - "it's too long, I just want my answer!"

I think this site is doing a good job of discouraging the annoying behaviors that are rampant on other forums, but we're still in a private beta phase, so I'd like to think we're getting better quality folks here right now than what we'll see in the future. When it opens up to the public, I imagine there will be a lot of "plz snd the codez" questions... but we'll have to see.

  • 5
    You spelled it wrong. It's "plz snd teh codez" :P Commented Oct 5, 2008 at 8:34

This is an ok point, but the thing is, asking good questions involves already having some knowledge of the topic, which the user often doesn't have. If he googles the topic, he's gonna find it, refining the search and googling some more will maybe answer the question, and he's not gonna post it here. Some users are terribly lazy at googling. I often answer some questions by simply googling it by keywords, and yanking/pasting the first results.

So, I'll say, let them ask the questions in the form they wish. Questions will be modifies, refined and rewritten if necessary, and in the end we will have a good answer on the topic. Duplicate ones can easily be deleted (and usually are).

Answer to lothar since comments are too short: Yes, of course it is. But, as I tried to point out, a new user will maybe not know it is a bad question. Because from his point of view (doesn't know) it is a valid question. And it is really. From yours or mine, naturally, it is a bad/boring/repetitive question, 'cause we've seen it so many times before. That is a way of learning. To be a teacher one has to be patient.

Now, as you probably guess, this can be taken to the extreme. Trolls arise. So the question is "how to stop users from continuously asking bad question, which everyone can see make no sense?". Should something like, "question closed for LAZY USER reason - user cannot post another for 24h" be implemented (where LAZY USER would be a category where the answer to your question appears in the upper block while you're writing the question).

  • Good point, but is it not tiresome to sift through the wast number of questions that are bad. And would it not be a better experience for a new SO user if he started with a good question rather than a bad one.
    – lothar
    Commented Apr 17, 2009 at 1:45
  • @lothar - see my answer in the post. These comments are too short.
    – Rook
    Commented Apr 17, 2009 at 3:27

Judging from the tags, I took this as a question about requirements collection, which so far puts me in quite a minority.

The problem with soliciting useful requirements from customers essentially lies in the difference between natural and formal languages. We need discrete answers to questions about how the system needs to work. But people naturally insist on qualifiers like "well, usually" or "most of the time".

So I believe the trick to asking questions that get useful answers for the purpose of requirement collection (if that's what you were asking about), is to define, define, define!

Formally document all of the terms that have special meaning to your project, and make sure that the client always has a current copy. Until you've come to terms on these definitions, no further discussion is going to be productive. It sounds rude, but to some degree you have to train the natural vagueness out of your client.

After the first, informal project discussions, I steer requirements sessions to inherently-documented forms like chat and email.


In terms of gathering requirements, try to get a really good understanding of the client's intent -- what problem are they trying to solve? Ideally, watch as they go through their process the old way, and learn what works and what doesn't.


Questions have to be short and to the point.

There's also a huge class of problems that can't be solved here (or anywhere else). SO is good for "how do I send a mail with Java", but you won't get help with the real problems that involve the larger picture.


When I meet with someone to go over requirements my goal is to really understand what they want.

The first rule I have is to not worrying about looking stupid or asking stupid questions. It is the person or group you are meeting with responsibility to convey their requirements to you in a way that you understand. Asking questions shows that you are serious about understanding what they want.

I like to use a basic cycle of:

  • Listen to their question,
  • repeat their question,
  • express what you do not understand about the question.

For example,

Q: "Adam, we are needing a dynamic system that will notify our users to changes made to it".

A: "Ok - so you want a dynamic system that will notify your users to change made to it. So, what exactly do you mean by "Dynamic?"

and so on....

Don't be afraid to say "I really don't understand what you are wanting. This is what I understand so far, please help me fill in the blanks..."


In order to avoid misunderstandings and misinterpretations humour should be avoided at all cost. No matter how dry the question, do not use jokes to lighten it up. Cheerfulness factor should equal void. Or null. Or nil. Not use it. Okey? Let's repeat:

Humour = Bad.  
No humour = Good.

We'll talk about smileys another time.

  • you are a very funny guy :) Commented Sep 11, 2008 at 20:22
  • Is this answer serious?
    – André
    Commented Sep 28, 2008 at 14:40

The upvote/downvote system encourages good questions and discourages bad questions. It's simple. Another idea would be to force new users to read an article before they post.

  • The problem is that you still have to read many bad question, as many bad questions are nevertheless around "0".
    – lothar
    Commented Apr 17, 2009 at 1:33
  • And there's an 'edit' option for the author. And reputable users can edit. Etc.
    – vanslly
    Commented Apr 17, 2009 at 2:01

I don't think a FAQ link will help no matter how prominent you make it. Most people don't read that sort of thing. And anyway the people asking these questions might not know they are leaving out important context. If they were such experts they wouldn't need to ask the question in the first place.

I also don't think this is such a huge problem anyway. Questions can be edited to make them better, so who cares if they are not so great at the start?

  • Maybe I am biased, because I have not reached the level where I could edit someones question. And even If I can I might not be able to enhance the question because I don't have the information in the first place. I just know there are many questions with comments that say provide more info.
    – lothar
    Commented Apr 17, 2009 at 1:49

I refer those interested in asking great questions to this nice piece by ESR. ("Courtesy never hurts and sometimes helps", "Make it easy to reply"...)

Also worthy is this tutorial on how not to ask questions. ("Be patient", "Show some effort"...)


If the question seems tricky, don't forget to set up the context. Also, go through the question by yourself first... think it through. What really is your problem? Why do you not understand it? How can you understand more about it? It is silly to ask a question if you already know the answer to it yourself.

Also, use the search button...


Read Jon Skeet's famous Short but complete programs before posting question.


I think all the questions on here are getting answers (for better or for worse). I see your generalized point here, but I think the answer lies in just reading the site for a while.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .