Writing answers for newbie questions

[cLive ;-)]

I've fallen for this myself, but have recently noticed a few others doing so and wondered what people thought...

When a newbie asks a question, is it always best to answer with the most efficient code? I don't think so myself. I think it's important to help them gain the building blocks of 'baby code' needed to help them understand the answer and not just know the answer.

I think we should try to remember some basic rules when answering a newby question:

• this may be their first attempt at Perl and they may not know what functions are available (don't RTFM them - learning what functions do what takes some time. If they are in their first week of Perl, we don't want to scare them away!). Of course, that doesn't mean you shouldn't point them to the RTFM page.
• rephrase their question before answering if they have asked it very fuzzily
• comment answers well
• point to functions/modules you use and explain why you are using them

The temptation is always there to show how much you know (and yes, I'm guilty of answering some questions from that perspective), but what we should be trying to do is answer questions so that we help increase their knowledge.

A while ago I suggested we had a node for 'newbie questions'. I think this would be good, because it could have the specific rule that the answer is explained properly as well as answered properly. Eg,

-- for:

$string =~ s/\s+/ /g;

++ for

# replace all multiple whitespace characters from $string
# \s represents a whitespace character (space, tab, newline etc)
# + means 'one or more'
$string =~ s/\s+/ /g;

ie, this section would encourage you to -- answers that answered the question but didn't really help the questioner.

Well, that's my .02. What do you think?

cLive ;-)

[nysus]

I personally don't mind when others "show-off" their coding ability. It shows me what is possible. Of course, I'm getting to the point where I can actually make some sense out of it after staring at it for 15 minutes.

What would be great is if more intermediate monks like me would post their less-than-elegant code right along with the 0 handicap golfers out there. I just did this over at this post. We shouldn't get discouraged just because our answer isn't the best answer and go ahead and post our crap code anyway. Besides, it's great practice for us.

So I vote to let the advanced users continue to show off. But less than godlike Monks need to be encouraged to chip in even if their answer is not the equivalent of erecting Stonehenge.

One more thought: Too often, the newbie asks a question, gets some answers, and that's that. But I'm sure the newbie still probably has lingering questions but doesn't want to look stupid with a follow-up question (I know I did this). It would be good if the person answering encouraged dialogue. I think a simple "Let me know if you don't understand anything and I'll be happy to help out" would go a long way to finding where a newbie really needs help.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot";
$nysus = $PM . $MCF;

[thpfft]

I've often thought that the best answers come from a rung or two up the ladder, rather than echoing down from olympus. They tend to be closer to the language and vocabulary of the questioner, and what they lack in authority they sometimes make up in immediate applicability.

there are obvious exceptions, where people draw on their experience and expertise to produce a commanding, if occasionally irascible, explanation of exactly why so and how, and those answers are treasurable. there are also people here who are very good - and remarkably patient - teachers, whom i certainly don't want to discourage.

but there also many cases of people either wasting their talents pointing out that CGI.pm is helpful, or becoming needlessly irate at the stupidity of it all.

i can answer simple questions, but i don't because someone more expert is bound to do so. perhaps it would be better if i did? then those who know better than i can inspect my answer rather than having to deal directly with the newbie stuff. their comments will be valuable to me, as mine are hopefully useful to the original questioner. The godly would be free to deal with the problems of bishops or just get on with optimising Pony.pm, or whatever they do up there, and generally keep an eye on things in case the occasional thunderbolt is required.

In which case, to address the actual question for once, the ideal would be to consider each answer in terms of its likely usefulness, firstly to the person replied to, then to the community. usefulness here includes understandability, applicability and educational value as well as rightness and elegance.

i'm inclined to ++ good intentions and -- pointless exclamations, too, but i guess that's a question of taste.

just two of your mercan c

[lemming]

-- for a correct answer? I don't think so. I have --'d for rude answers, but that's different. On the other hand, I respect an answer more, that shows the journey as well as the destination.

Update: To expand on my first point, if a newbie sees an answer that is correct with a low or even a negative rep, that may steer them wrong.
If you don't like an answer due to it's brevity, write a node that explains the concept, but to -- a node just because they didn't show their work is wrong IMO.

That said, I think it's a good idea for people to explain their answers.

this update brought to by a /msg comment

[VSarkiss]

Well, showing efficient code is not necessarily a bad thing. I think the problem is when the newbie's question gets twisted into a golf challenge! If someone's new to the language, I think it's better to provide them with something that may use up a few more symbols, but is easier to understand.

The recent thread on Removing Duplicates in an array is a great example. The first answer is an RTFM , followed by two rounds of golf. I'm not pointing fingers at the people who posted; I've done all of these myself. (I think RTFM answers are appropriate sometimes, but indicate where in the FM to R! If a clear and detailed writeup is available, provide a link to the node or external page.)

I don't think a separate node type or area for "newbie questions" is really necessary. We just need to indicate somehow that the emphasis in SOPW answers should be on clarity and simplicity of the code. Efficiency always counts, but don't sacrifice legibility and ease of understanding for a few cycles.

[Tiefling]

Ok, I admit it, I'm the person who teed off the golf in that thread.

I'm a newbie myself, as davorg and others know. I wanted to see what ways of doing what I suggested there were, as a means of getting a better grip of the language. Admittedly, I'll need to pick over MeowChow's answer with tweezers to understand it, but I certainly didn't intend to make the thread as a whole inaccessible. There were clear, nicely stated pointers there to the right answer. I was attempting to highlight the fact that the right answer was attached to the 'wrong' question in the FAQ - which I felt was unhelpful to, er, newbies.

Addendum: I'm tired of being asked to use Super Search. It's a nice feature and all, but sometimes I want to ask the question that's on my mind, in English (or $human_language in general) of real people and get an answer that relates the WTDI to my own application.

Tiefling



-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d++ s:- a-- C++ UL P++ L++(+) E? W+(++) N+ o? K w+(--)
!O M- V? PS+ PE- Y PGP- t+ 5 X+ R+++ tv- b+++ DI++++ D+ G+ e++ h!(-) y
+?
------END GEEK CODE BLOCK------

[Abigail]

I disagree. I'm not going to explain every function or module I use. Then it takes me hours to answer some questions. That's what the TFM is for. If you ask a question, get an answer which uses function foo you don't know about, is it too much to ask to spend a few seconds typing perldoc -f foo in a different window? Should authors really cut and paste the documentation for every question they answer, just because the asker of the question might be a newbie? (How do you know? Do they smell different?)

As for

    $string =~ s/\s+/ /g;

I fail to see what the problem is with that. If there are parts in the code the reader doesn't understand, (s)he can look it up. Now the excuse of "I don't know what to look up" doesn't hold.

One last thing. You mentioned the infamous baby code. Is there an official piece of documentation that lists what's part of baby code and what isn't? Because only then, one can answer in baby code. Or does every one has his/her own baby code, which just happens to be the set of constructs the person knows about? Perhaps everyone signing on for Perlmonks could fill out a form with 2500 tickboxes, marking all the commands and constructs they know about, making that their own private baby code. Then people can study those sets and adjust their answer. Keep in mind that people are learning, so you would have to force them to update their pages at least weekly, but preferably daily.

BTW, don't you think showing people constructs or functions they haven't heard of before is the best way to get them out of the baby code stage, and into the world of full Perl enjoyment?

-- Abigail

[footpad]

It is written in the Third book of Camel:

Most important, you don't have to know everything there is to know about Perl before you can write useful programs. You can learn Perl "small end first." You can program in Perl Baby-Talk, and we promise not to laugh. Or more precisely, we promise not to laugh any more than we'd giggle at a child's creative way of putting things...Any level of language proficiency is acceptable in Perl culture. We won't send the language police after you. A Perl script is "correct" if it gets the job done before your boss fires you.
--Preface, pp xix-xx. (emphasis added).

No one expects you to "dumb down" your experience or writing style to Baby Perl, however, I've found that the wisest of comunicators understands, at least in part, the amount of "TRVTH" their audience can take in a given session. This is, I think, part of what [merlyn|Larry|Tom|whoever](*) was getting at when he wrote the above.

(Note, that's an assumption, one based solely on his writings here and elsewhere. If it's a bad one, then please feel free to insert the proper author's name. The point being the same...whoever originally keyed those words understood that Perl is a language with many levels and many subtleties...and that everyone must learn to crawl before they can leap tall idioms in a single bound...yes, even Clerk Kant.)

I agree that we should be willing to challenge people as needed and as appropriate...however, is it not true that each finds their own path along the Perl Way? Is it not true that some may need to work their way through less than ideal solutions before they arrive at the "best" ones? Also, who's to say that any single solution is precisely the exact answer that's best for every need? Each problem is unique, as is each poster. Some approaches are more effective than others, certainly...however, I believe that part of Perl's flexibility stems from the fact that someone understood that it was better to provide flexible interfaces and tools, rather than rigid, dogmatic ones (ala C++, imho).

Personally, I have no problems asking for clarifications when I don't get it. However, not everyone has that much of a spine. Some would take an RTFM screed far more pointedly (and personally) than others...and that's (in part) why I think the Monastery has a bit of a bad rep regarding the treatment of newcomers.

Finally, as someone who has spent hours composing replies in other fora...yes, it sometimes takes that long to hazard a good guess. However, when you do it correctly, you gain more than the "win" of being right...you also help someone else see the light. In addition, you also help those that aren't directly involved in the conversation..yeah, the lurkers. Your online words have a broader audience than your RL-words.

No one doubts your skill and we're certainly now asking for a line-by-line breakdown. However, when you're doing something that might seem tricky to a new person, it doesn't seem unreasonable to include HREF links, man page references, or other Resources for further consideration. Signposts, if you will, into the land of imagination...the Twi...Oh, wait...sorry. Wrong intro.

--f

(*) - Update: I've been told via a private /msg that passage was originally written by Larry himself. Can anyone confirm that?

[Abigail]

I am aware of the quote in the third Camel. However, said quote only mentions the existance of Baby Perl. It doesn't define what Baby Perl is. In fact, it strongly suggests everyone has his/her own Baby Perl.

And that's just fine. However, in no way this quote implies one should be expected to be addressed in Baby Perl. There isn't a single book written in Baby Perl. No manual page in the Perl distribution talks in Baby Perl. Yet many books are aimed at beginners, and so are tutorials in the main distribution.

Here's an experiment. Get married. Get twins. Call them Angela and Bobby. Separate them. Expose Bobby only to language at his own level. "Dadadadadada" when he's a baby, and one syllable, one word sentences when he's a toddler. Only use words he already knows. To Angela on the other hand, you only talk normally. Normal sentences, with verbs, subjects and objects. On each birthday, compare their linguistic development. Describe the differences. Motive your answer.

And even if you remain convinced you should talk Baby Perl to people asking questions, you still have a practical problem. You will not know what they know. Will you not use a substitution in an answer because you think they don't know substitutions? What about hashes? grep? strict? -w? Perhaps they don't know open has a useful return value. Should you ignore the return value in your answer? Not use CGI.pm? Not use pack? Not use substr?

-- Abigail

[tilly]

This is a request.

If you see a question whose form and/or content indicates an extreme lack of clue, then either do not answer or else take the time to explain what you are using. Saying politely that the documentation is helpful is useful but insufficient. For the truly clueless it is useful to give an explanation of how to navigate documentation.

Here is an example of what I mean by an explanation of how to navigate documentation.

Also note that just inspiring someone to learn more does not mean that they know how to do that. For instance you offer an example of a substitution which most Perl programmers should be able to understand. But if someone does not, then they problably do not know about perldoc, do not know what a regular expression is, and will have no way to find perlre. So while I would answer a question with that answer, if I got a follow-up question I would be willing to respond with some combination of an explanation, a mention of perlre, a recommendation for the Owl book, and a recommendation for japhy's YAPE::Regex::Explain.

Furthermore if you can find ways to subtly phrase things in a manner that indicates that you are actively trying to be helpful and impart knowledge, that is always good. For instance rather than just say that someone should have done a search, point to the search engine, say that the search engine is really helpful, and link to the result of a basic search. That passes on the same information but leaves the questioner happier and more likely to follow your advice. I find the small additional energy expenditure more than made up for by the energy savings from less conflict.

Again, if this sounds like too much work for you, then don't answer that question. Move on to a question that looks like it comes from a more sophisticated user. If the question is basic, it is a safe assumption that someone else will answer it. If there is some subtle mistake that you think people are likely to make, then it is typically most useful for all involved for you to wait for someone to misanswer the question, and then politely correct the bad answer. More than anything you can say, this flags the point as something people can easily get wrong. Plus at least one vocal person is now going to pay attention to your answer and is likely to answer the question correctly the next time.

[Abigail]

For instance you offer an example of a substitution which most Perl programmers should be able to understand. But if someone does not, then they problably do not know about perldoc, do not know what a regular expression is, and will have no way to find perlre

Neato. So, I guess we should now cut and paste documentation of everything you use in answering a question? After all, of anything you use to answer a question, the person asking might not know about. And since there's no way to tell, (because I don't think anyone here would suggest the person asking needs to do anything more than the minimum, so just telling what said person knows or does not know is out of the question), all you can do is assume the person asking has zero knowledge.

Is it ok to cut and paste the entire OED in each posting? A person might not know a certain word you use, and it might entirely be possible the person asking doesn't own a dictionary. Hmmm, perhaps the OED isn't enough, and we should also translate the OED to all possible languages - just in the off change the person asking isn't a native English speaker. Oh, and of course we should include pictures as well, perhaps the person can't read either!

-- Abigail, thinking questions about consulting documentation should be seen as separate questions - which, once answered, could be linked to from for instance the front page.

[John M. Dlugosz]

Hmm, sounds like some macros would be helpful. On the server side, something like [rtfm://super search] could expand into an entire paragraph.

[jeffa]

Almost. I think a better way of elevating people into the world of full Perl enjoyment is to show them WHY they need that new construct or function. Otherwise, it's just more noise to those that aren't ready to receive higher knowledge.

Just showing is not really enough. If someone takes a brilliant one-liner and adds it to their program or application without knowing how it works, then that is really just black-box reuse.

But for God's sake, don't quit doing what you do! I think what cLive ;-) was getting at is we need all kinds of levels of answers. Remember, answers directed at the seeker of wisdom are read by many more potential lurkers, and while you may know the level of the seeker, you cannot know the levels of the unknown lurkers . . .

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--

[Abigail]

Almost. I think a better way of elevating people into the world of full Perl enjoyment is to show them WHY they need that new construct or function. Otherwise, it's just more noise to those that aren't ready to receive higher knowledge.

How would I know 1) they don't know the contruct(s) I might be using? 2) they aren't ready to receive higher knowledge?

I refuse to assume people are stupid. Nor do I believe spoon feeding leads to Nirvana. I will keep assuming people are interested enough in Perl that when they see something new, they will do some discovery themselves. I also believes that that is better for the people too - because by doing a little research yourself, you will find more new things, leading to ever more finds when exploring them. That will push the borders of their knowledge much further than spoonfeeding. It keeps Perl much more interesting, and it insults the intelligence of the other people less.

It's like going on vacation to an unknown city. It's no fun to go their using with a list saying where to turn left and right, which restaurants to visit, what to order, and how much to leave for a tip, than to just hear "that's an interesting city", and then go exploring yourself.

But then, perhaps I'm just an old gezer who hasn't been dumbed down by television.

-- Abigail, the television less.

[tomhukins]

I get the impressions that a reasonable proportion of newbie questions here have already been asked. In such cases, I think it's best to politely direct the poster towards Super Search and one or more threads where the same issue has already been discussed. There's no need to discuss the issue again - indeed doing so will mean users who fail to associate both threads with each other will miss out on potentially useful information.

Considering my own posts, I guess other monks must agree with me. Several of my highest ranked nodes are very basic I found this useful information using Super Search, such as Re: need both from system-call.

[sierrathedog04]

I think that when a newbie asks a question you should first berate him for not using 'strict'. Then you should tell him that he should have used Supersearch before posting his questions. Finally you should accuse him of trying to get us to do his homework assignment for him.

These practices will win friends for the Perl community and encourage others to join us.

[cLive ;-)]

LOL

cLive ;-)

[petesmiley]

Another idea might be to just write 2 versions of the code. Although I wouldn't bother if someone has already given a perfectly reasonable basic answer. And personally I kind of like seeing golf answers without explanation. Gives me something to do when I get bored ;-) And if I get stumped I can always ask.

One of the things I liked about Effective Perl Programming was the lack of indepth discussion on each line of code. Something I always skip over in books. I just read the code and then jump to the next paragraph. I always got the impression that if the book was thick, it was either a reference or it was too wordy.

Oh, and personally, RTFM is only rude if no link is given. Probably the most important part of learning something new is figuring out how the FM is layed out.

just me 2 pennies

[Anonymous Monk]

I agree completely. RTFM is good but when newbie is not sure of what they are looking for RTFM would just get them more frustrated. --Another novice/modest user. ;)

[Johnny Golden]

I am new to Perl myself and I must say that I like seeing the most efficient way to do things. I don't expect everything I see to be easily understood and granted a question turning into golf is a bit harder to understand. I have probably missed some of the basic things, but I have gained allot of understanding on how things are done in the real world. By not understanding something, it just makes me want to learn more. If I have to back track or reverse engineer the code, so be it. I think that for anyone who wants to see the different ways to do something, it certainly benefits. I do like the idea of a newbie node though. Maybe something attached to the tutorials?