[olavk]

Yeah this is common syndrome. An experienced software developer might sense something off in the question, and try to dig into what the actual problem is and find the solution for that. After all, the job of a developer is to solve problems.

E.g. a customer asks - can you make the button so you have to click it multiple times before it reacts? The less experienced (or more cynical) developer say sure, I'm on it. The more experienced developer (annoyingly) ask "what do you really want to achieve"?

[psyc]

The very assumption that there is a larger solution behind my question, and that I am really looking for a best practice with regard to this putative solution, is itself a hasty conclusion. I'm often searching a question because I want to know the answer to that question, so that I can use that knowledge in future solutions. In those cases, not only have you not properly imagined what I'm going to do with the answer, I haven't imagined it either.

I realize that a lot of this comes down to asking hyper-logical pattern completers to stop being hyper-logical pattern completers. And that is in a sense one of the main motivations behind April Wensel's campaign to improve SO.

[olavk]

Exactly...that is why you ask clarifying questions. And if you post a question on SO is a great idea to include contextual information which helps clarify what you are trying to achieve.

A bit of context like "I'm on an embedded platform, so I can't use heap allocation", or "the HTML is for an emai'l, so I cant use JavaScript" also goes a long way to avoid the annoying "why don't you just..." comments.

If you peruse SO you will notice quite a lot of questions simply does not make any literal sense because of misuse of terminology or just lack of understanding. Very often questions arise exactly because the person have a wrong mental model of how the system is supposed to work. Which means the question will reflect this misunderstanding in the way it is posed. Just answering the literal question is not helpful and in many cases simply not possible.

[rhapsodic]

>Just answering the literal question is not helpful and in many cases simply not possible.

If you can't answer it, or don't want to answer it, then don't answer it. But please don't be the annoying, condescending know-it-all who is always there to provide an unsolicited lecture.

[olavk]

A typical example is "I want to keep my JavaScript code secret. How do I disable the 'View source' menu item in browsers?" This is a very frequently asked question. What would be the most helpful answer, if you imagine you are a newbie asking in good faith?

1) No answer

2) A technical explanation of how the 'view source' menu item can be suppressed (e.g. iframe, overriding right-click events and so on) which may at least work in some browsers some of the time.

3) An explanation why it is simply not technically possible to hide code sent over the wire to the client, and a suggestion to move sensitive code to the server if this is possible.

Clearly (2) is closest to the technically correct answer to the question... but it is it really helpful? Option (3) do offer unsolicited advice, which could be construed as condescending since this is not what was actually asked. But I will also argue this is the most useful response in 99% of cases.

But there might be some specific cases where (2) is actually relevant. E.g I'm building some kiosk-style console to provide an interactive quiz, and I don't want users to cheat by using view source to see the answers. In this controlled environment, it might be possible to completely disable "view source". So providing both (2) and (3) is the optimal answer, and should get the green checkmark.

But I simply fail to understand how giving no answer could be better for anybody?

[psyc]

Parent said:

> If you can't answer it, or don't want to answer it

Here is how I would rank answers from best to worst:

1. Give the correct answer to the technical question asked, and some background about when to think twice about using it

2. Give the correct answer to the technical question asked

3. Why you should rethink the approach

4. No answer

5. "Don't do it"

[rhapsodic]

>E.g. a customer asks - can you make the button so you have to click it multiple times before it reacts? The less experienced (or more cynical) developer say sure, I'm on it. The more experienced developer (annoyingly) ask "what do you really want to achieve"?

That might be an appropriate response to someone in your own company. But when it's a stranger asking a specific question in a forum where such questions are asked, I give them the benefit of the doubt that they have good reasons for asking their question. If I can't answer it, I simply ignore it.