When someone asks a question, should you answer the question that they asked or the question that you think they should be asking? This applies because often someone asking a question really needs to know how to answer it for themselves rather than the answer to that specific question. But very often people show up saying, "I need to do this, how do I do this" when it is obvious that the fact that they want to do that indicates they should be learning about something else.

So should you answer the question asked (say how to do a soft reference) or explain why you think they should be thinking about something else? I tend to do the latter but don't really know how to draw the line. Thoughts?

I always try to look at the context of the question as well. I try to figure out not only what they are trying to do, but why they are doing it as well as how they are doing it. Yes, there is often a strong risk of coming across as pushy, but most people appreciate the "ancillary" help as well as the direct answer to their question. Often times this involves showing another way to do something. The best threads on this site (in my opinion) is where someone asks (or indirectly asks) "How can I do X?" Then many people all contribute different ways of doing it, some perhaps "better", some "faster", but mostly just different. Sometimes the discussion goes far afield from the original question - which is a very good thing, and one of the strengths of the monastery.

I've been involved in a similar vein of discussion on a completely unrelated forum. I'm more of the inclination to answer the question as asked. But, the matter of interpretation is left to the reader. In other words, if the question is as specific as to state full requirements, then an answer is best given within those conditions. But if no requirements are given, then a good answer will involve the best interpretation.

This kind of relates to something I learned in my Automata Theory course at school. If the answer isn't readily available, then redefine the question. Since programs should be able to be reduced to mathematical representations, this is perfectly legal as long as the end result was arrived at using valid operations.

ALL HAIL BRAK!!!

I would say absolutely! Getting answers in five seconds isn't a good way of learning. And, if you repeatedly do it, you won't learn anything but how someone else says to do it. It is amazing what you can learn when trying to find a 'simple' answer in the docs. You may be looking up something simple about how to make a coderef, and suddenly get sidetracked into sockets or OO. The path to find an answer contains other answers of unasked questions.

I just remember being really green, and not even knowing how to get at the docs to review them.

That may be the real problem. I don't think every person asking a simple question is simply lazy. I think one problem is that they do not know about perldoc, or the wealth of information they can find on the web (tutorials, books, articles, etc...) by default. I think it is our job to point (or prod) people into looking at the docs, even tell them the exact place the answer is, just don't tell them the answer. (this goes for novice-like questions)

Or is it more like a Monk saying, “here’s a fish, and there is a stash of fishing rods over behind those rocks for next time…

Well, being a vegetarian I like this better: Give a person a carrot they eat for a day, show them how to grow a garden, they eat for a lifetime.

Cheers,
KM

I guess what I'm asking is: Are there questions that are too basic? Should a newbie be required to pour over the docs for answers that we can provide in 5 seconds?

I would say absolutely! Getting answers in five seconds isn't a good way of learning. And, if you repeatedly do it, you won't learn anything but how someone else says to do it.

Actually, my experience is fundamentally different.

One of my most enjoyable learning experiences is learning a) a new language, and b) the programming practices and use of an existing code base by sitting among three other programmers and being able to just throw out quick questions, getting answers within seconds.

I realize that maybe Perlmonks isn't the same thing, but I can say that I would like to have that kind of quick and responsive environment on the Net as well.

I'm not saying that you shouldn't read the manual, because you really should! I'm saying that sometimes you learn better by getting a quick solution to your immediate problem than you do by getting a reference to The Whole Picture(tm) in the form of a dense man page when you're not ready for it.

Knowledge doesn't expand 100% to new areas all at once. It slowly grows and deepens by internalizing what you read and do. When you have the personal experience of doing something you are so much more prepared to understand the theoretical base of that "something".

/J

There are degrees. At my stage in Perl knowlege, I will get a lot more from a quick answer because I can understand various thing surrounding the issue I need an immediate solution/answer for. I don't think I have come across too many newbies (or any) who can get a quick answer and actually learn from it, without asking 10 other questions. This is why learning to read the docs (et al) are useful for this skill level because they can find the answers to their questions, and side-knowlege along the way. It will also help them learn to learn for those times when they do not have three other programmers around them to ask questions to. I'm saying that sometimes you learn better by getting a quick solution to your immediate problem than you do by getting a reference to The Whole Picture(tm) in the form of a dense man page when you're not ready for it.

Which do you think would help someone learn better if they ask the simple "how to I remove whitespace from a string?". By you showing them the regex so they can cut/paste it? Or by being refered to perlre and the FAQ (of which that is a question in)? I believe the later is a more effective way. It will take longer to grasp a concept by trying to learn by sound bits and specific snippets (like the regex only). The knowlege one would take from reading perlre to find their answer would in turn answer future questions.

I am not sure what dense man page you are talking about. Most of the Perl documentation is quite verbose and well explained (with some exceptions). And, when do you propose someone is ready to learn from the documentation of the product they are using? After a year? After asking every FAQ question to cow-orkers and people on the internet?

Personally, I learned Perl from reading the documentation and learning how other peoples scripts worked (and didn't work). No classes, no mono-a-mano.

Knowledge doesn't expand 100% to new areas all at once. It slowly grows and deepens by internalizing what you read and do. When you have the personal experience of doing something you are so much more prepared to understand the theoretical base of that "something".

Yes, so someone needs to read and do to learn.. not ask for 'the answer'. This whole discussion came about from wondering about simple questions from newbies, not about needing quick solutions to complex problems. If people are spoon fed answers from early on, they may not learn the tools needed to fend for themselves.

Cheers,
KM

Are there questions that are too basic? Should a newbie be required to pour over the docs for answers that we can provide in 5 seconds?

Required is hard, but gently threatened would be good I think. Evidently I've got too much self-imposed restraint, but I'd rather look something up and figure it out myself at least until I'm really stumped, rather than ask a bunch of experts before I've even composed the question in my mind, no matter how friendly they may be.

I just remember being really green, and not even knowing how to get at the docs to review them

I've been green for many years now, but I know where the docs are, and I've got the books. Perhaps when an unknown monk tries to post, the page starts with a carefully selected and annotated group of links (the docs, tutorials etc.), also the SuperSearch, and they'd have to scroll through this to get to the edit box. The main benefit to the unknown monk would be an instant answer, not to mention significantly reduced hazing.

The root of the problem is probably the same thing that stopped me from reading c.l.p several years ago: everyone that has manage to cobble together a home page then wants to get into CGI, and they leap into Perl eyes closed and holding their nose, thinking it's just fancy HTML. The kicker is the old "please e-mail the answer as I don't monitor this group". Is being "unknown" a similar thing? Should you at least be required to register and amass some XP by reading before being permitted to post? (what's the fun in -- unknown? ;-)

I don't know the answer but maybe there is some entropy-related rule that any repoistory of concentrated knowledge is doomed to be diluted by poorly-typed homework requests.

The problem with some questions is that they just show that the posters want to do things that are a tad too complex for for them right now. Which they might not even realize.

It is often obvious that the poster will not fully understand the answer unless they look at the doc. Hence the you should really grab a book chant and the answer.

Just giving the answer would probably result in some kind of cargo-cult programming. I think that exhorting the poster to read some more about the answer is the quickest path to enlightment.

Amen

Think about all the power of Perl, but not knowing it. Driving a car that you only knew had first gear. My original world of Perl was defined so narrow that for most tasks, I only knew of one way to do things, a bad place to be for Perl.

Even after I started learning more, I wasn't fluent with what modules were on CPAN, and what wheels have already been invented. I'm still not near the point I want to be.

All this is leading to the point of simple questions may open up worlds to people new to Perl. A simple indication to read the docs may not reveal other ways to do things to those struggling, where a code snippet or a reference may.

But you still need to understand, so a enjoiner to look at the docs is still in order. But even better would be a pointer to the appropriate docs - be it in perldocs, a name of a favorite book (or publisher) that covers it, etc. It really encourages people.

=Blue ...you might be eaten by a grue...

One of the strengths of Perl as it relates to learning the language is that it's possible to get a frightening amount of work done with a very small subset of the language.

A bigger strength is that there's usually a much more concise and efficient way to do it. Showing less experienced programmers these techniques is a very good thing.

The trouble is, how do you teach them to recognize when one solution is better than the other? How do you help a new programmer discern between different approaches?

Take a look through the Perl FAQ sometime with a beginner's eye and see if you can figure out *why* underexperienced coders are drawn to symbolic references and other easy-to-do-but-hard-to-do-appropriately things.

One of the few shortcomings of the assembled documentation is that it sometimes doesn't explain *why*. That's something I had to learn through experience (making mistakes in Perl and programming a half dozen other languages).

No matter what kind of answer you give, you're depriving the supplicant of some of the benefit if you don't go into why things are done the way they are. Experience is a good teacher, but it's not a gentle one. Reading the documentation is very good, but it's no substitute for already knowing how to program in general.

(spurred on by this line of thought, I'm thinking of writing something like 'Common Mistakes of Beginning Programmers' along the lines of Common Regex Gotchas or whatever I called it way back when. anyone interested?)

Yes! Very!

(I'm trying to learn on my own, but I'm being asked to produce production scripts without formal training or time to research. Even the most trivial script is taking days (or longer) to finish...sadly, I am only now beginning to feel like I understand the basics.

Going back to the original question, I'm in the camp that says "No, no question is too basic." A bit of background may help; I frequent a community support newsgroup and have been involved with that community for ~10 years, so I'm very grounded in the package.

Many times, I have responded to overly basic questions with stock answers and then learned something new from the follow-up.

Just because you know a few, some, or many intracacies of a product, language, or process doesn't mean that you can't learn more about it.

I feel that there are some simple questions asked, Bod knows I've asked enough of them. How can you define a level at which you are spoon feeding someone, surely it will be in the Monastery as it is in Development: The serial quizzer will be noted and dealt with by each individual.

We've all been the novice and needed help, and sometimes we need to spread the word of the good books, a new Monk mightn't know of the books or realise their importance as reference.

Brother Frankus.

But I'd like to posit that even though I have excellent resource material in front of me (close to the whole O'Reilly Perl series), there are still situations where it would be more appropriate for me to ask a question here. In many of these cases, it's more of a situation where I will take the time to ponder the solutions after the fact of implemenation and try to dissect them into their operative mannerism. I'm willing to argue that a green question is good, as long as the end result is productive learning.

The obvious problem is that there is no way to gauge if a solution will facilitate productive learning, since the user is not obligated to follow up. So, this is a matter of faith. I have to trust that if I provide a solution to a green question, I am helping the asker to learn something.

And one final note on this topic: I know that Perl, Linux, and this general area of computing is supposed to be a community. It is important for newbies to understand that by joining this community, you are hereby obligated to read a lot of documentation, to expect that the quick and easy path will lead to Visual Basic style development, and a mixture of help and chastisement. It is important for seasoned vets to aid and to scorn. But I'm going to argue that the two must work hand in hand to create a better community. As an experienced developer with certain areas, I don't want to just give out easy answers all the time. But it's also kind of a civic duty to do more than shout RTFM at the drop of a hat.

It's been my experience in the past that a good majority of us probably know how to make snide comments that appear within helpful answers. It's one of the facets of many of the geek communities I've been in, and I'd argue that it is an important facet that controls the hierarchy of the group. It creates a healthy competition to become better.

ALL HAIL BRAK!!!

Add "I'm too stupid to format my post correctly" to the list

:)

Update: Kudos to tilly for reminding me this isn't Slashdot...

The most fundamental information (in any subject, not just Perl) is often skipped in the documentation under the assumption that "everyone knows that." (Try to find a definition of a "four banger" in a engine strip-down manual. I dare you.) Well, I for one can say everyone doesn't. I learned Perl with Programming Perl in one hand and the Perl docs in the other and there were many, many frustrating times when one or the other (or both!) would say something akin to "This is just like x function in Unix" or give code examples on how to do something with no explanation. There was an assumption of a basic level of knowledge that didn't exist in my case. I would have given my eye-teeth for a good explanation of grep, or a good definition of what the heck a character class was. Too basic? RTFM? Not in my case...

Maybe it's because I'm not burned out after years of c.l.p dealing with newbies, but my first inclination is to say that all who come here seeking knowledge are worthy, and should be treated, at minimum, gently. The question might look stupid to you, but surely going to the trouble to seek out the Monestary and type in a coherent question should count for something. When you see an easy question, please answer it as a teacher would, addressing the scope, level, and desire of the student.

And if you can't do that, at least be quiet while those of us with more patience take care of it for you.

Gary Blackburn
Trained Killer

More importantly, there are answers too available, we should at least try and steer them there. My rules are a little more complex on whether or not to ANSWER the question.

1. Are they Anon? That's a big strike, if they haven't bothered to login and thus aren't planning on staying here to help out, why would I spend much time on em? OTOH, some of the best questions are Anon so I read em all =)

2. Homework. I will no longer respond to em, you're doing them a disservice by "helping" them.

3. Spastics. There are some people who seem to just post all kinds of weird, semi-off-topic posts and start flame-wars just for the gratification of seeing their name on the web. I left c.l.p.m years ago over that and FAQ posting. When the channel is 90% karma-whore/spastic and FAQ questions, it's time to leave.

4. Trying to learn. That phrase is usually a bad sign, as it is generally an amulet held up against expected shouts of "that is a module!" and "why do that with THAT?" I do approve of learning through doing tho so I usually bite on these but I don't often spend the extra time I do on other posts, I just answer the question and let em stew in their own juices.

5. Performance. This word is a giant red blink tag of evil. I'm either going to bail out immediately if it is tied to phrases like (question the, of module, OOP) or spend hours there tinkering with useless speed enhancements.

Ahh this will turn rantish if I continue, keep the good questions coming =)

--
$you = new YOU;
honk() if $you->love(perl)