This is horrible, and reminds me of the programmer mentality in general. I come as a human asking a question, and instead of answering like a normal person, they grill me until I've proven something to them.
>This is horrible, and reminds me of the programmer mentality in general. I come as a human asking a question, and instead of answering like a normal person, they grill me until I've proven something to them.
And even then they probably don't know the answer, and you will have wasted your time and keystrokes. That's why I never attempt to justify myself to someone just because they want me to. If I anticipate that a question I'm about to ask will engender a lot of "why are you doing it that way?" responses, I'll usually address it when I ask the question, but long ago, I got wise to the people who seem to think that if they don't know the answer to a question, it's the wrong question.
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"?
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.
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.
>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.
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?
>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.
And even then they probably don't know the answer, and you will have wasted your time and keystrokes. That's why I never attempt to justify myself to someone just because they want me to. If I anticipate that a question I'm about to ask will engender a lot of "why are you doing it that way?" responses, I'll usually address it when I ask the question, but long ago, I got wise to the people who seem to think that if they don't know the answer to a question, it's the wrong question.