Craig> Before asking a technical question by email,
  Craig> or in a newsgroup, or on a website chat board,
  Craig> do the following:

  Craig>      1. Try to find an answer by searching the Web.
  Craig>      2. Try to find an answer by reading the manual.
  Craig>      3. Try to find an answer by reading a FAQ.
  Craig>      4. Try to find an answer by inspection or experimentation.
  Craig>      5. Try to find an answer by asking a skilled friend.
  Craig>      6. If you are a programmer, try to find
  Craig>         an answer by reading the
  Craig>         source code.
        
All excellent advice, to which I will add:

              7. Try to find an answer before your boss
                 fires you or the company folds and you
                 lose your job.

It's a fine thing to 'learn to fish' rather than 'being
given a fish', but sometimes there are situations in
which information being sought is desired for more than
academic reasons, and a job simply needs to get done.

If my leg is cut off, I need a tourniquet, not a copy
of Gray's Anatomy and a lecture on the circulatory
system.

  Craig> I am more than happy to help those who are
  Craig> trying.

Will you grant free passage for people who have been
around Linux for 20 years, assuming that they are well
aware of how to do research, but sometimes just need to
get an answer?

About a year ago I taught Unix/Linux for two semesters
at UAT. (Not a fun experience, BTW.) I devised a slide
show for *lesson one*, entitled "Ask the Man". In it I
made the the point that Unix is vast, that they would
never run out of questions about it, and that often
they would need to go searching for knowledge. So I
devised the mantra: "Ask the Man". Which man? I put up
pictures of RMS and someone else and myself. Then I
demonstrated the man(1) manual page command and told
them that if they learned nothing else in the course,
learn how and where to find information.

Regrettably, many of them didn't even learn that much.

I concluded with a wonderful quote from a friend of
mine:

    The most valuable employee is not the one who knows
    everything, but the one who can find out anything.

On the other hand, nothing steams me more, when I post
an intelligent question to a list, than to see a
high-handed response from some jerk that looks like
this:

    lynn> ... how can I do blah blah ... ?

    jerk> google blah blah ...

Thanks a lot. Very helpful.

A good example is when my outbound email went out last
week and I asked the group how to fix it. In that case
I did *not* get the sort of response noted above. I got
some intelligent, informed, if not altogether
articulate information on how to get it fixed. 

What I needed at the time was not a lecture or class in
SMTP or sendmail or m4, but instructions on which file
to edit, what to put in it, and how to get moving
again, because I had a queue of business email that was
backed up and needed to get out the door immediately.

Although I got some good advice from the list,
ultimately it was a colleague who knew what to do and
got me going again.

Meanwhile, a very interesting and useful thread got
started on this list, which resulted in a valuable
reference document being created that any of us can
refer to the next time something like that happens.

-- 
Lynn David Newton
Phoenix, AZ