common time-management mistake: rack & stack

Leo Bicknell bicknell at ufp.org
Thu Feb 23 19:35:39 UTC 2012


In a message written on Wed, Feb 22, 2012 at 12:37:57PM -0800, 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. The problem with "networking" is that TOO MANY skills

Actually, the differences are deeper than you suggest, and it's why
the model you suggest won't work for networking, yet.  I think
there's a chance they may in the future, although it's not a given.

There are several aspects to licensing, but one of the most important
is that the applicant knows basic rules of the profession.  In most
cases these rules are codified into law, and can be tested in a
straitforwad way.  An EE doesn't go around saying "run your circits
at 80% unless you have a 100% duty breaker" because it's a good
idea, or they like it, or their vendor told them do.  They do that
because it's part of the National Electric Code which everyone
(including non-licensed folks) is _required by law_ to follow.

Networking does not have "codes".  There's nothing to test against.
If we wanted to apply a licensed engineer model to the networking
field the first thing that would need to be developed is a set of
comprehensive codes.  Anyone who's experienced PCI (as an example
of an IT attempt at something similar to a code) and also worked
with a more established one (NEC, NFPA, etc) knows that IT isn't
even in the same ballpark yet.  I won't go into the reasons here,
I think there are many and we could discuss that for hours.

But I actually think your analogy is more misplaced because the
names do not line up.  The networking equivilant of an EE or ME is
the "Network Architect".  EE's and ME's are designers in their
professions.  They write up blueprints and plans.  This is also
what network architects do.  Think a CCDA operating as a sales
engineer.  They draw up a design but never implement it.

Network Engineers are the trades people.  We come up with really
dumb names like Network Enginneer 1, 2, 3 and 4.  In a real trade
these would be apprentice, journyman, master, supervisor.  They
take the plans and turn it into something.  In a real trade
(electrican, plumber, hvac, etc) the supervisor interacts with the
apprentice, journeyman and master, who are all working on the same
team.  The subtasks are divided according to skill.

In IT, the Network Engineer 4 thinks he only needs to talk to the
Network Engineer 3.  Everyone else is "below him".  How many companies
have Network Engineer 1's that aren't allowed to even log into many
of their network devices, or call the engineer level 3's and 4's
on the phone?  This is absurd.  Some companies even put them in
different call centers sioled away from each other so they don't
even know who call!  This is where I think we need more mentorship
and teamwork.  When a team of electricans shows up the apprentice
does a lot of the meanial work, but is also allowed to do some of
the higher level work, under strict supervision.

I think, in a sense, we agree more than disagree.  There are established
models for engineering disciplins and IT would probably do better in
many ways if it were to fall in line.  Licensed folks working in
architecture and design.  Codes to standardize and provide quality
control and safety.  Apprenticed skilled trades to implement.  What
we're arguing over here is some minor semantics of how that structure
works in IT.

HOWEVER, I am not sure it completely works.  Here's why; some
colleges have C.S. in the Arts and Sciences college, and treat how
to program more like how to write a novel than how to build a bridge.
Others have it in the Engineering college, and treat it more like
building a bridge than writing an novel.  What seems to work is a
blend in the real world, treating most IT tasks like classical
engineering doesn't work out well, nor does treating it like writing
a book.  IT isn't governed by the same hard (physical) rules as
traditional engineering, but you also can't be freely creative and
expect to come up with something that works.

I personally would like to see the industry work on the "code"
problem, which would be necessary pre-work for licensing.  I'd also
like to see trade style mentoring.  I think those can proceed in
parallel.  I'm just personally prepared for the eventuality that
IT might never fit into as ridgid a framework as EE or ME.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120223/1efc1bbd/attachment.sig>


More information about the NANOG mailing list