RE: Looking for a Tier 1 ISP Mentor for career advice.

[Robert Bonomi <bonomi () mail r-bonomi com>]

Nathan Eisenberg wrote:
> To: Jeroen van Aart <jeroen () mompl net>, NANOG list <nanog () nanog org>
> Subject: RE: Looking for a Tier 1 ISP Mentor for career advice.
> Date: Wed, 4 Jan 2012 22:25:40 +0000
>
> > Say a
> > coder gets confused when /tmp fills up and being unaware of this thing
> > called a "search engine" and instead will virtually cry "help my puter
> > b0rked, I stuck!" and vice versa.
>
> Hah!  In my experience, this phenomenon is not unique to coders, 
> sysadmins, or any other specialization.  People prefer to look to other 
> people for their answers.  This one has bugged me for a long time, as 
> I'm not sure what to attribute it to - is it a desire to be social, or 
> to have the answer personalized?  Is it a compliment indicative of 
> respect of ones peer, or is it an indication of laziness?

This phenomona has been recognized for, well, "forever".  The 'reasons'
are codified in 'traditional wisdom' like "two heads are better than one",
or the modern "The solution to the most intractable problem is immediately
obvious to the first unqualified observer." 

When ones own way of lookinng at a problem isn't working, it  is necessary
to find a "different way of looking at the problem".  The most efficient
way to do that is talk to some who thinks differently than you do.

"Search engines" are good for finding facts; 'less good' for finding
abstract/concept info -- It's much harder to formulate a search
query to find something to 'fill in the blanks' in an _incomplete_
conceptualization.  If yu can foumulate the search for "what you're
missing" the search probably contains the answers you're looking for.

Also, the act of 'organizing ones thoughts' to explain the problem to 
someone who is *NOT* familiar with the background of the problem can
lead to _self-recognition_ of the solution.  I have phoned a collegue,
many times, and/or had a collegue phone me, where the _one-sided_ 
conversation has gone; 
 <-- "Hello?"
 --> "Hi! I've got a problem.  like _this_ {launches into description}...
      OH!!  never mind, the light just dawned!"
 <-- "<chuckle> Glad I could help."


"Troubleshooting", however,  _is_ a special case situation.  I can 
pontificate on this at some length.  You have been warned.  <grin>

Troubleshooting problems is an 'art', not a 'science'.
Either you know how to do it, or you don't.  And, like any other "art",
you can't teach it; you _can_ teach 'mechanics' that help people who
have an 'instinctive' (for lack of a better word) grasp of the subject
"do it better".  But the _ability_ has to be there in the first place.

It's similaar to integral calculus -- you have a result, and are looking 
for the question. (Remember how _hard_ integration was -- until the 'AHA!'
moment when, all of a sudden,  it all made sense. And you were shaking 
your head wondering *why* you had so much trouble 'getting it'.)

Troubleshooting is much the same.  If you've seen "that" problem before,
you have an idea of what -may- be causing it.  And can start checking
for the existing of each possible 'what' that you know about.  With
experience, you know _which_ "what" is most likely and to start there.
Also, what _additional_ things to check, to narrow down the list of
'possibles'.

'Search engines' are good when you have a 'question' and are looking for
looking for an 'answer'  (like 'differential calculus', to use the math 
metaphor). But they're "medium lousy", at best, at finding the 'question'
that fits the 'answer'.

There are some major attempts being made to build computers that _can_
reverse engineer the 'question' from an 'answer'.  See 'Watson' -- the
IBM research computer project that plays as a contestant on "Jeopardy!"  
The latest incarnation 'does good' a lot of the time, but when it's wrong
it is *very* wrong.  I don't think I've ever seen it be 'close, but
incorrect'.