mailing list archives
RE: common time-management mistake: rack & stack
From: "Holmes,David A" <dholmes () mwdh2o com>
Date: Thu, 23 Feb 2012 11:54:47 -0800
The problem with using engineering as a model is that computer science networking 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 specifications, preliminary design reviews, and various iterations of final design
reviews involving engineering drawings and CSI-format specification documents where a 6 year start-to-finish time frame
is not unusual. The number of PEs who can operate in real time is but a fraction of all PEs, and those who can plan a
project with a 1 week time frame, and implement the project at 3 am in the morning is a yet smaller fraction. ( and
don't even think about the number of PEs who can get a 3 am call and must fix a broken network 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 other large construction projects, but this
ability does not transfer to computer science, and computer networking.
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
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 licensed 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 broadcast systems in the 5-50KW range, doing
'technician' things like phasor rocking, transmitter retubing and retuning, monitor point and radial measurements,
transmitter installation, and tower climbing, in addition to more mathematical and engineering sorts of things like
initial coverage and protection studies for pattern/power changes, measured radial ground conductivity/dielectric
constant curve fitting/prediction contour overlap studies and models, as well as keeping up with FCC regulations and
I left broadcasting full-time in 2003 for an IT position, as a stress-reducer (and it worked.). So I say this with
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 hosted by
broadcast.net; in this regard the network ops community isn't too dissimilar from the broadcast community.
Now, while in the broadcast role I had the distinct honor of having three fantastic personal mentors, two of whom still
stay in touch, and one who died 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 worked in practice than ten hours of class time could
have. Likewise, I know 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
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 teaching 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 doing 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 like 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 result 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 book. Especially due to some of the
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 things 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 transmitter's meters, and every broadcast licensee (holding the station's operating
license, that is) had to employ 'operators' holding an active First Phone to keep an eye on the transmitter during all
operating hours, with the First Phone of every operator posted at the site, and even the DJ's had to have a Third Class
Permit to run the audio board, and periodic FCC inspections were frequent. So that's the extreme situation in terms of
licensing, just 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 recipient, you are
hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is
strictly prohibited. If you have received this communication in error, please notify the sender immediately 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.
RE: common time-management mistake: rack & stack George Bonser (Feb 17)
Re: common time-management mistake: rack & stack Jens Link (Feb 17)
Re: common time-management mistake: rack & stack Gary Buhrmaster (Feb 17)
Re: common time-management mistake: rack & stack Owen DeLong (Feb 17)
- Re: common time-management mistake: rack & stack, (continued)