[150416] in North American Network Operators' Group
RE: common time-management mistake: rack & stack
daemon@ATHENA.MIT.EDU (Holmes,David A)
Thu Feb 23 14:55:54 2012
From: "Holmes,David A" <dholmes@mwdh2o.com>
To: Lamar Owen <lowen@pari.edu>, "nanog@nanog.org" <nanog@nanog.org>
Date: Thu, 23 Feb 2012 11:54:47 -0800
In-Reply-To: <201202231359.18977.lowen@pari.edu>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
The problem with using engineering as a model is that computer science netw=
orking theory is based upon mathematical logic and formal mathematics (for =
instance Finite State Machines, Turing Machines), and operates on what are =
essentially robotic automatons running in real time. Engineering as I have =
experienced it, operates according to construction time frames using CSI sp=
ecifications, preliminary design reviews, and various iterations of final d=
esign reviews involving engineering drawings and CSI-format specification d=
ocuments where a 6 year start-to-finish time frame is not unusual. The numb=
er of PEs who can operate in real time is but a fraction of all PEs, and th=
ose who can plan a project with a 1 week time frame, and implement the proj=
ect at 3 am in the morning is a yet smaller fraction. ( and don't even thin=
k about the number of PEs who can get a 3 am call and must fix a broken net=
work ASAP).
Not everyone has the ability to grasp mathematical logic, even though they =
have been able to get an engineering degree.
Engineers have no peers in the ability to build bridges, skyscrapers, and o=
ther large construction projects, but this ability does not transfer to com=
puter science, and computer networking.
-----Original Message-----
From: Lamar Owen [mailto:lowen@pari.edu]
Sent: Thursday, February 23, 2012 10:59 AM
To: nanog@nanog.org
Subject: Re: common time-management mistake: rack & stack
On Wednesday, February 22, 2012 03:37:57 PM Dan Golding wrote:
> I disagree. The best model is - gasp - engineering, a profession which
> many in "networking" claim to be a part of, but few actually are. In the
> engineering world (not CS, not development - think ME and EE), there is
> a strongly defined relationship between junior and senior engineers, and
> real mentorship.
My degree is in EE, and I spent over a decade in the field as a 'broadcast =
engineer' Now, a 'broadcast engineer' is not a PE, and is not currently lic=
ensed as such, although many of the best consulting broadcast engineers do =
take the extra step and expense to get the PE license; technically, in many=
states, you're not even supposed to use the word 'engineer' in your title =
without having a PE license.
By way of background, my specialty was phased array directional AM broadcas=
t systems in the 5-50KW range, doing 'technician' things like phasor rockin=
g, transmitter retubing and retuning, monitor point and radial measurements=
, transmitter installation, and tower climbing, in addition to more mathema=
tical and engineering sorts of things like initial coverage and protection =
studies for pattern/power changes, measured radial ground conductivity/diel=
ectric constant curve fitting/prediction contour overlap studies and models=
, as well as keeping up with FCC regulations and such.
I left broadcasting full-time in 2003 for an IT position, as a stress-reduc=
er (and it worked.). So I say this with some experience.
Mentoring in broadcast is still practiced by associations like the Society =
of Broadcast Engineers and others. These days, much of this sort of thing =
is online with websites like www.thebdr.net and mailing lists like those ho=
sted by broadcast.net; in this regard the network ops community isn't too d=
issimilar from the broadcast community.
Now, while in the broadcast role I had the distinct honor of having three f=
antastic personal mentors, two of whom still stay in touch, and one who die=
d twenty years ago, a few years after I got started in the field. RIP W4QA=
. He taught me more in half an hour about phased arrays and the way they w=
orked in practice than ten hours of class time could have. Likewise, I kno=
w some old hands here, even if I've not physically met them, whose opinions=
I trust, even if I don't agree with them.
> The problem with "networking" is that TOO MANY skills
> are learned on the job (poorly), rather than folks coming in with solid
> fundamentals.
This is not limited to networking.
The parallels between broadcast engineering and IT/networking are a little =
too close for comfort, since there are more potential mentors with weak tea=
ching skills and bad misconceptions that were valid 'back in the day' than =
there are who will teach practical, working, correct ways of doing things '=
today' and why they are done the way they are done (which can involve some =
history, one of my favorite things).
A mentor who will teach how to think about why you are doing what you are d=
oing is priceless. A mentor who will honestly go over the pros and cons of=
his or her favorite technique and admit that is isn't the single 'correct'=
way to do something, and a mentor who will teach you how to think sideways=
, especially when things are broken, are beyond priceless. I especially li=
ke it when a mentor has told me 'now, this isn't necessarily the way I'd do=
it, and I'm not really fond of it, but you *can* do this to get this resul=
t if you need to do so...just don't ask me to fix it later.'
And the recent thread on common misconceptions has been priceless, in my bo=
ok. Especially due to some of the respectful disagreements.
> I blame our higher education system for being ineffectual
> in this regard. Most of the "book learning" that you refer to is not
> true theory - it's a mix of vendor prescriptions and
> overgeneralizations. In "networking", you don't learn real theory until
> you're very senior - you learn practice, first.
Vendor-specific certifications don't help much, either, really, in the 'why=
' department.
> They also lack real licensing, which
> is a separate problem.
Now you've stirred the pot! In the broadcast field, SBE offers some good t=
hings in the line of vendor-neutral certification; in the networking field =
there are some vendor-neutral avenues, such as BiCSI for general stuff and =
SANS for security stuff.
Having said that, and going back to the broadcast example, not too long ago=
you had to have an FCC 'First Phone' to even be qualified to read a transm=
itter's meters, and every broadcast licensee (holding the station's operati=
ng license, that is) had to employ 'operators' holding an active First Phon=
e to keep an eye on the transmitter during all operating hours, with the Fi=
rst Phone of every operator posted at the site, and even the DJ's had to ha=
ve a Third Class Permit to run the audio board, and periodic FCC inspection=
s were frequent. So that's the extreme situation in terms of licensing, ju=
st for reference....
This communication, together with any attachments or embedded links, is for=
the sole use of the intended recipient(s) and may contain information that=
is confidential or legally protected. If you are not the intended recipien=
t, you are hereby notified that any review, disclosure, copying, disseminat=
ion, distribution or use of this communication is strictly prohibited. If y=
ou have received this communication in error, please notify the sender imme=
diately by return e-mail message and delete the original and all copies of =
the communication, along with any attachments or embedded links, from your =
system.
