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