Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NANOG: users

common time-management mistake: rack & stack

 

 

First page Previous page 1 2 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded


tony at swalter

Feb 17, 2012, 10:56 AM

Post #26 of 33 (500 views)
Permalink
RE: common time-management mistake: rack & stack [In reply to]

> From: Mike Andrews [mailto:mikea [at] mikea]
> Sent: Friday, February 17, 2012 1:44 PM
> To: 'NANOG'
> Subject: Re: common time-management mistake: rack & stack
>
> On Fri, Feb 17, 2012 at 01:15:09PM -0500, Tony Patti wrote:
>
> > 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_2.htm
> > I was lucky enough to have heard her speak once at an ACM event.
>
> I still have my nanosecond. Did she hand them out to the crowd there?

Yes, of course!

I remember that she said they were borrowed from a phone closet in the
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.


surfer at mauigateway

Feb 17, 2012, 11:42 AM

Post #27 of 33 (509 views)
Permalink
Re: common time-management mistake: rack & stack [In reply to]

--- gary.buhrmaster [at] gmail wrote:
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


dgolding at ragingwire

Feb 22, 2012, 12:37 PM

Post #28 of 33 (500 views)
Permalink
RE: common time-management mistake: rack & stack [In reply to]

> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell [at] ufp]
>
> 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.


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.


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

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


cabo at tzi

Feb 22, 2012, 2:19 PM

Post #29 of 33 (495 views)
Permalink
Re: common time-management mistake: rack & stack [In reply to]

On Feb 17, 2012, at 18:55, Owen DeLong wrote:

> I also think that when we spend too many consecutive weeks/months/years behind a desk without going out in the real world, we become progressively more detached from the operational reality where our designs have to operate.

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 discussed there, so Jeff gets some support, too.)

Grüße, Carsten

PS.: Donald E. Knuth said:
"The designer of a new kind of system must participate fully in the implementation."
So, the more cookie-cutter your systems become, the less important is the requirement to do this over and over.
But having it done once, and recently enough, still is a qualification factor for an architect.

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


lowen at pari

Feb 23, 2012, 10:59 AM

Post #30 of 33 (491 views)
Permalink
Re: common time-management mistake: rack & stack [In reply to]

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

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

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


bicknell at ufp

Feb 23, 2012, 11:35 AM

Post #31 of 33 (495 views)
Permalink
Re: common time-management mistake: rack & stack [In reply to]

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


dholmes at mwdh2o

Feb 23, 2012, 11:54 AM

Post #32 of 33 (492 views)
Permalink
RE: common time-management mistake: rack & stack [In reply to]

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.

-----Original Message-----
From: Lamar Owen [mailto:lowen [at] pari]
Sent: Thursday, February 23, 2012 10:59 AM
To: nanog [at] nanog
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 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.

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

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


isabeldias1 at yahoo

Feb 23, 2012, 12:00 PM

Post #33 of 33 (504 views)
Permalink
Re: common time-management mistake: rack & stack [In reply to]

1- what do you mean by "Licensed folks working in architecture and design"?
 
2- You wrote "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." bolox!
As far as I'm aware you are not showing any creative work that requires the copywrite/authoring work. Unfortunatly the great majority of us are "users" of the system. There are different levels of users, some more cleaver than others.
 
The one that looks for data sets in databases in in IT and so is into "scripting" and CShell.
 
The sponsor is the issue.He was tasked to do so! have you ever been employed or have been offered employment by someone that has a lower weight than you have?
the frameworks seem to be known more and more and still................some face unemployment whereas others are and will always be your sponsors- think about the director of your local post office  :-)
 
Have you ever thought the reason why you are doing what you are doing instead of signing a PO?
 
Who's business is this ? do you know why you are required to have at least three A levels? and at least two MSc/MA? Or even maybe a PhD? Where exactly are you based?
 
 
 
 
 
 
 
 
 


________________________________
From: Leo Bicknell <bicknell [at] ufp>
To: Dan Golding <dgolding [at] ragingwire>
Cc: NANOG <nanog [at] nanog>
Sent: Thursday, February 23, 2012 7:35 PM
Subject: Re: common time-management mistake: rack & stack

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

First page Previous page 1 2 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.