[mdlug] Future presentations.

[Adam Tauno Williams]

On Mon, 2012-01-16 at 11:46 -0500, Garry Stahl wrote:
> > Yes. Thank you for the presentation.  We'll have to think of more topics like this.
> I can think of one, but I'll be damned if I can think of an adequate 
> presenter.  Linux education.  As a newbie slowly crawling out of that 
> state I have noted that most help is not very helpful.  To paraphrase, 
> the average advice to newbies breaks down thus:

I whole-heartedly *disagree* with the premise of this message.  I'm not
a newbie, but I was a newbie, and I interact with a lot of newbies.  My
single most emphatic bit of advice of newbies is: SLOW DOWN!  Mostly I
watch newbies flail about in veritable panic and throw solutions at
problems in a terribly ineffective manner [like
reinstall-reinstall-reinstall, install-more-packages, etc...].  There is
nothing specific to LINUX or IT about this;  slow and methodical wins
the race [in any problem domain].  Stop and *think* about a problem,
start from the bottom and work up [is the cable plugged in, is the link
light on, do I have an IP address, do I have a gateway, can I ping the
gateway...]  Even after 20+ years of sys/net-admin I... start at the
bottom and methodically work up.  It works.  Lunging to a *theoretical*
source of a problem prior to gathering all the information is a recipe
for failure [again: in any problem domain].  Slow down.  Get a cup of
coffee.  Think.  And not only will you be able to solve more problems
you will also learn a great deal more from the process.

> Newbie:  "I have a dillywhop problem"
> Guru 1:  "Gain the knowledge level I have then do X and Y."
> Guru 2:  X might be helpful, but Y will simply muddy the problem, I 
> suggest you read the man page and try Z.
> Guru 3:  "X and Y worked for me."

This sounds like an IRC conversation. Newbies have no business asking
questions in IRC channels.  IRC channels are a *BAD* source of
information.

Go where the Gurus are - the mail lists - and don't say "I have a
dillywhop problem".  If you say that you *DESERVE* an off-the-cuff
stupid response.  Say "I have dillywhop problem and I am running version
XYZ of the relation application on a 64 bit whuzit-distro.  Previously
this did/did-not work when running version ABC.  I don't believe I have
changed anything relevant"

Note: it said "I don't believe I have.." not "I haven't" because clearly
you have.  Let that sink in.

GIVE INFORMATION!  Clearly you are asking because YOU DO **NOT** KNOW
why it is not working, so don't give *LESS* information.  If I have to
beat the poster for more information I'm going to just move on.  It is
*YOUR* problem and you want *MY* time so.. POST THE #$*&&*(!@Y$ RELEVANT
INFORMATION.

<http://catb.org/~esr/faqs/smart-questions.html>

Who takes there car into an auto-shop, drops of the keys and leaves a
note saying "sometimes it doesn't start".    You say "Here is my '68
t-top camero and on really damp morning sometimes the engine cranks but
it doesn't start"

>   Yes, our little group is as guilty as any other in this respect.  The 
> steepest part of the Linux learning curve is often the people that try 
> and help you.

Bogus.  The steepest learning curve is typically learning to
systematically approach problems.  Again, irrespective of the problem
domain.

Here is my #1 tip:
At the end of every message just always include:
   Distribution version and platform (x86, x86_64, Atom, etc...)
   Output of "uname -a"
   The *exact* version of the related package from your package manager.
Just do it - every time. period.  no exceptions.  If you really can't
take the time to do that.... why should I take the time to ask you for
that information?  Not sure what package(s) is related to the problem...
take a guess, include a few.  That at least some effort [which equals
respect].

> Things to Not Do:
> 1)  Read the Man page:  These documents are written by everyone from 
> Charles Dickens, to Charles Manson.  Many assume a certain level of 
> technological knowledge and are singularly unhelpful to-the beginner. 
>   Most resemble crib notes for those than know what they are doing and 
> are meaningless jargon to those that don't.  Like 90% of computer 
> documentation, useless.

Bogus.  Many man pages are very good.

> 2)  Type anything into the CLI:  

I'm sympathetic to this; but you really limit who can help you hear
since the GUI admin tools are the one of most distribution specific
components.  And with the exception of YaST they generally SUCK and are
quite limited

> 4)  Forget that not everyone is a coder:  The question used to be is 
> Linux ready for Grandma? 

Yes, it is.  Linux works great for Grandma.  She will rarely flail about
and break things.

>  As long as knowledge of the CLI is required, 
> no.  This doesn't mean that Grandma is stupid.  Many people are 
> excellent drivers, they use their cars successfully every day to 
> accomplish the tasks they need to do.  Some are even professional 
> drivers that make a living with their cars.  That doesn't mean they can 
> fix the engine or repair the suspension. 

This analogy is fallacious.  Grandma can't fix or even install any OS.
She can use them quite effectively.

> car or design and print all your own books?  Respect the fact that not 
> everyone can be a computer wizard, but the computer is a necessary tool 
> in today.s world.

And the end-user asking for free advice can treat the 'guru' with the
same respect they'd use when approaching an auto-mechanic or doctor at a
social gathering when they intend to pump them for free advice.

> 2)  Remember that this person wishes to learn.  

No, I don't believe it always clear that this is true.

> Do not place roadblocks in 
> the path of those that seek knowledge, help them as you yourself would 
> like to be helped.

I do exactly that.

> 5)  Encourage questions.  THERE ARE NO STUPID QUESTIONS!!

Incorrect. There are stupid questions; or maybe not stupid but
"disrespectful" and "uninteresting" questions.  Like questions whose
answer can be found in bold print on the home page of a project.
Demonstrate effort with statements like "I saw the FAQ at <link> but
nothing there seemed relevant". 

>   No matter how 
> obvious you might think the answer is, they would not be asking if they 
> understood.  Different people have different competencies and differing 
> ways of learning.

Off topic, but I disagree.  There is one and only one way to learn:
Research, try, fail, research, try, fail, research, try, fail....
succeed! Everything else is blather [educators attempting to rationalize
their own failure].  There may be real differences in research methods,
but pragmatically those difference are irrelevant when *seeking* help.
When seeking the *seeker* does the heavy lifting; that is what "seeking"
means.  Lounging in a comfy chair and postulating is not seeking; that's
just lazy.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mdlug.org/pipermail/mdlug/attachments/20120117/4c597412/attachment-0001.sig>