Randy's P-Touch thread brings up an issue I think is worth some
discussion.  I have noticed that a lot of very well-paid, sometimes
well-qualified, networking folks spend some of their time on "rack &
stack" tasks, which I feel is a very unwise use of time and talent.

Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
Flying a sharp router jockey around to far-flung POPs to install gear
is just as foolish.

Not only does the router jockey cost a lot more to employ than a CCNA,
but if your senior-level talent is wasting time in airports and IBXes,
that is time they can't be doing things CCNAs can't.

I was once advising a client on a transit purchasing decision, and a
fairly-large, now-defunct tier-2 ISP was being considered.  We needed
a few questions about their IPv6 plans answered before we were
comfortable.  The CTO of that org was the only guy who was able to
answer these questions.  After waiting four days for him to return our
message, he reached out to us from an airplane phone, telling us that
he had been busy racking new routers in several east-coast cities (his
office was not east-coast) and that's why he hadn't got back to us
yet.

As you might imagine, the client quickly realized that they didn't
want to deal with a vendor whose CTO spent his time doing rack & stack
instead of engineering his network or engaging with customers.  If he
poorly the senior people at that ISP managed their time.

With apologies to Randy, let the CCNAs fight with label makers.
--
Jeff S Wheeler <jsw*******>
Sr Network Operator  /  Innovative Network Concepts

It's not a waste, it's therapeutic, breaks the monotony of a desk
job, you get a bit of exercise. Doing something mindless can help
clear your thoughts, engineering yoga.

That'd be a good idea, it's too easy to become remote from reality.
obviously you need the right balance - s/big//

brandon

No, your CTO shouldn't  be racking and stacking routers all the time.  Thefundamental concept of an organizational hierarchy dictates that.  But a CO who has lost touch with the challenges inherent in racking and stacking  router can't effectively support his team.  See the TV series 'undercoverboss' for a (possibly trite and clichéd) example of this.

"Your position never gives you the right to command. It only imposes on yo the duty of so living your life that others can receive your orders withot being humiliated."
--Dag Hammarskjold

I'm not suggesting it's a crime for the CTO to put his eyes and hands
on a POP local to his office once in a while, or pay a visit to his
gear in a city where he happens to be in to conduct business that
requires the presence of the CTO, not a CCNA.

This, however, is exactly the kind of thinking that produces bad
managers.  Yes, it can be boring sitting at a desk all day.  If that
is your job, don't ignore it so you can play site tech while to-do's
pile up in your absence.  If your are a senior decision-maker, don't
set a bad example for everyone else in your org by blowing off your
senior-level duties to fly around the globe doing something that you
have CCNAs for.

The "my desk-job is boring so I spent the day racking gear" message is
fine if you are not blowing off real work to push boxes through the
co-lo.  If that's your hobby, fine, but rack & stack is not part of
the CTO, network engineer, or whatever, job.  It's a hobby and you
shouldn't ignore your actual duties to go do it.  It's no better than
spending the workday at the movie theater or playing world of warcraft
at the office.

If you don't have any junior-level employees to do the junior-level
work, yes, this is certainly true.  But as soon as that "CTO," who is
also wearing a bunch of other hats, finds himself with a long to-do
list, the first thing he ought to do is delegate tasks like rack &
stack to inexpensive workers so he can use his most valuable
strengths.

Obviously we are throwing around the term "CTO" at this point in
reference to pretty small businesses, but the basic concept here is,
don't let mundane tasks get in the way of work you are specially
qualified to do.  Definitely don't go out of your way to do mundane
tasks so you can play IBX tourist on your company's dime!

--
Jeff S Wheeler <jsw*******>
Sr Network Operator  /  Innovative Network Concepts

+1

I picked up ram from a supplier today.  Could have used a courier, but
getting out of the office is vital.

A CTO who's lost touch because they haven't been to a remote site in
half a decade is a business risk, more so than the CTO being away from
their desk.

If there is business risk from having the CTO out of touch for a week or
even a month then there's a bigger problem.

D

--
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699

1 I find this myself, it's useful to do this, as it is to sitin with the operations team and other groups (even finance) tounderstand what other groups need/require.  I've often found thatsomeone is working around a problem they didn't know you could solve(easily), or is doing a large amount of manual labor when there is anAPI, etc.

    Perspective is good.  I also do other work that certainly isn'ta complete use of my talents that benefits others (e.g.: chaperone afield-trip at school).  These are not without merits, but I do know Ihave my faults in perhaps reading (and responding) to NANOG too muchwhen I should be engaged in more worthwhile tasks.

    - Jare

I think it was Miagi in Karate Kid that stressed balance.  The CTO who
is NEVER out of his cage is dangerous, likewise the one that is never
available is also.  It is keeping in touch with what is happening at all
levels that makes him valuable.  If there is one thing that American
Management misses, it is that.  The GROWING companies almost always have
management that is active, visible and accessible - top to bottom.  The
ones that are dying are not.  The same goes for union leaders who are
really pseudo-management.  The senior technicians are no different than
management, they need broad focus but they must also be able to take the
magnifying glass and look at the current situation.  A network engineer
who cannot do both is not living up to his job description.

Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone  1 717.506.0802
FAX  1 717.506.4358
Email Ralph.Brandt*******
5095 Ritter Rd
Mechanicsburg PA 17055

on the contrary, we'd PREFER if CEO's and CTO's of our trading partners
know what their company is doing and how their core network actually
works. (Rather than just giving one of those stupid flyers with a world
map and some lines representing their network to potential customers ;)

no "startrek questions pls". :P.

(and rack & stack with "routers" is something else than rack & stack with
serverfarms, as for servers, you can just as well have an installation
company or the vendor do it for you ("clearance" issues set aside ;)..
with routers its a bit more touchy which wire goes where exactly, and
furthermore, they have to be individually configured during install, so
its better to just be there, CTO or not CTO :P

you might be confusing the CTO for the sales manager :P

Hi,

     Or sometimes you don't let a hazardous task like handling a Carrier
Class Router to your CCNA in case they injure themself.

     Or worst...  drop it =D

     ( From an actual experience )

-----
Alain Hebert                                ahebert*******
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911   http://www.pubnix.net     Fax: 514-990-9443

Definite +1 here.  I got my start in this profession 15-ish years ago at a
mid-sized regional ISP.  The company was small enough, in terms of its work
force, that that I interviewed with the CEO for what was largely an IT
position.  As a result, many people in the organization wore lots of
different hats.  It wasn't to the point of having accountants pull cable
or IT guys doing the books, but I did spend a lot of time doing
rack-and-stack work.  I didn't (and still don't) mind rack-and-stack,
diversion from staring at a screen and attending meetings ;)

Another good reason for getting out into the field.  When you're the
person who defines technical deployment standards for an organization, it
gives you an opportunity to verify that work is being done to those
standards.

I'm sure if the ISP I got my start with 15-ish years ago was much bigger, I
would not have interviewed with the CEO, but at that time, it was the right
fit for that organization.

jms

Hrm.

This.

One of the reasons I love my job so much is that I don't need to be
stuck at a keyboard all the time.

I usually "volunteer" to help rack and stack new hardware that I
haven't had a chance to touch yet.  "For humans, touch can connect you
to an object in a very personal way, make it seem more real."

: )

--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

actually most west european countries have laws against having your
employees lift up stuff heavier than 20 kilos :P

you generally don't have insurance on your network-dude to handle such
things *grin* if it drops on his foot, you're screwed. (or worse, on his
hand ;)

looking at the latest models we found units weighing 110 kilos *grin*
i'm not lifting -that- up.

--
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven*******
=========================================================================
<penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.

IT job postings in the US often include physical qualifiers such as "must
be able to lift weights of up to 50 pounds (~22.7 kilos)" and "must be
able to use hand tools".  The lecture about using safe lifting practices
usually waits until after you accept the job and go through your
new-employee orientation :)

jms

At the risk of offending many folks on NANOG, our industry is more
like a trade than a profession.  In many cases we would do better
to treat our people (in terms of how they are managed) like skilled
trades, electricians, plumbers, metal fitters, rather than pretend
they are white collar professionals.

Low level employees should be apprenticed by higher level employees.
Many of our skills are learned on the job; just like other trades
someone with only book knowledge is darn near useless.  Not only
do those above need to teach, but they need to supervise, and
exercise standards and quality control.

To your point, if you look at skilled trades the simpler the task the
more likely it will fall to the "new guy".  Rack and stack is probably
one of simplest jobs in our industry.  A two man team, one senior, one
junior, showing up at a colo may see the junior guy doing the physical
work, while the senior guy works out any issues with the colo provider
brings up the interconnection to them, etc.

But key to an apprenticeship is that the senior guy does some of
the low level work some of the time, and _shows_ the junior guy how
to do it right.  The senior guy might rack or stack a couple of
boxes each colo they visit, and relate concepts like how the screw
hole spacing works in the rack rails, how to plan cable management,
proper labeling, and so on.

It really accomplishes much of what everyone else is talking about,
while still being productive.  The "old hat" gets the downtime and
catharsis of doing a simple, yet productive task.  The new guy gets to
learn how to do the job properly.  The employer knows the work has
been done right, as it was overseen by the old hat, and that they will
have someone to replace him when the old hat retires.

Maybe if we did more apprecenship style learning folks would still know
how to wrap cables with wax string.  It's simple, fast, and works well.

--
       Leo Bicknell - bicknell*******- CCIE 3440
        PGP keys at  http://www.ufp.org/~bicknell/

> -----Original Message-----
> From: Jeff Wheeler
> Sent: Thursday, February 16, 2012 11:30 PM
> To: NANOG
> Subject: common time-management mistake: rack & stack
>
> Randy's P-Touch thread brings up an issue I think is worth some
> discussion.  I have noticed that a lot of very well-paid, sometimes
> well-qualified, networking folks spend some of their time on "rack &
> stack" tasks, which I feel is a very unwise use of time and talent.
>
> Imagine if the CFO of a bank spent a big chunk of his time filling up
> ATMs.
> Flying a sharp router jockey around to far-flung POPs to install gear
> is just as foolish.
>
> Not only does the router jockey cost a lot more to employ than a CCNA,
> but if your senior-level talent is wasting time in airports and IBXes,
> that is time they can't be doing things CCNAs can't.
>

I see this as a double-edged sword.   You don't want your "C" staff out inthe field actually installing gear as a general course of operations as tht is a great waste of their time/talent unless the "C" role is more "honorry" than anything else.  That said, you might want a senior technical persn on site overseeing the installation, checking the configuration, interfaing with vendor staff, testing things, etc.  And it is good to have this snior staff member present when things go sideways as is often the case wit new installations and often these issues are physical and are best solvedwith someone senior on site who can make decisions on the spot or carry moe weight with the provider to get things done quickly. This should be somene that was involved in discussions with the vendor's rep. during the planing phase.  If you get too reliant on sending only the cage monkeys (a ter I use with fondness) then what happens when problems turn up greatly deped on your corporate culture.  Do they simply stop, report the problem and ait for direction?  Is there anyone on site that has the trust of the orgaization to make decisions on the fly and cut through the organizational re tape? Can they authorize a configuration change to work around something nforeseen?  Having someone senior enough on site to make these decisions ad carries some weight with the vendor can greatly reduce the time it takesto get a data center up and running.  Granted, he doesn't need to be therewhen the initial cables are being laid out but should be there once equipmnt starts being installed in racks and configured.  Having that experienceand authority on site at the time of installation can be quite valuable.

http://www.serverlift.com/solutions/products/sl500x-server-l[..]

1  I believe that can not be stressed enough. There is also another aspec to it in that about 15% of the population of people are "abstract" thinkes and 85% are "concrete" thinkers.  The abstract thinkers are the ones whocan come up with a vision in their head of how something should work as a ystem and then set out and build it.  Or when they are faced with a proble, can in their head envision the work around and then apply that vision onsite to do things such as rewire a portion of the network in a methodical ashion with no/little downtime.  Those people are relatively rare and workng with your line staff gives one an opportunity to assess the various talnt sets of the people in the organization.  The abstract thinkers are the nes good at being able to design a network from scratch and the concrete tinkers are the ones who will be great maintaining that network and keepingeverything documented and done according to policy.  You need both and it ust so happens that you need more of one sort in just about the same propotion that you find them in the general population.  The key is to identifywhich people have which talents and place them where their natural abilitis more closely mesh with their job requirements.  If you can do that, you an have a very powerful team.  If you place people into positions simply bsed on the number of years in the organization or because of holes punchedin the cert ticket, you might end up with people in positions that they do't really like or aren't particularly good at doing.  The first step in bulding such an organization, though, is working closely with your people an attempting to identify whose natural abilities like in which direction.  ometimes it is more about talent than training, more about nature than nurure.

But at the same time, if you have a guy who might not be so sharp at troubeshooting a very complex network but is sharp as a tack when it comes to dcumenting things and keeping paperwork organized, that is a vital skill inthe overall effort, too.  That person should be given responsibility for mintaining more of the documentation, organizing things so they are easy fo other employees to find, etc. and their pay should still continue to incrase as they gain wider scope across more of the organization over time.  Te point is that it often takes many different sorts of skills and attemptig to match people's natural talents to the requirements of the organizatio benefits both parties provided the individual involved doesn't see their osition as a dead end.  A good person of the sort mentioned above can liteally save hours of time for people doing other tasks such as troubleshootig a problem.  There is a certain synergy involved and some organizations rcognize that, and some don't.  Some are better in an architectural role, sme are naturally better in a sustaining role, others are better at an orgaizational support role and (darned) few are good at all of those tasks.  Smetimes we don't have the luxury of such specialization of roles, but someorganizations do, particularly if they are in a phase of reorganization an downsizing.  One thing to look at might not only be "how good is this peron in their current role" but also "would this person absolutely kick buttin a different role".

Actually, just having the senior person assist with some tasks such as movng/installing heavy/unwieldy gear does more than just show them how to do t right, it is actually quite an important almost sort of bonding experiene between employees.  It says "I'm not allergic to work and not above doin the same job you are doing when it needs to get done, we are all importan pieces of the big picture."  It can give an employee a sense that they ar respected and appreciated for the job they do, even if it is fairly low o the corporate org chart.  It is still vital to the success of the overallbusiness or they wouldn't be there to begin with.  Doing things like this elegraphs that in a tangible way without having to spew a lot of corporatepropaganda.



The "old hat" still gets job satisfaction from seeing a vision come to phyical life and operate as planned.  Why deprive them of that?  It can re-enrgize one's love of a particular carrier field and remind them why they ar in that field to begin with.

Leo, in many trades, telecommunications being one of them, the military wa one source of new people with some skills and with some hands-on experiene.  As that scales back these days, it gets harder to find such people.  W don't have trade schools and we don't have apprenticeship programs like cmpanies used to have so I agree.  People coming out of a community collegeor a certification program know enough to be extremely dangerous (sort of ike a lieutenant with a screwdriver, the most dangerous person in the worl aside from a corporal with a clipboard) and need to be mentored as they gin perspective in real world situations.  I completely agree that we shoul be looking more at our employees in the longer term as a nurturing proces and identifying where their natural interests and abilities can benefit bth sides of the equation.  Having that interaction with the senior staff i vital.  And that senior staff member should not only be explaining WHAT h is doing, but WHY he is doing it that way.

would have been good to know to whom you were replying, not in To: or in
pre-quote text.

i configure routers, admin servers, and occasionally rack and stack in
my own research racks [0].  aside from giving me a base in reality
instead of all research papers and power point (a major benefit), it's
like housework or doing the dishes, shut up and do your part.

it's also damned useful to maintain layer zero skills.  once upon a
time, when i was playing at vp eng, a london routing hub was supposed to
be turned up.  the equipment sat in co-lo receiving for weeks, and no
respose from the london techs (i am sure they had ccnas, whetever the
hell that is).  so i grabbed my toolkit and got on a plane and walked
into redbus and started turning it all up.  the local techs appeared
pretty damed quickly and started doing their jobs.  of course, a few
weeks later they were told to get jobs elsewhere.

maintain your skills, you may need them again some day.

randy

---

[0] - deep thanks to (in alpha order) cisco, equinix, google, juniper,
      nsf, and others for contributions.

Knowledge transfer should also include the very important WHY NOT to do
something a certain way.  This part is often left out.  Considering that
most bit-twiddler tasks can be performed a multitude of ways, both sides of
the argument should be presented.  Perhaps this is obvious to all on the
list, but it's certainly not to junior staff.

Yeah. And you need do be at last CCNP to switch a module in a router.

Had this request last year. I first thought that some troubleshooting /
configuration was involved but it was just replacing a module.

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany    | +49-151-18721264     |
|  http://blog.quux.de  | jabber: jenslink*******| -------------------  |
-------------------------------------------------------------------------

There is a theory of management that says a good manager
needs to know nothing about the staff or the jobs he is managing,
because his job is about returning profit to the shareholder,
and not about what the company does.  AFAIK, these
theories are made in the academic halls of the business
schools, which churn out MBAs, and, self-selected group
that they are, believe in (more) managers, and (more)
powerpoint business plans, and (more) theory.

I happen to come from a different background, and believe
that it has value to understand what the people who are
working for you actually do.  That does not mean the CEO
should spend all day delivering the mail (or flipping burgers),
but she had better have done it a few times, and it is a good
idea to do it from time to time to see what has changed.
It keeps the manager grounded with the reality.

(I have been told that the reason that the commanders
in the Army are reluctant to send their people to battle
is that they have experienced it, and know it is hell.
And the reason the people will go to hell for their
commander is that the commander has the moral
authority of having done it, experienced it, know
that they are asking a lot, but it is for the common
good.  People will follow a leader who has been there,
done that, and not so much when it is just an academic
business plan on a powerpoint slide.)

With all due respect, Jeff, I think you are missing several factors thatcome into the human equation beyond merely the most efficient use of aparticular person's time.

I would go stark-raving bonkers trapped in a cubicle doing only thingsthat CCNAs can't if I didn't get the occasional break to go out and playwith real hardware in the field. Most of the well-paid well-qualifiednetworking folks I know are the same way.

I also think that when we spend too many consecutive weeks/months/yearsbehind a desk without going out in the real world, we becomeprogressively more detached from the operational reality where ourdesigns have to operate.

On the surface, it might seem an inefficient use of financial/humanresources, but, I think that there is value to time in the field thatdoesn't necessarily show up directly on the balance sheet.

Admittedly, in my current position, I'm no longer in an operational rolefor the most part, but, I'm even more out in the field and spending moretime in airports.

Owen

nothing about the staff or the jobs he is managing, because his job is about
returning profit to the shareholder,
the academic halls of the business schools,
(more) managers, and (more) powerpoint business plans, and (more) theory.
value to understand what the people who are working for you actually do.  
flipping burgers), but she had better have done it a few times,
reluctant to send their people to battle is that they have experienced it,
and know it is hell.
commander has the moral authority of having done it, experienced it,
will follow a leader who has been there, done that,

+1 for Gary's comment.

That is the large difference between LEADING and MANAGING.

In the context of the military scenario above, Grace Hopper comes to mind
because of her nanoseconds etc
"In her retirement speech, instead of dwelling on the past, she talked about
moving toward the future, stressing the importance of leadership." http://inventors.about.com/od/hstartinventors/a/Grace_Hopper[..]
I was lucky enough to have heard her speak once at an ACM event.

Tony Patti
CIO
S. Walter Packaging Corp.

Cue the obligatory cabling porn thread.

Cheers,
-- jr 'and aren't all the old Bell guys dead now?' a
--
Jay R. Ashworth                  Baylink                       jra*******
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates      http://baylink.pitas.com          2000 Land Rover DII
St Petersburg FL USA       http://photo.imageinc.us              +1 727 647 1274

I still have my nanosecond. Did she hand them out to the crowd there?

--
Mike Andrews, W5EGO
mikea*******
Tired old sysadmin

Yes, of course!

Pentagon...

Of course, she is also famous for "It's easier to ask for forgiveness than
it is to get permission"
Notable Quotation from her Wikipedia page at http://en.wikipedia.org/wiki/Grace_Hopper  

Tony Patti
CIO
S. Walter Packaging Corp.

There is a theory of management that says a good manager
needs to know nothing about the staff or the jobs he is managing,
---------------------------------------------

<neck hair == raised>  :-)

From empirical data, this is not a good thing for companies.  They
constantly make bad choices because they not only don't understand the
concepts, but can't even grasp the consequences of their decision.

For example, I had four GigEs each to several upstreams.  I pointed the BGP
session to the loopback at the provider's router, so the traffic would load
share across the four GigEs.  I was told my one of those managers who "needs
to know nothing about the staff or the jobs he is managing" that was not
redundant and that I had to do one BGP session per GigE, so four BGP sessions
to each upstream.  After some heated discussions with the manager about why
that was not a good design decision, I warmed up my resume and started looking
for a new job.

scott

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
are learned on the job (poorly), rather than folks coming in with solid
fundamentals. 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.

The true problem is that most "networking" professionals came out of a
CS background or are self-taught. They might be clueful and they might
be highly adept, but they lack the structure of an engineering
educations and formal mentorship. They also lack real licensing, which
is a separate problem.

Rack and stack is not a network engineer task, anymore than running a
208/3 phase circuit is an electrical engineer's task. Instead, rack and
stack is a task for a skilled telecom tradesman. I have nothing against
network engineers getting out of the office to do this, but the quality
of their work will never be up to a real telecom guy. Look at the
cabling. You can always tell which has been done by a "network engineer"
and which has been done by a real tradesman. Guess which one is better?

Dan

In software, this problem is a rather well known "Antipattern":

http://c2.com/cgi/wiki?ArchitectsDontCode

(This is an "Antipattern", i.e. it actually means "Architects *MUST*write code".
But the problems from doing this getting in the way are also discussedthere, so Jeff gets some support, too.)

Grüße, Carsten

"The designer of a new kind of system must participate fully in theimplementation."
So, the more cookie-cutter your systems become, the less important isthe requirement to do this over and over.
But having it done once, and recently enough, still is a qualificationfactor for an architect.

PPS.: I'm less sure about the battlefield analogies :-)

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 such.  

I left broadcasting full-time in 2003 for an IT position, as a stress-reducer (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 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.

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 respectful disagreements.

Vendor-specific certifications don't help much, either, really, in the 'why' department.

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.

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*******- CCIE 3440
        PGP keys at  http://www.ufp.org/~bicknell/

N©®�åzl"¶¬�x�§yêâ�¬jjzX¬¶­r�©º×«±È��ǧzÜ

1- what do you mean by "Licensed folks working in architecture and design"=0A =0A2- You wrote "IT isn't governed by the same hard (physical) rulesas=0Atraditional engineering, but you also can't be freely creative and=0Axpect to come up with something that works." bolox!=0AAs far as I'm aware ou are not showing any creative work that requires the copywrite/authoringwork. Unfortunatly the great majority of us are "users" of the system. Tere are different levels of users, some more cleaver than others.=0A =0Ahe one that looks for data sets in databases in in IT and so is into "scriting" and CShell.=0A =0AThe sponsor is the issue.He was tasked to do so have you ever been employed or have been offered employment by someone hat has a lower weight than you have?=0Athe frameworks seem to be known moe and more and still................some face unemployment whereas others re and will always be your sponsors- think about the director of your loca post office  :-)=0A =0AHave you ever thought the reason why you are ding what you are doing instead of signing a PO?=0A =0AWho's business is his ? do you know why you are required to have at least three A levels? an at least two MSc/MA? Or even maybe a PhD? Where exactly are you based?=0 =0A =0A =0A =0A =0A =0A =0A =0A =0A=0A=0A_______________________________=0AFrom: Leo Bicknell <bicknell*******/~bicknell/