Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Give a fish or teach to fish?

by Anonymous Monk
on Mar 31, 2008 at 20:33 UTC ( #677635=monkdiscuss: print w/ replies, xml ) Need Help??

I've been here for a fairly long time, and one thing I don't think I have a handle on here is when to provide a solution, and when to provide a path to a solution.

Sometimes I think I have a fix on the Perlmonks' feeling on this, but then somebody will code and post a big solution when I thought "perldoc X" was coming, or vice versa.

So, I'm interested: What makes you decide, when you see a SoPW, between various levels of direct help and pointers to documentation/other nodes/CPAN/etc.?

Comment on Give a fish or teach to fish?
Re: Give a fish or teach to fish?
by wade (Pilgrim) on Mar 31, 2008 at 20:52 UTC

    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
    --
    Wade
      • 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.
Re: Give a fish or teach to fish?
by samtregar (Abbot) on Mar 31, 2008 at 20:58 UTC
    To me it depends on how easy I think it will be to find the answer in the fine manual. When someone asks a question about SysV IPC I'm likely to give them the whole solution because I happen to know just how crappy the manuals for that junk are. When someone asks how to get the current year, "perldoc -f localtime" seems like a fine answer.

    -sam

Re: Give a fish or teach to fish?
by radiantmatrix (Parson) on Mar 31, 2008 at 21:02 UTC

    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.

    <radiant.matrix>
    Ramblings and references
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: Give a fish or teach to fish?
by kyle (Abbot) on Mar 31, 2008 at 21:08 UTC

    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.
Re: Give a fish or teach to fish?
by McDarren (Abbot) on Apr 01, 2008 at 00:43 UTC
    As a general rule of thumb, I try to match the amount of effort that I spend on answering a question to the (perceived) amount of effort that the OP has put into asking it. Of course, this isn't always appropriate. It just depends. A bit like kyle, it usually depends mostly on me™ - how much free time I have, how interested in the problem I am, how appropriate/complete existing answers are, what I had for breakfast (or not) that morning, etc.

    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.

Re: Give a fish or teach to fish?
by wfsp (Abbot) on Apr 01, 2008 at 06:16 UTC
    I share kyle's view on this.

    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.
Re: Give a fish or teach to fish?
by starbolin (Hermit) on Apr 01, 2008 at 07:33 UTC

    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.


    "To free a person from error is to give, and not to take away."
    Arthur Schopenhauer
    1788-1860, German Philosopher
Re: Give a fish or teach to fish?
by poolpi (Hermit) on Apr 01, 2008 at 14:44 UTC

    Go vegetarian !


    PooLpi

    'Ebry haffa hoe hab im tik a bush'. Jamaican proverb
Re: Give a fish or teach to fish?
by dws (Chancellor) on Apr 01, 2008 at 18:07 UTC

    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.

Re: Give a fish or teach to fish?
by Popcorn Dave (Abbot) on Apr 01, 2008 at 18:28 UTC
    I agree with dws in that it's usually better to point people towards the fish rather than giving it to them. If it's a glaring error I'll point it out, but I think it's better to steer people to solutions rather than solving problems for them.


    Revolution. Today, 3 O'Clock. Meet behind the monkey bars.

    I would love to change the world, but they won't give me the source code

Re: Give a fish or teach to fish?
by Your Mother (Canon) on Apr 01, 2008 at 20:51 UTC

    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.

Re: Give a fish or teach to fish?
by BrowserUk (Pope) on Apr 01, 2008 at 21:30 UTC

    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.


    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.
      If someone is weak with hunger, its still pointless to cut/paste "perldoc -f keys"
Re: Give a fish or teach to fish?
by revdiablo (Prior) on Apr 02, 2008 at 14:53 UTC

    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.

Re: Give a fish or teach to fish?
by moritz (Cardinal) on Apr 03, 2008 at 07:59 UTC

      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
Re: Give a fish or teach to fish?
by Bruce32903 (Scribe) on Apr 04, 2008 at 01:39 UTC
    It has been many years since I have done homework for school. Back then I worked very hard and was 100% in favor of the "slap them with the fish" comments made by others. Overall, I probably am still in this camp, but there is something to consider that is normally overlooked.

    Somewhere in one of my Perl books there is a statement similar to "Almost everything is possible in Perl, and most things can be done many different ways." When learning and confused the "many different ways" can cause books, Internet postings and RTFM to have a divergent effect on the student of Perl. What is easy to see when you know the answer can be very confusing when the books and helpful experts all seem to be going in different directions.

    Perl is a great tool. But, it is often necessary to overcome a lot of divergent seeming ideas before converging on a workable solution. Also, the shortcuts can short circuit the confused.

    Bruce
Re: Give a fish or teach to fish?
by spx2 (Chaplain) on Apr 04, 2008 at 01:41 UTC
    I think a closely related question to yours is
    "How good are our current FAQs ?Are they really useful/good/helpful
    or does their content send to the user a message homophonic to FAQ?"

    It would be very nice to see better and more encompassing FAQs.

    A related quote to your question is due to Edsger W. Dijkstra:

    "And a second, but not less important challenge is how to mould what
    you have achieved in solving the first problem, into a teachable
    discipline: it does not suffice to hone your own intellect (that
    will join you in your grave), you must teach others how to hone theirs."

      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.
Re: Give a fish or teach to fish?
by tweetiepooh (Friar) on Apr 07, 2008 at 13:19 UTC
    Sometimes being told where to fish also helps.

    This is where I don't know the right "words" to ask the question so "googling" just brings up lots of irrelevant information. Mind you, you can mention that in the question

Re: Give a fish or teach to fish?
by dwm042 (Priest) on Apr 10, 2008 at 12:44 UTC
    I can only say that I answer questions that I think are interesting to answer. Further, I've gone and answered questions and then often I'll look at the answers that already exist to see if I'm just covering old ground. I've discarded any number of answers when Grandfather or ikegami or Corion have already covered the ground that I would have touched on. So, in the context of the question:

    * I only fish when I want to.
    * I toss my fish back unless the fish is original in some sense.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://677635]
Approved by Arunbear
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (8)
As of 2014-09-22 08:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (185 votes), past polls