[150076] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Common operational misconceptions

daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Feb 17 14:02:03 2012

From: Owen DeLong <owen@delong.com>
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
Date: Fri, 17 Feb 2012 10:59:10 -0800
To: Mario Eirea <meirea@charterschoolit.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


This reminds me of what I think is the biggest root misconception of the =
20th and 21st centuries:

Rapid step-by-step training can replace conceptual education on the =
fundamentals.

In other words, we have moved from the old-school of teaching people why =
things work and how they work to a newer school of teaching people how =
to complete specific tasks. This has had the following negative effects, =
IMHO:

1.	When the only tool you have is a hammer, you try to mold every =
problem into a nail.
2.	When you only know a procedure for doing something and don't =
understand the fundamentals
	of why X is supposed to occur at step Y, then when you get =
result A instead of X, your only options
	are to either continue to step Z and hope everything turns out =
OK, or, go back to an earlier step
	and hope everything works this time.
3.	Troubleshooting skills are limited to knowing the number of the =
vendor's help desk.

I once worked with a director of QA that epitomized this. It was a small =
company, so, as director, he was directly responsible for most of the =
tasks in the QA lab. He was meticulous in following directions which was =
a good thing. However, when he reached a step where he did not get the =
expected result, he was limited to telling the engineers that the test =
failed at step X and would not make any effort to identify or resolve =
the problem and would literally block the entire QA process waiting for =
engineering to resolve the issue before he would continue testing. =
Worse, he would not test independent pieces of the system in parallel, =
so, when he blocked on one system failing, he wouldn't test the others, =
either. Further investigation revealed that this was because he didn't =
actually know which systems were or were not dependent on each other. He =
was so completely immersed in the procedural school of thought that he =
was literally unwilling to accept conceptual knowledge or develop an =
understanding of the theory and principles of operation of any of the =
systems.

Owen

On Feb 17, 2012, at 8:13 AM, Mario Eirea wrote:

> I definitely understand and agree with what you saying. Actually, most =
my friends are over 50 years old... I do agree with you on the =
generational statement. My argument was that many people over 35 have no =
idea what they are doing, and some under 35 do know what they are doing. =
On thing is for sure, experience goes a long way. The importance is =
knowing the fundamentals and putting it all together (a skill that has =
been lost in recent times)
>=20
> I have a lot to say about the current generation of people growing up =
in this country, but that's a whole other thread in a whole other list. =
:-)
>=20
> Mario Eirea
>=20



home help back first fref pref prev next nref lref last post