[mdlug] Fwd: Re: Fwd: Re: Future presentations.

[Garry Stahl]

-------- Original Message --------
Subject: 	Re: Fwd: Re: [mdlug] Future presentations.
Date: 	Tue, 17 Jan 2012 14:08:33 -0500
From: 	Sue Stahl <stahl_s at wowway.com>
To: 	Garry Stahl <tesral at wowway.com>



On 1/17/2012 1:13 PM, Garry Stahl wrote:
>  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].

This is good advice, but the reason many newbies flail like this is
advice that they get from many Windows techs.  I've run into them....
Me:  I have X problem.  Tech:  Oh, just reinstall Windows and then
install the latest service pack.  Now I know a bit more than to do that,
but most newbies don't.  They blithely follow the instructions.

Therefore, when the newbie encounters problems with Linux, they do what
they've been taught to do with Windows and flail at it.

>  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.

This is fine and dandy if you already KNOW the process.  Most newbies
have no idea where to locate the bottom to start at.  They can think all
they want about the problem, but they have no clue where to start or
where to go from there.  They need someone to hand them the road map and
teach them how to read it.

>  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"

Ok, I'm going to use a real problem I encountered here.  The newbie
tells you, "I have a problem printing.  When I print the normal way,
everything is fine.  When I try to print the other way, the computer
freezes."

The newbie is describing the problem as they see it.  They don't know
what information you need and may not know how to find it.  That is up
to YOU, as the guru, to draw out.  Give them an off-hand, stupid (or
sarcastic) answer, and the newbie is going to leave and never come
back.  It is not that they are stupid... it is that they do not know.
YOU know... but that is because you are standing on the shoulders of
others who taught you these things.  Treat the newbie with a bit of
patience and respect, and offer to help them stand on your shoulders.

So, using my example, if I am the teacher...
Me:  Do you mean when you print on the paper like a book, you have no
problem... but when you print with the paper turned on its side, the
computer freezes?
Newbie:  Yes
Me:  Ok, the book orientation is called portrait, and the paper turned
on its side orientation is called landscape.  Does it do this every time
you print or only in one program?
Newbie:  Only when I do it in (name of program).
Me:  What version of the program are you running?
Newbie:  I don't know.
Me:  Ok, right click on the icon on the desktop and go to Properties.
It should list the version.
Newbie: [doing as instructed] It says it's version XYZ.
Etc.... etc... etc...

As the teacher it is up to ME to help them discover the information I,
and they, need to diagnose the problem.  I guarantee that the next time
there is a problem, the newbie will have most of the necessary info
because they now know what is needed and how to find it.  They aren't
standing on my shoulders yet, but they've taken the first step up.

>  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.

Again, this is great IF YOU ALREADY KNOW THE INFORMATION THAT IS
NEEDED!  You can't expect a newbie to suddenly have this knowledge or
somehow divine it out of the aether.  If you invest a bit of time and
patience with the newbie now, it will pay off later.  They will be
better informed and can describe the problem more accurately and in
greater detail.

>  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"

Many people do.  My mother would go to the family mechanic and tell him
"It's making a funny noise."  The mechanic never failed to treat her
with patience and worked with her to get the information he needed.
That is why this mechanic is still in business years later and is
well-respected by both his clients and his colleagues.
>
>  Bogus.  The steepest learning curve is typically learning to
>  systematically approach problems.  Again, irrespective of the problem
>  domain.

The steepest learning curve is learning HOW to systematically approach
problems.  If you don't teach that, you won't be able to teach anything
else.

>
>  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].

So how do I find all this out?  I know a bit of Linux, but you lost me
on this one.  Ok, I understand the distro version part, but what is my
platform and how do I find it?  What the heck is "Output of 'uname-a'?"
What is the related package from my package manager?

Why should you take the time to ask me for that information?  BECAUSE I
AM A NEWBIE...  I DON'T KNOW IT, AND I DON'T KNOW HOW TO FIND IT!  Treat
me like an idiot for not knowing and I will forget trying to learn Linux
and go back to Windows.  Instruct me how to do this with a bit of
patience, and I will not only want to continue to learn Linux, I will be
able to provide you the information the next time I have an issue.



-- 
Garry  AKA  --Phoenix--  Rising above the Flames.

Politically I have given up on being an anything-arian. I am for accountability and nothing else. Hold the government, in specific the office holders, elected or appointed, accountable for all actions taken in office. Authority must be granted grudgingly and reluctantly. When it is abused it must be snatched away at once. Be it a minimum wage screener at the TSA or the President of the United States.
Star Trek mort. Viva la Star Trek admiraetur
The Olde Phoenix Inn http://phoenixinn.iwarp.com
Metro Detroit Linux Users Group http://www.mdlug.org