I don't know about anyone else, but

• Homework := here's a rod and reel
• Syntax problems := have a tuna
• Often := try to do both -- the harder you tried to solve your own problem, the nicer the fish you'll get

• Syntax problems := have a tuna

Why not a tigerfish? :-)

But seriously, I agree with your last item. The less guess work others have to do with good commenting and organized code (regardless of whether you really know wtf you're doing or not), the better and speedier (and often, more enthusiastically) someone will be able to help you out.

meh.

This depends on a number of things. A big part of what affects my behavior is, well, me personally. It's how much time I personally have and how interesting I personally find the problem. If I have a lot of time, and I find the problem pretty interesting, I'll spend whatever time I have to come up with a solution.

If it's not a "solution" kind of question, I may spend lots of time on an explanation, or I may only spend enough time to post a search result. Sometimes, I know right where an explanation is, and I can just post a link without much searching.

I have sometimes answered questions from my phone. These answers are very short.

If it sounds as if the poster has not spent much time trying to find a solution, I'm less likely to spend time providing one. If someone has spent a lot of time on something, I might go as far as posting a link to documentation and an explanation specific to their situation and a solution to their specific problem. If I have a lot of time, I may do this even if the OP hasn't put forth much effort.

Sometimes I provide only whatever answer hasn't already been provided. If someone already gave the CPAN link, I might write a little solution from scratch. If they've gotten documentation and a working solution, I might provide further explanation.

Mostly, though, it depends on my time and interest.

Mostly, though, it depends on my time and interest.

I agree. At the risk of stretching the fishing metaphor too far, we all bring our fishing tackle and expectations when we browse the posts. So for example a perl initiate novice (like myself) would be thrilled to "reel in" a simple "homework problem", filet it and have it for dinner. A more skilled perl programmer may be more likely to pass on the small fry. That is natural and overall a good thing.

Generally speaking, I'll just point someone to documentation if:

1. Their question is vague
2. It's obvious they didn't do any reasonable amount of research before asking
3. or when there's not much I could add to the documentation

If it's clear that the querant has tried their even best before asking for help, they're more likely to get an annotated solution -- because, at that point, it's probably the most efficient way of instructing them.

-sam

Although I do try to keep the aphasia factor in mind (thanks, Buk), I tend to find poorly worded and/or presented questions annoying. But I generally try to do my best to ignore these and let others deal with them.

One point to bear in mind is that the answers are useful to others besides the poster. For example, a short snippet that succinctly makes a point can help add to the wisdom of the monastery regardless of whether you think the poster is a good cause.

<whinge>If you have an aversion to perceived homework questions please pass on by. Ease up on the lectures. :-)

I agree with this fully. Sometimes I find myself here after google searching an issue or a better way to accomplish a task I am working on. I generally won't ask something until I've searched this issue and either not found a reasonable solution or just plain don't understand a solution presented. Resources like the monastery are priceless sources for information. For me it is obvious when a poster has done his homework before posting the question. It can be helpful to point to a path that may be applicable, one that the poster had not thought of before, but sometimes, a couple of lines of code as an example can say more than 100 lines of documentation. And as noted, it can help others in the future, who may just simply stumble into it using google, such as myself.

We're all operating on incomplete information here. Our understanding of the poster's problem is limited to our interpretation of his few written lines. We all like to see code to overcome the perceived omissions but this assumes the code mirrors the OP's intentions. Often we draw on our own experience to re-interpret the context. In essence saying "I has this same problem once and It was because of my mis-understanding of XYZ."

If the OP's post is unclear is it because of a lack of intelligence on the OP's part? More likely english is not the OP's native language or the poster is tired and frustrated. I myself have written posts that were less than clear ( to be kind to myself ) and not to the point.

One of things I had to learn when I graduated from a do-er to a teach-er was that people approach learning in different ways. Internally I divide them into the Verbals, the Visuals, and the Readers based on how they absorb information the best. The problem is that in reading their posts it is rare to be able to tell before hand which camp I'm speaking to. Does the OP need a code snippet, a book reference, or a re-interpretation of something he may have already read?

Now most coders are Readers with some characteristics of the Visuals thrown in. Thus the usual response of RTFM. But not all coders are Readers and I've even known a few very good ones that were Verbals. In addition, we've all experienced time when the manual has left us baffled. So it's hard to say precisely what the optimum response is to any question.

I also stop and reminded myself now and again the purpose of this forum, that is to leave a repository of Perl knowledge, otherwise we'd just direct all the SOPWs to the Chatterbox. I hope that my own preference has grown such as to leave a record that may be helpful outside of it's expressed recipient.

I really lost track of where this post is going except to say that I find answering SOPW to be a real crap-shoot.

Sticking with the analogy. If someone is weak with hunger, give'em a fish first to build up their strength. Then think about teaching them to fish.

There's nothing more annoying when you're desperately trying to get to grips with some bigger problem, than being given an RTFM for some annoyingly obscure small part of it, by a self-rightous person you know knows the answer.

Of course, if they come back asking for another fish. And then another. Then it's time to go all permonks on them, but in the first instance a little direct help can go a long way to encouraging better things.

If someone is weak with hunger, its still pointless to cut/paste "perldoc -f keys"

Analogies don't really work if you take them either literally, or too seriously.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

I gave some advice about this a while back in Do my homework for me!.

Unless the situation is urgent, I'll give people enough hints that they can solve the problem themselves. That "aha!" they get from solving it themselves is wonderful fuel for skill growth. Handing out fishes cheats people out of "aha" opportunities.

The other reason is to filter out leeches. I had enough of being the "go to" guy earlier in my career. It was fun for a while, until I saw that I was just enabling one set of people to be lazy, leading to continual, draining interruptions. I don't like to work with lazy leeches. If they're not teachable, I tend to shut them off.

There are already lots of responses, but mine can be grossly summed up in the following short phrase:

Code for code, prose for prose

There are plenty of exceptions, but that's my general rule of thumb.

moritz's response is, IMHO, incredible. It is not unlike the notion of "higher order functions." Here we're engaged in a discussion of inquirers seeking knowledge and how others engage the inquirer to provide the most beneficial experience, and moritz raises the bar: providing us with a higher-order direction that could teach us "is it better to give a higher-order fish or to teach us how to seek a higher-order method of fishing."

Amazing! That appeals to a certain sense of Perl within me; thanks moritz.

ack Albuquerque, NM

What kyle said + if I have a decent answer and there isn't one already, I'll try.

You left out two alternatives though: 1) slap with fish, 2) tell to "go fish." No need to RTFishM for the former. You cannot go wrong with a large haddock.

I think a closely related question to yours is "How good are our current FAQs ?"

A number of SoPW posts would seem to indicate that the poster hadn't read the FAQs at all. It doesn't matter how the document gets refined if it isn't read.

No.
A good FAQ should always exist.
ALSO, making it KNOWN to the users that the FAQ DOES INDEED EXIST is the problem at hand.
So, put the FAQ FIRST in your documentation.That is my suggestion.