From a recent email exchange in one of the many mailing lists I follow:

One of the answerers: You asked one question when most people who use {product} know that's not the right question to answer.

Original questioner: Please don't second-guess my questions. If I wanted a different question answered, I would have asked a different question.

Yours truly:
Uh, no. As a frequent question answerer, I tend to think as much
about the context of the question I'm answering, as the answer I'm
writing, just in case there's something missing. And I'm free to
question the context as much as I am free to answer the original
question.

If you had not wanted to be second-guessed, you would have stated more
about the context of your question, so that we wouldn't have to wonder
if you're doing something the hard way.

Every question is a piece of an answer to a larger question.
Sometimes, it's worth backing up a step to ensure you haven't painted
yourself into the corner.

To presume you've already solved the issue that led to your question
in the best possible manner is to have an arrogance that will only
irritate the people from whom you seek guidance. :) Remember, you've
only solved that level to the best of your ability.

Public answers to public questions also benefit those who haven't asked the question yet, or who haven't articulated the question, or who haven't dared to ask it for fear of being embarassed in public. So quite often a public answer carries an implied "Maybe you want only your specific question answered, but others reading along might benefit from hearing more."

Whilst a man of your in-depth experience and knowledge will often be able to divine more context than supplied, and therefore often be correct in answering, "You asked the wrong question!". Every now and then, your divining rod will give you a false twitch with the result that you end up irritating the questioner as much as he has irritated you.

As a questioner who sometimes explicitly removes the context from my questions deliberately, in order that I may seek answers that move beyond, around or under received wisdom on a particular point or subject, I don't mind receiving the answer. "Wrong question!" if comes with at least a little context of it's own. Ie. Why is it the wrong question. As a quite young man, I got really miffed by parents, teachers etc. that would answer "why?" with "Because I say so!" or "Because that's how it's done!". At 7, I got into trouble for walking 2 miles each way to the local library in order to read books on electricity. (Anyone remember Bibani book?). Of course, it was a good few years before I began to understand them, but I did so hate being told, "You wouldn't understand".

The problem with this medium (web) and email, is that unless you're personally or professionally aquainted with the questioner, you can never be quite sure who you are talking to, or what level of knowledge, expertise or understanding they may have. If James Watt, Benjamin Franklin, Thomas Edison or Einstein hadn't questioned the current thinking of their day, many things we now teach in high school, and take for granted every day, would not be around, including in their case, the computers we are using to communicate. Likewise, Mr. Wall questioned the wisdom of C, shell scripts etc. You, must have said "there must be a better way" to yourself before you came up with the ST? Every new thing comes out of questioning the status quo, and sometimes that means making a mental leap a step beyond current expert opinion.

Of course, I've no way of knowing how much if any of this can be applied to the facts of the particular case you cite, and I have no doubt at all that in 99/100 cases, the questioner really is lagging behind the experts (or even the simply accustomed) in knowledge, but even then, it's sometimes better to learn by making your own mistakes than having to take things as read.

It doesn't usually take that much longer to type "That's the wrong question because <10 words of explaination or pointer to same>". And it's always worth keeping an open mind that, just maybe, this questioner has asked/phrased his question in a particular way because he thinks he sees something new, different, unique. 99/100 times he will be wrong, but it's the 1% that makes life interesting. Engaging in a litte open-minded debate may just lead to something worthwhile.

Examine what is said, not who speaks.

The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.

What if someone asks for advice on how to commit suicide? Do you answer that?

What if the person is asking for advice on how to do something that will be really bad for their code-base, which you know will be bad for their code-base (eg obvious insecurities, sources of major bugs)? What then?

Read http://perl.plover.com/varvarname.html and follow the links to see one example of a common question that should not be blithely answered as asked. Another example is how to set up some of Matt Wright's scripts.

Opps! I did it again. Had an opinion that is. I should probably not answer this, but it's simply too provocative.

In reverse order:

Another example is how to set up some of Matt Wright's scripts.

I would tell them that I cannot help them with that, but that I had heard that Matt's script are notoriously difficult and dangerous to use and suggest that they might find it easier to visit NMS instead.

Read http://perl.plover.com/varvarname.html and follow the links to see one example of a common question that should not be blithely answered as asked.

First Perl did not have hashes references (*thanks jdporter) for many years, and symbolic references where used a lot. Done properly, it can be an amazingly powerful and useful feature.

Many of perl's native abilities can be be dangerous if used incorrectly, or as in the case cited by MJD in your reference, used without proper forethought for the consequences.

Finally, I never advocated doing anything blithely. I think said,

You move on dodgey ground when you assume information that isn't in the question

On even dodgier ground and risk offending or being offended when you make judgements on the questioners skill levels, background or motives based on one question.

Can soften the blow of the suggestion that the questioner is going in the wrong direction by giving a little context or a link explaining why. MJD's piece makes a fine example of this.

I would usually say something to the effect of:

Are you sure that's what you want to do? If your sure, read Perlref and by the time you've done so, you will probably understand how to do it, but more importantly why you almost certainly don't want to. Beyond that, if you'd care to explain a little more about why you want to do this, someone may be able to show you a better way to acheive your goals.

I realise some would read that as patronising, but if they do, that's their problem not mine.

What if the person is asking for advice on how to do something that will be really bad for their code-base, which you know will be bad for their code-base (eg obvious insecurities, sources of major bugs)? What then?

First off, I don't know. I can hazard a good guess, but they know better than I and as you point out, it is their codebase

What if someone asks for advice on how to commit suicide? Do you answer that?

After much typing and deleting, I've decided to pretend that pair of questions was not asked. If you want to have a serious and deep debate on a very awkward subject, I'm sure we can find somewhere more suited to that than PerlMonks.

And I guess that is a lesson in its self. Noone is forcing us to answer either way. Likewise, if I choose to give what I think is 'good advice' and it is rejected, I tried. It's enough. Perl doesn't enforce good practice, hence warnings, and strictures are optional. Personally, I'd probably invert the default, but I'd still make it optional.

Updated to close UL tag and correct brain fart.

Examine what is said, not who speaks.

The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.

In many respects I am/was like you. Always asking the annoying questions, sometimes far more advanced than I probably had any business asking. So naturally i'm sympathetic to what you say. But there are some questions that really aught to not be directly answered. For instance a novice comes here with some code that depends on getting symrefs to work right and asks us to tell him how to do it. Well, most people would reply "dont do it that way, do it this other way". The point being that there is almost no chance the questioner would ask the question, the way they asked the question, if they properly understood this other point. So if they then got stroppy and insisted I answer the question directly I would refuse and then quote one of my old signatures (resurrected for this post and coincidentally a subject of private discussion earlier today :-)

Still, dont you hate it when some say "cause" when they really mean "I have no idea" :-)

--- demerphq
You probably shouldn't use symrefs until you can explain why you probably shouldn't use symrefs

Engaging in a litte open-minded debate may just lead to something worthwhile.

LOL ;-) I seem to remember answering a question that you *hadn't* asked a while back which led to increasing child like indignation (probably more on my part than yours) and as you say with the result that you end up irritating the questioner as much as he has irritated you

I would have included a link if I was not so embarrased by my childishness - I blame that bottle of red wine. Again.

Something a good friend taught me that a mentor taught him: When faced with a question he'd often pause for a moment then ask, "What problem are you trying to solve?"

I'm on both sides. Sometimes questions are specific and warrant a specific answer. Other times you need to ask, "What problem are you trying to solve?" Often you can tell the latter type of question by the complete lack of context surrounding it.

Related tangent: I personally believe it's worth asking (maybe several times) the questioner to elaborate. Often by having to formalize a question in writing, the questioner arrives at the answer himself. It's the same reason programmers should provide high level docs. to their interfaces.

I saw a question on a JavaScript newsgroup or forum, which was essentially "how do I get checkboxes to behave like radio buttons?" -- how to get a set of checkboxes where if one gets checked, the others become unchecked.

Three or four people gave solutions -- it's not hard to get an array of all checkbox objects and check or uncheck them programatically in JS -- but only one said "that's a terrible idea! Checkboxes are checkboxes and radio buttons are radio buttons. You will upset and confuse your users if you do this". That's a much better response than just telling them how to do it, because they've misunderstood something fundamental, or they wouldn't be asking.

I often see on PerlMonks a kind of intermediate variety of this problem. It's not "how do I do (something stupid or dangerous or wasteful)" it's "I want to do (something quite sensible-sounding) and I've already determined that I'll do it such and such a way, and I'm stuck, please help me".

It's like someone's written "I want to get a screw into some wood, but my hammer's handle is slippery, what shall I use to make the hammer do the job better?" and you have to say that a screwdriver is the correct solution. And probably just as often, the person asking says "I want to fix two bits of wood with one of those metal things, which hammer should I use?" and you have to encourage them to explain whether it's a screw or a nail in a follow-up post.

--

Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.
M-J D

The right way to use a screw is with a screw-driver right! Well, yes and no. The right way involves clearance drilling the outer peice of wood prior to screwing the two together so that the bearing surface of the screwhead comes to bear before the two pieces of wood are forced apart by the action of the screw threads. Alternatively you can use a screw with a threadless shank equal to or greater in length than the thickness of the outer piece.

However, in the days before portable drills where commonly available, carpenters working on remote locations or temporary structures (eg. shuttering) would drive the screw part way through the outer piece of wood (think 1/2 inch ply) with a hammer. This effectively clearance drilled the outer piece, and provided a firm hold for the screw upon which they could use their "lazy susan" screw-drivers to drive the screw home into the second piece of wood and finish the job. Quick clean and secure provided you don't drive the screw too far with the hammer. It takes expertise. They even made specially hardened screws designed for the job.

Similarly, you don't hit a screwdriver with a hammer right? When screwdrivers had wooden handles, chippy's often had screwdrivers with extended tangs (the bit that goes inside the handle) that passed all the way through the handle and protruded slightly above the end of the handle. This allowed them to strike the end without splitting the wooden handle. This is useful for loosening set or paint covered screws. It also allows the screwdriver to double as a bradawl(sp?). They could carry a seperate bradawl, but thats one more tool to carry (up and down ladders), to manipulate (when they need all three hands just to hold the 8'x4' they are fixing) and to loose.

As with all tools, there are generally 2 ways to use it. There's the safety-first, beginners way. Then there's the expert's "I know what I can get away with" way. The best perl example of this is described much better than I could in Paradigm Shift - Don't use strict.

"But if the guy's an expert, why does he have to ask the question? Well, he may have the expertise from another language, understand the pro's and con's but be lacking on the particular form of perl syntax. In REXX, compounding one variable with another (or a bareword in perl terms) to form a third is standard practice. If fact, using REXX's content-addressable arrays, is the only way to form any compound data structure. To create an array, you use syntax like:

file = 'myfile'
array = ''
do for index=1 by 1 while lines(file)
array.index = linein(file)
end
/* print the 5th line of the file */
say 'the fifth line was ' array.5

Someone used to this language, might, in the absence of a REXX interpreter, try to use Perl to get them out of a hole, and might try to use symrefs, but get bitten by the syntax differences. Sure, given the time to learn the language, perl has much better ways of dealing with this situation, but time isn't always on the programmers side.

So whilst this may be a contrived and rare example, it is concievable. Without context, they are indistinguishable from the raw beginner. Without context, they may seem to be in an indecent haste. If you've ever been an expert floundering outside your field, with enough expertise to make the suit but for the lack of a thread, you'll sympathise with my hypothetical rexxspert. (Who, by the way, isn't so hypothetical and isn't so very far away).

Do I advocate "Give'm the rope to hang themselves"? No. Do I try (but not always suceed) to avoid saying "You don't wanna be doing't that way!". Yes. At least until I get a feel for the who, why & when of a situation.

One man's opinion. Right or wrong is for each to make up their own mind. YMMV.

Examine what is said, not who speaks.

The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.

After reading the debate on the merits of using hammers versus screwdrivers to screw two pieces of wood together, I couldn't help wondering why most of us use (and advise others to use) a "Swiss Army Chainsaw" to do it. :)

__________
"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work." -- (Author Unknown)

I have to agree with both sides.
As somebody that asks questions now and then, I know that I sometimes intentionally leave out the context of what I am trying to do, sometimes I will want to know if what I am thinking to do is possible, and sometimes I'm really looking for a solution using the tools I name, because boss/company/coding standards say that it has to be done with them, even if you/I/rest of the community knows that it can be better done with other tools. The problem is that usually the questioner knows all this, but forgets to tell his audience: "I have been told to do X with product Y ... *insert question here*." At these times I am also frustrated when all I get is answers to the tune of "You dont." "You shouldnt" "Use product Z instead".. (I hear a *lot* of these on some chat channels when people ask stuff like 'How do I do XYZ in Windows' and 90% of the answers are 'Use linux' - What sort of answer is that? These people make me mad...)

So, when answering such questions, it is, as you say, a good idea to try and find out the reason for doing things that way, just answering 'This question doesnt belong to this product', or simliar, is not good enough, in my opinion. One also has to say why.
The response of the questioner is equally too short, 'because I need to' is not helping anyone answer the question.

In short, if I'm confronted with such a question, where I think the questioner is asking the wrong question, then I do one of two things. Either, answer to the effect of 'You could probably do that like this *psuedo-code*, but you'll eventually find out that its better to do/use XYZ', or, I don't answer at all, since I don't have an answer that fits the question. That may be chicken, but either somone else will, or the questioner may try out for him/herself and figure out that that wasn't what they wanted.

I usually don't try to second guess questions. It works counter
productive. For two reasons. First, in forums like perlmonks, where
there are a lot of not-so-knowledgeable answerers, there's a lot
of noise of people trying to second guess answers; spawning threads
that have not much to do with the original question. Today I read a
question on comp.lang.perl.misc; someone had a problem parsing command
line arguments. It didn't work as he expected in certain cases, and he
wanted to know why. There were five or six replies, all pointing to one of
more of the Getopt:: modules. All were second guessing the question. The
questions appeared to be helpful, but were they? The question wasn't
answered, and the poster didn't learn much. The problem was an off-by-one
error, using $i < $#ARGV instead of $i <= $#ARGV
or $i < @ARGV.

The other reason is that it makes people sloppy. Why would I formulate
a question well instead of ambiguous if people try to second guess my
question anyway? Someone might get it right, and it's not my time wasted
of the five who guessed wrong, and answered a question I don't care about.
A clear example of that are questions that look like:

How do I extract 23 from fubble wabble 23 upupup.

One person will write a regex to extract the third word, another to
extract the digits from the text, and a third uses substr
to extract the 15th and 16th character from the string. Now, it's likely
the original poster is pleased, and got his answer. But at least two
people have wasted their time, writing an answer to a question that was
neither asked, nor intended to be asked.

If answerers wouldn't second guess questions, questioners would be forced
to well formulate their questions. Then answerers can focus on the right
questions, instead of questions the questioner isn't interested in. And
well formulated questions have another benefit, which I will illustrate
by a story.

For a long time, outside the office of the sysadmins at MIT,
next to the door, there was a table. On the table was a teddy
bear. On the door was a note, saying that before entering the
door with a question, you better first explained your problem
to the teddy bear. Many people didn't need the help of the
sysadmins after telling the teddy bear.

Many people can solve their own problems, if they stop for a moment and
actually think and formulate the problem. A well formulated problem
is often more than half solved.

This is a debate that is as old as Usenet (at least), and will never leave us as long as society (especially our online virtual one) is made up of various levels of skill.

We all differ, some of us are highly skilled, in Perl, in the ability to articulate (a question or an answer), and in understanding our fellow human beings. Most of us, however, fall short on AT LEAST one of these, and it is this that makes life both interesting and frustrating.

How much "interaction" would there be if we were all Larry Wall clones? Very bright bunch, no doubt, but not much to say to each other ... BECAUSE we all shared the same skill levels in Perl, in Communication ability, and in Understanding.

No matter what we say, we all come here from common motivations, to learn on the neophyte's part, to share on the "expert's", for whatever reason. That being the case, how long would PerlMonks (or any other Virtual community) survive if only the Senior Monks (? Abbot+ ?) could ask questions? Sure, they would be very interesting questions ... to other senior monks, but the rest of us poor mortals would say "Gee Wiz, aren't they clever!" and wonder off somewhere else to learn the basics of Perl.

So, what's my point? ... We seem to have two fundamental differences of approach to how to handle neophytes who do not yet know how to ask questions. The first is to treat them like the "Open Sesame" doors of fairyland. If you ask the question right, you will get all the riches of the land, as well as the princess. If you don't formulate your question correctly, well, tough, hope you've got an umbrella.

I agree that people should learn how to formulate questions. I agree that people should first figure out what they can. I agree that people shouldn't be spoon-fed.

I also think that those of us who are advocates for Perl, and those of you who actually know how to use it, should be gentle on those who still have certain skills to develop. We should be evangelising the use of Perl, not protecting our turf. (I am NOT implying that anyone here did that). Very often we frighten away someone who may, over time, have become a useful member of the community.

If, when someone asks a question in a vague or obviously poorly thought out way, instead of lambasting them (however gently), we said something to the effect of:"I'm sorry, I don't understand exactly what you want. Could you please repost your question and provide us with some background (context) and a fuller explanation of what you do want to achieve, then maybe we'd be able to point you in the right direction."... a bit syrupy, I agree, but the idea is, let's be helpful, not hurtful ...

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other