|Perl: the Markov chain saw|
Re: On Answering Questionsby Abigail-II (Bishop)
|on Feb 09, 2003 at 03:50 UTC||Need Help??|
I don't know why you posted this. What are you trying to say?
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.