On Fri, 3 Oct 2003 09:27:34 -0500
Ben Lutgens <blutgens at us-admins.com> wrote:

> 
> On Thursday, Oct 2, 2003, at 15:50 US/Central, Shawn wrote:
>  
> > Not to sound harsh, but to have everything laid out for you in exact
> > documentation makes for laziness, poor admins, and what you're 
> > complaining about that IBM GS is doing.  "Any monkey can do it, so 
> > they can do it from afar."  Documentation will never take the place
> > of knowledge, experience, and a desire to learn.  It is, however, a
> > great support aid tool for those things which I just listed.  This,
> > is of course, all IMO.
> >
> 
> This is bar none one of the stupidest things I've ever read on this 
> list. Without documentation, how are you supposed to learn about
> stuff? Guess? Divine the information from tea leaves?
> 
Reread my post.  In particular this part:

"Documentation will never take the place of knowledge, experience, and a desire to learn.  It is, however, a great support aid tool for those things which I just listed."

Reading that again, I probably should have used "should" instead of "will."

As I stated in a later post:

"Don't get me wrong, I'm not against decent documentation.  But, to have every single step laid out, of any and all possible causes/issues/problems/etc gets overly burdensome at times.  There are particular instances where things are taken for granted that the person knows specific steps or procedures to get to a point of what they are trying to accomplish.

There's a point where documentation is good and beneficial, and there's a point where it's cumbersome and detrimental.  Where that point is, depends upon each person.  So, in a sense they have to write it to a particular low level of understanding.

I'm still learning a lot, but IMO, to have every single step laid out and written for me takes away part of the enjoyment of getting things to work.  It can be boring cookie cutter work, and can lead to the thought of "Why do I need to learn this, it's documented for me.  If anything goes wrong, I'll just reference the book.  Or call XXX vendor for support on all issues.""


Again, I'm not against documentation.  I to have a great deal of bookmarks to websites, books, cheat sheets, notes and so forth as well.  What I am referring to in regards to being against documentation is the useless overdocumentation.  Do you refer to documentation when you want to do a basic listing of a directory?  How about when you want to do an interactive deletion of files within a directory?  Chances are greatly not.  You already know these basic steps, and that is the type of stuff which is generally omitted from documentations.  It's an assumption that the person doing this already knows basic skills on certain things.  If a person needs to refer to documentation on how to do what I would consider entry level stuff to do an advanced install, then they are greatly out of their league and should not be doing what they're attempting.

Yes, there is a point where documentation is good to learn from and is beneficial in most instances.  But, again what I am trying to say is that there is good useful documentation and there is bad overly burdensome documentation.

Think of it this way:  If you had to go in for open heart surgery, would you want a good experienced doctor who knows what he's doing and maybe has to refer to textbooks in rare instances.  Or, would you rather have Joe Blow who's never held an Exacto knife and needs to read every single step to do the operation?

Maybe that's a bad example, maybe not.  Hopefully makes sense.

-- 
Shawn

  The difficult we do today; the impossible take a little longer.

  Ne Obliviscaris --  "Forget Not"

_______________________________________________
TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
http://www.mn-linux.org tclug-list at mn-linux.org
https://mailman.real-time.com/mailman/listinfo/tclug-list