When you are answering questions here as well as in the real life what do you do if you feel there is a bigger issue/misunderstanding behind a simple(?) question asked?

Sometimes the straight answer is pretty obvious. Just give the person asking the fix they want and be done with it.

But what if the question shows that there is a bigger issue in play here? What if you know that even the right answer to the question will not solve the asker's real problem?

What do you do? Ignore the question? Answer it and move on? Or try to explain the bigger context and related issues?

So many people asking questions here are in just for a quick fix (and I fully appreciate this - some of them are under considerable pressure) so they ignore - or even downvote answers which are more complex than what they expect.

But isn't it better to teach them to fish rather than giving them the correct answers which you know will not solve their problems?


It looks like it is time to select the "correct answer". It seems that everybody is pretty much of the same opinion - it is necessary to do both. Not that this is something unexpected for me _ I have to admit that the question was as much a question as an expression of some frustration.

Frustration not because my feeling offended/rejected - not that, frustration because people just skip over important stuff not realizing that they set themselves up for more problems, problems which would've been easily averted if they just pay attention.

@Charles Stewart: What prompted the question? - It was multiple encounters more or less relevant to the topic. The one which stood out for me is this. F# is a beautiful language, but so many people out there think that it is C# with slightly different syntax. They have no idea how far from truth this is.

Anyway - going back to the answer - All of them are good ones, but according to the rules I can only select one and will go with the crowd.

  • Was there a particular question that provoked this? Commented Dec 11, 2009 at 18:18

6 Answers 6


Look, we've seen this all the time. What I try to do, is check if it is a duplicate (that generally this kind of simple questions have) and if there is none, provide as complete an answer as I can.

I start explaining the background knowledge needed, later explaining the specifics for the OP situation and finally, I give them the fish, if I consider that it should be given (the OP is not asking how to do something illegal or technically stupid).

Giving the fish in the last part of the question is important. Even if most people rush through questions/answers looking for the relevant information, the OP has a high chance of seen the introductory explanation, which could even say don't do this, because it's evilthis, this and this.

Let's try get people to learn something new every day, not just make them practice copy n' paste.

  • 2
    I generally do the opposite: I give the answer first then fill in the background about what's going on. Generally, I leave it up to the asker if he wants to read the background or not, but at least the background is there if he wants it and if other stumblers need it later. Unless I'm telling the asker not to do what he seems to be doing (like parsing XML with regular expressions). In those cases I start with the "don't do it, here's why", then move into a more suitable solution (like XPath! Hooray.).
    – Welbog
    Commented Dec 11, 2009 at 20:37

I usually try to do a bit of both, where I feel it's appropriate. For homework questions I'm much more likely to give "fishing hints" rather than giving a whole fish. For "I need this for my job" questions I try to give the "fishing" bit first and then give the answer - that helps to stop people from only reading as far as the bit they need right now :)

Admittedly there are time pressures here - it's a lot quicker just to give the fish, so sometimes that will have to do... but not usually for homework questions, as that's not really helping anyone.


You can only teach someone to fish if they want to learn how to fish.

Yes many questions show far deeper issues that simply the question that is being asked, however the people who ask those questions can easily be split into 2 categories:

  • Those who care
  • Those who don't

The people who don't care are never going to take a blind bit of notice - both you and they are better off if you just give them the fish and let them go on their merry way,

The people who care on the other hand generally tend to be the people who will figure out these sorts of lessons themselves anyway, given enough time.

More importantly, these people also tend to be the sort of people who learn best if they figure something out for themselves. You can tell them that parsing xml with regular expressions is a bad idea, but they won't really know why until they try to do it themselves, fail, and then realise why its a bad idea.


Great question indeed. I think you've already stumbled on one of the key points in the discussion: differentiating between a simple question with a simple answer and a question indicating there's a bigger problem.

For the simple questions, the simple answer is probably best. As you've stated, the person posing the question is likely just looking for a quick fix.

For the questions suggesting a bigger problem, I try to help them see the bigger problem and understand it. If I succeed, then they will be able to answer their own question once they understand the larger issue. That makes them a better developer/architect/whatever.

As one of my teachers once said, my goal is not to teach you this particular set of rules and facts but to teach you to think. Once you can think, the rules and facts are easy to apply.


I usually provide an answer, then expand on it to discuss alternatives or ask more questions about what the use case may be that seems to be driving them towards whatever is causing me to wonder about the question. The reason I try to provide an answer is that, in a very real sense, the question stands on its own. It's not mere the OP whose problem it is that you are trying to help, but everyone who comes after them -- with whatever motivations -- who might be helped. In some cases, though, my answer might be along the lines of -- don't do that, it's just wrong. Sometimes you get punished for trying to improve a person's practices instead of simply answering the question. If you can't deal with that, then just move on, I suppose.


Usually some people inevitably come to the rescue by throwing fish even in spite of an accepted quick solution. Sometimes the total fish carnage is quite respectful. In general most of us like to know reasons why, and we understand by leaving background info we are helping out still, even if a solution has already been accepted or even if we realize we're not apt to get many points. Future visitors to the pages will reap the benefits.

The example cited by the author here might be filled out even more in the future - it won't necessarily always remain a quick fix. That's one of the beauties of SO.

Other side of the coin Likewise where a quick answer is oft given for points sake (I do it too), when the author wants even more info, he/she can draw in more explanation by way of not accepting a solution and asking more comment questions pending acceptance.

You must log in to answer this question.

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