Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

brian's Guide to Answering Questions

by brian_d_foy (Abbot)
on Feb 28, 2007 at 19:20 UTC ( #602571=perlmeditation: print w/ replies, xml ) Need Help??

[ DrHyde just posted How to answer questions, and I've had this guide sitting on my desktop for several months as I've slowly worked on it. I haven't added PerlMonks specific parts yet, but I figured I should just put it out there. I'll update the orginal post for new stuff to keep everything together, and try to put in update markers where it might confuse the discussion to see new or changed material. ]

Answering questions well is a skill, although not necessarily one in explaining things cogently. Picking the right questions to answer and avoiding the time wasters helps quite a bit too.

What do you get out of it?

Someone has asked a question, whether directly or in a public forum, so you have to figure out if you should answer it. As a Perl trainer, I have to answer the questions from students. It's my job. As a PerlMonks reader, I don't have to answer questions.

Maybe it's not your job to answer questions, but you're the clueful programmer in the team so everyone asks you. Do you stop what you are doing to help? It probably depends on who is asking and what you think of them. An occasional question from another good programmer gets an answer but you try to avoid the new hire who pretended to know Perl and now asks you how to use split because he can't remember that command to look up things and the bookshelf with Programming Perl is way on the other side of the office.

If you want a lot of XP, you answer any PerlMonks question you can, so you get the numerical (and perhaps actual) reputation for being the person with the answer. If you're like me when I was very active in usenet, you use the questions as challenges to learn more about Perl. You might be a rabid Perl promoter, so you answer questions so people think Perl is great because Perl people are nice and friendly. You might also just be a jerk that likes to show people that you know more.

Whatever your situation, you give up something (time, low blood pressure) to answer the question. Is what you give up worth what you get out of it? Being an open source or free software person doesn't mean you have to give stuff away; it's actually built around the principle that you're exchanging stuff with other people by sharing. You share a little here and someone else shares a little there. The questioner might not be sharing at all, although your answer might help other people who helped you, even if you don't ever find out about it.

What you need to know about questions

People ask questions for many reasons, and not all of them mean the questioner wants just pure technical information. Sometimes he wants to confirm that he's thinking the right thing, figure out if he's on the right track, or ensure that all is well with the world.

Questions also socialize newcomers into a community. A Perl newbie may want to participate, but he can't come up with original information simply because he is new to the subject. The answers to simple questions give people a frame of reference they can use to judge the new group and where they stand in it. If newbies never participate they'll remain outside the community as lurkers.

Other people ask questions because they are greedy leeches who think the world revolves around them and that you are compelled, simply by your knowledge, to spend your time answering their questions. These people typically think that if they can't learn something in 15 minutes, they have to find someone to blame. Their time is valuable and they don't like it when you waste it by not stopping your life to spoon feed them, do their homework, or save their job. These people not only think "free beer", but "why don't you pay for dinner too?"

A handful of people ask questions just to annoy you or watch the ensuing chaos. Trolls keep doing it because it keeps working too. People forget to think about what it costs them to answer and what they get out of it.

Finally, most people simply can't ask a good question. No matter how many HOWTOs, guides, or other resources we create about asking good questions, these people aren't going to ask good questions. If they read the HOWTOs, guides, and other resources, they probably wouldn't be asking questions.

What do they get out of it?

Part of my question-answering process is thinking about why the person is asking the question. Part of that means finding the context for the question (that's next), but also to figure out the social implications of the answer.

For instance, someone might ask "Could I delete the root directory?", and I could, without thinking too much about it, say "Yes". But what did I really just answer? Here are some possibilities:

  • He was simply wondering if it was technically possible
  • He's wondering if what he's doing has security implications
  • He wanted me to tell him how to do it (indirect question)
  • He knows how to do it but wants to see if I know how to do it
  • He was asking permission to actually do it ("Well, brian said I could!")
  • He's telling me to delete the root directory (an implied "for me?" on the end)
  • He's avoiding work, but if it looks like he's talking to me, the boss won't be mad
  • He wanted to see if I was actually listening
  • He's new to me and he's using it to introduce himself and establish his street cred
  • He's trolling for a reaction
  • He's distracting me while his buddy steals my laptop (happened at an OSCON, actually, but not to me)

It's a bit of a contrived question, but the literal text is not everything that's going on. Sometimes the answer doesn't have anything to do with the literal question.

Find the real question

Sometimes people ask the question they think they have, but they don't realize it's not the right one. That's understandable if they are new to the subject area or the technology. It actually takes a pretty good grasp of the subject to ask the right question. When someone asks a direct question, hiding all of the context of it, they still might be asking the wrong question. See XYZ Questions

The right answer will almost always depend on the context, and that context might not even be apparent to the questioner. Sometimes, just by asking the question, the questioner figures out what he really wants.

Ask clarifying questions

People are much better at answering questions and directing questioners to the appropriate resources because we can do all of that fuzzy logic stuff that we haven't been able to cram into computers yet.

A good clarifying question is "What are you trying to do?", although it's even better as "What do you want to happen at the end?". Usually, it doesn't really matter how they are trying to do it as long as they get it done. If they were asking a good question they'd have already told you that, but they didn't.

You're better than your computer

People want to ask other people questions. Asking Google or other search engines isn't always that effective since the questioner often can't judge the reliability or quality of the information, even if it comes from a person everyone else knows is a pretty good source. You might think Randal Schwartz is a good source of information because he writes Perl books, but remember that many other people write Perl books too. Simply being a Perl author doesn't mean you're useful, and the newbie can't tell the good authors from the bad ones.

Search engines can't really ask clarifying questions. Google and some others can detect misspellings, but that's about it. They lack the ability (so far), to recognize ambiguity or a lack of context. People can do that, given the right mindset, and ask more questions. Indeed, one of my questions for questioners is often "What are you trying to get out of this?". Forget the actual question and focus on the goal.

In the brick-and-mortar libraries, it's not the books that are the best sources, but the librarians. Librarians typically answer questions about how to find information. Now you're the librarian.

You don't know all of the context

The technical context is just a part of the situation, and you should remember that when you answer the technical question. Often, the asker is trapped by other decisions, such as platform, version of Perl, and other things that might have much better options. Most people think that their situation can be better, but that's not up to them.

I've often been in situations where I'm stuck with what's already installed on the box. I haven't met any programmer that likes that (or, I guess, a sysadmin who doesn't), so don't get too worked up over things the questioner can't control. You don't have to live in his world, so you're naturally a lot more cavalier about what you think someone in his situation should do. I could install any Perl modules I like in my home directory, but what if I don't have a home directory? The target machine might not be one I get to use. I can bundle modules in various ways, but again, maybe the target machine or local policy just can't handle that.

The technical and social constraints don't always align themselves in the best way. It's usually not the questioner's fault, either.

Don't sweat the small stuff

Along with the question probably comes a lot of small details that are a bit off or not exactly right. Some parts may be completely wrong, but have nothing to do with the real problem. Just ignore those parts. An answer that tries to correct every detail dilutes the meat of the answer.

Update:: For PerlMonks, niggling things such as spelling, bad links, and pointers to thinkos might be better in /msg-s. You can still point out the small stuff but you don't make it part of the conversation. It's like whispering to someone that their fly is open, but not announcing it to the whole group. :)

Do you actually know the answer?

Knowing the answer involves the technical chops to handle the question but also the experience to judge its suitability for the context. Unfortunately, lacking experience for the context usually means that you don't realize that you shouldn't answer the question. It's in these situations where I make my biggest mistakes. :(

Another common problem in this area is simply parroting what you've heard other people say, even though you have no real experience with it yourself (which is probably more common to kiddie communities). You can read all the Oracle mailing lists you like, but that doesn't give you the chops of an Oracle DBA. Just because other people say something doesn't mean it's right, so you shouldn't pass it along unless you know it to be true. Alternately, you can simply point people to the place where you read the answer and leave it up to the questioner to decide its value.

Just because you don't know the answer doesn't mean you shouldn't answer the question, but you should be more careful in that case. This is often a problem when you can say something about the literal question, but don't have any experience with the context. You might be able to set up an email server on your home Linux box just fine, but that doesn't mean you know how to set up one for Sarbanes-Oxley compliance, so your answer might be crap.

Still, answering questions is sometimes really just a way to ask questions. You put some information out there and see if anyone complains. Despite the risk of looking stupid and leading someone in the wrong direction, this can be an effective learning tool for the answerer. You won't get better at answering questions if you never try.

In terms of PerlMonks, writing your own sample program and checking the docs to verify what you are going to answer can help.

Do you have to answer the question?

What happens if you don't answer the question? Does the world end?

What happens if you do answer the question? Maybe you get some XP and people think you're cool.

I used to feel compelled to answer any question I could. If I knew the answer, I felt a little bit of responsibility for passing on my knowledge, especially if it wasn't something in the documentation. Now I choose the questioners I answer, asking myself "Is this something I really want to spend time on?"

You might have different questions to ask yourself, but consider what you have to give up or endure. If you don't like newbie questions, stealth homework problems, or looking at code that doesn't use strict, then don't bother with those questions. Why let the cluelack of others take up your time? Control your life by not letting other people control your time.

Maybe the question hasn't been answered by anyone else, so you think you want to jump in there so the questioner doesn't feel lonely.

Good answers have three components

Good answers have three componenets, and I try to get all of them in there (although I may not always succeed). The trick is to educate the questioner about the particular topic, given the context it was in, but make it so he doesn't have to ask the question again. Give him the first fish, but also the fishing pole.

  • A re-iteration of the question that establishes the limitations of the answer, perhaps reclarifying the question in light of other input (for instance, information in replies). This is something I do in speaking engagements, although usually to ensure everyone heard the question.
  • The answer to the question.
  • How the questioner could have answered this on his own (docs, website info, FAQs, etc). This part might take a little bit of research to see what Google says and what the questioner might have found. Even if the answer seems really obvious and it's the top hit in Google, other people might appreciate the link as well as how you found it (i.e. keywords).
Update: Here's some other good Monastery resources and threads, and maybe even some external links:
--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Comment on brian's Guide to Answering Questions
Select or Download Code
Re: brian's Guide to Answering Questions
by jettero (Monsignor) on Feb 28, 2007 at 19:32 UTC

    This is a nice article (as usual) brian.

    Speaking purely about attitudes (not content), I think the three most important parts of answering questions, based on feedback and ++/-- votes are: to care (ie not just about xp), to actually have something to say, and to stay positive. Being amicable saves a lot of trouble and giving people a way to save face avoids flame waring. Whenever I find myself thinking more about xp than the content of my post I end up getting negative xp. Funny how that works.

    -Paul

      and to stay positive

      Although it is somewhat of a subset of Brian's article, I think it is worth emphasizing this. No matter how bad the question is, try to followup constructively.

      -=( Graq )=-

Re: brian's Guide to Answering Questions
by shandor (Monk) on Feb 28, 2007 at 20:00 UTC

    Nice post...

    I'm a question answerer at work. Besides having an abundant amount of patience, I think the key to answering questions is the speed with which you can determine the actual question. If I'm busy at work, I will answer the questions that are asked of me. If I have some free time, then I answer the question the person meant to ask. More often than not, these are not the same questions.

    Answering the correct question should, in the long run, reduce the overall amount of questions you are asked.

Re: brian's Guide to Answering Questions
by hangon (Deacon) on Feb 28, 2007 at 21:34 UTC

    Really good article. I'm a nube to Perlmonks, (but not to Perl) and have already learned a lot without actually posting a question yet. From browsing through the posts I would like to make an observation that may help in answering questions.

    Code is a form of communication. Though obfuscation and obscure idioms are easily understood by the Perl interpreter, this is not necessarily true of humans. All good communication should be tailored to it's audience. Making example code clear and concise with a few embedded comments will help make it understandable to a larger audience.

Re: brian's Guide to Answering Questions
by smahesh (Pilgrim) on Mar 01, 2007 at 03:46 UTC

    Great article brian. I would recommend that this article be added to the list of "must read" articles for new monks.

    Mahesh

Re: brian's Guide to Answering Questions
by shmem (Canon) on Mar 01, 2007 at 09:26 UTC

    Great post, brian_d_foy++

    Some points on What do you get out of it?

    As a Perl trainer, I have to answer the questions from students. It's my job.
    ...
    If you're like me when I was very active in usenet, you use the questions as challenges to learn more about Perl.

    Perhaps you are using the questions not only to work out almost forgotten corners of your skill, but also improve in the art of expressing yourself. I guess some of us may be labelled as "consultant", which is as unspecific as "system engineer", but involves more guessing at needs, expressing yourself, discovering XY problems, keep an eye on appearently unrelated things an so forth.

    If you are like me, you don't think about "what do I get out of it", you simply have the urge, being long time overpaid and helped by others - specially by all those that made perl into what it is today -, to give back. There's little you could give to them, so you give to others. You let the universe draw the sums; it's not your job to keep track.

    Then there are those with a socialist inclination, and they would ask your question as what do WE get out of it? since they rather live up to "first we, then I". I would like to count myself among them more often than not.

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
      You have some urge to answer, so you're satisfying some personal motivation. That might be to advance a political agenda or a desire to shape the world in the way that you want it to be. Those with a socialist inclination usually have it because alone they have nothing but with the group they get something. That's the root of why socialism doesn't work. No matter how much you think it makes sense, human nature involves self-interest, even if you deny that you have it.
        That might be to advance a political agenda or a desire to shape the world in the way that you want it to be.
        Might, but isn't. Trying to advance a political agenda at perlmonks? heh..!

        The only world I can shape to my liking is my own; shaping our world is something that we do, no matter whether humanity is perceived as a integrated we or a disasociated I and them.

        I would be a fool if I denied self-interest; but putting self-interest over social concerns wouldn't be less foolish.

        --shmem

        _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                      /\_¯/(q    /
        ----------------------------  \__(m.====·.(_("always off the crowd"))."·
        ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: brian's Guide to Answering Questions
by rodion (Chaplain) on Mar 01, 2007 at 11:24 UTC
    What Do You Get Out Of It ... challenges to learn more about Perl. ...

    Also, since my work is not Perl teaching or consulting, I have learned a lot about writing informative short Perl, and doing it fast. Now, when I need to write something "quick and dirty" in my work, it's both clearer, and quicker.

    Answering at PM provides two key elements for learning writing; many examples of other's writing that you must read, including examples of very good writing, and practice at it where there is some feedback.

    Speaking of very good writing, the post was not only a pleasure to read, but was for me an especially good example of using <readmore> to deliver two levels of detail, serving both the time-crunched and those more interested. (And even the many of us who are both.)

Re: brian's Guide to Answering Questions
by j3 (Friar) on Mar 01, 2007 at 17:04 UTC

    A question I see asked here sometimes is: ``I'd like to do X. Can anyone recommend a module I should use? Maybe A or B?''. A common reply is, ``Have you searched the CPAN? Maybe try C?''.

    Trouble is, the original poster has probably already searched CPAN and found A, B, C, and others. It, of course, takes time to write examples with each of them, and read all their docs to decide which one looks like a good bet. The OP is hoping to save some of that time and effort, and benefit from other Monk's experiences.

    Seems to me that a good way to answer this type of question is, if you have experience (good or not so good) with a module related to the OP's question, maybe head over to CPAN Ratings, write a short review of the module, then post here directing the user to cpanratings.

Re: brian's Guide to Answering Questions
by perllove (Beadle) on Jul 06, 2007 at 01:46 UTC
    A very well presented argument and time management principle. But I am not yet completely on either side-questioning or answering. If I think the question is simple enough I always use the CB. If it needs more explanation and I have spend some effort on it, or if I find it as an oddity, then I tend to post.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (13)
As of 2014-04-24 09:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (565 votes), past polls