Common operational misconceptions

Sat Feb 18 07:56:25 UTC 2012

Give me someone who can already think and analyse over someone who 
'knows' it all, any day.  You can be qualified to the hilt but 
absolutely useless in the real world (I've watched CCNP and higher 
struggling to figure out why they can't ping a 10.0.0.0/24 address at a 
customers remote site, not even realising it's a private range, let 
alone trying to trace the path of the ping,)  If you're capable of 
symptoms->synthesis->solution you're of much more use to me.  You can 
pick up technical knowledge on the job, or around the job.  It's 
extremely hard to mold someone's thinking patterns by the time they're 
adults.  When we interview we try to spend more time trying to gauge 
problem solving capabilities than anything else, after first quickly 
establishing their technical level.

Paul

On 2/17/2012 8:43 AM, Kenneth M. Chipps Ph.D. wrote:
> Exactly right. They have some much information floating around in their
> heads many of them cannot fit it together. But once they get on the job, all
> of those little synapses rapidly connect, and then the light comes on.
>
> Higher education is just like drivers education. You did not learn to drive
> in drivers education. You learned how to drive by driving. Higher education
> gives you the foundation on which to learn.
>
> -----Original Message-----
> From: Paul Graydon [mailto:paul at paulgraydon.co.uk]
> Sent: Friday, February 17, 2012 12:33 PM
> To: nanog at nanog.org
> Subject: Re: Common operational misconceptions
>
> On 02/17/2012 04:29 AM, Leo Bicknell wrote:
>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
> Graydon wrote:
>>> At the same time, it's shocking how many network people I come across
>>> with no real grasp of even what OSI means by each layer, even if it's
>>> only in theory.  Just having a grasp of that makes all the world of
>>> difference when it comes to troubleshooting.  Start at layer 1 and
>>> work upwards (unless you're able to make appropriate intuitive
>>> leaps.) Is it physically connected? Are the link lights flashing? Can
>>> traffic route to it, etc. etc.
>> I wouldn't call it a "misconception", but I want to echo Paul's
>> comment.  I would venture over 90% of the engineers I work with have
>> no idea how to troubleshoot properly.  Thinking back to my own
>> education, I don't recall anyone in highschool or college attempting
>> to teach troubleshooting skills.  Most classes teach you how to build
>> things, not deal with them when they are broken.
> The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
> troubleshooting.  Not sure if they still do, or if trainers even bother to
> mention it (mine did back when I did it several years ago)
>
>> The basic skills are probably obvious to someone who might design
>> course material if they sat down and thought about how to teach
>> troubleshooting.  However, there is one area that may not be obvious.
>> There's also a group management problem.  Many times troubleshooting
>> is done with multiple folks on the phone (say, customer, ISP and
>> vendor).  Not only do you have to know how to troubleshoot, but how to
>> get everyone on the same page so every possible cause isn't tested 3
>> times.
> Never trust what you can't prove yourself, that includes vendors and
> customers.  Every now and then I forget this and find hours later that I've
> wasted a whole bunch of time because I trusted when someone said something
> that it actually was the case.  It's really often better to test something a
> third time even if Vendor and Customer tell you something is a particular
> way.
>
>> I think all college level courses should include a "break/fix"
>> exercise/module after learning how to build something, and much of
>> that should be done in a group enviornment.
>>
> Definitely.  I've learnt more in my time from breaking things than I've ever
> learnt setting them up; however the education system is focused on breadth
> of knowledge, not depth.  Students are expected to be able to regurgitate
> ridiculous amounts of facts and figures, so that they pass standardised
> tests, not understand how to actually use them.
>
> Paul
>
>
>
>
>