> I'm not quite sure where this is going to go, but as you may know, > I've worked pretty extensively in medicine, have developed expert > systems for diagnosis, etc. When you mentioned Doogie Howser, you > gave me several flashbacks to some very bright young interns that > don't necessarily have the practical experience. > > Now, Doogie would probably start by ordering a complete blood count > to decide, on the spot, if there is an infection, since the physical > exam is equivocal. While I could do the blood count if I had the > equipment, I don't. Instead, I reach back to what probably isn't in > any textbook, but I learned from watching good clinicians. The > complex diagnostic instrument I'm using is a ball-point pen. I > outline the red area each night and compare to see if there is > significant spreading (also checking for other warning signs that > would be immediate red flags). If I see spread beyond a certain > level, I'd call one of a couple of physicians I know well, and say > "It's looking as if I have mild cellulitis of the lower left > extremity. Do you mind phoning in a prescription for an appropriate > antibiotic, presumably a second-generation cephalosporin?" I'd > probably get the prescription, because that doctor knows I have the > experience to know I've done what he would have done. In any event, > I'll be seeing people at NIH on Tuesday, as part of a research trial, > so I'll get a doublecheck.
While I think your analysis and diagnosis was very creative, however, would that fall under the years of advanced hardened experience or the tricks of the trade? Is that something you required years to learn or is it possible you could have just done it simply by being creative. (I want to find out if my swelling is getting worse, let's get a ball point pen or measuring tape!) I know some individuals who have this knack, yet, it is not quantifiable on the resume and it did not necessarily require years of experience. Also, I guess this depends on how we define Doogie as a character. I did not watch many of the shows, so I do not know if he was characterized as a bright guy but generally naove, inexperienced person. Let us say, Doogie is a Howard in his younger years. :) > An experienced physician does history and physical much differently > from a beginner. The beginnner will probably start by spending equal > time on each body system, where part of experience is knowing how to > identify *cough* the appropriate OSI layer and then to hone in on the > details. I suppose so, but I think that varies greatly. i.e the "experienced" person might be mal-experienced so to speak. He might think "ah ha, it has to be a network layer issue, I worked on this crap for 5 years and I always add all three protocols on Microsoft NT servers, and it always worked for me." Where as someone new but with a much stronger base on the theory might say, "but nothing showed it was the network layer and, there is no reason to put in all three protocols in there when we already validated one of the protocols work." The "old rotting knowledge" syndrome. Rotting experience that somehow is misapplied or has not been updated in a while. :) (yes it is okay to buy switches now, they do N way switching now...) I admit, I was the victim in this case. A few fellow engineers of mine who were "new" but were very bright and knew the theory of networking very well challenged some of my statements based on my "experience". Despite working on it significantly longer, if I cannot debunk the theoretical claims, something might be wrong with what I have done but coincidentally it "worked". I am sure you have seen that in your travels... hmm yes, look at this wonderful network that "works". You go in there and see it's a ticking timebomb ready to go off and it's been taking that 512K Frame Relay Circuit instead of the 1.5 Point to Point, and they were ready to buy ANOTHER T1 with the 1.5 Point to Point to do some load balancing since congestion was getting bad. While I am certainly not saying a bright individual with less experience is "better" or "equal" to a bright individual with greater experience, those with the greater experience and larger learning capacity are extremely rare or at least, tend not to be in this field for very long. (they get bored, as NRF pointed out) Being "out in the field" for a few years by no way guarantees this from what I have seen and may not even demonstrate any level of growth. > >My comment was joking about the sheer lack of general knowledge many > >IT people have there. If you did not learn about network layering > >(in the generic sense), and did not identify the protocols or learn > >about the protocols you are working with within a few weeks, how long > >is it going to take you? > > Often a long time, especially when someone mutters a mantra "there > are seven layers at which protocols go", and not realize (1) that's > only half the OSI model, because service interfaces are just as > important as protocol interfaces [Priscilla was talking about that > the other day] and (2) OSI doesn't fit everything. Right, which is why I specifically left out OSI in my comments. :) Some people just have no idea that some things can be layered at all. I mean in the very basic primitive sense. They have no idea how to apply the layering knowledge when they are by the router. "Why can't I ping XYZ?" I knew someone who worked in NOCs for 2-3 years. I did some training for them and this guy did not know how to do any form of DNS lookup (be it through nslookup itself, dig, dnsq, etc) or basic ping/traceroute testing. Years... years and he did not know what many I know learned in months. Of course this specific guy might have failed on his first round exam, but he could become a CCIE Bootcamping labrat in a few months easily too. > >So, a good number of these Doogie Howsers have no way of easily > >distinguishing themselves. Even if you are a Doogie, you do not > >necessarily have the rest of the skill sets to acquire a job. i.e. > >social skills, people skills, the network of friends, etc. > > Historically, that's been easier for developers than people in > operations. Creative code gets recognized. > > Writing for publication is an excellent way to distinguish > yourself--in many directions. I wince whenever I see a post here in > "chat speak", such is u see, yr router is ok. It's probably not fair, > but I tend not to take such posts seriously. True, creative code does get recognized more easily. However, I am pretty sure we have some good coders hurting for jobs too. Anything with creativity tends to be on the extremely rare spectrum of being picked out. I wonder how many of the HR heads are thinking "outsource to India" instead, you can get 5 progrrammers for the price of one! > >> Consider the case of airplane pilots. Just to get an pilot's license, you > >> must have a certain minimum number of documented flying hours. To be hired > >> as a pilot for an airline, you must have documented proof that you had at > > > least several hundred hours of flight time, and sometimes several > >thousand. > > > >Well, even in THIS case it is far more reasonable. Documented hours > >of hard testing/working on networking gear in a "lab" by Cisco. That > >I would go for. Because, like I said 3 years of router rubbing ... > >come on, I am sure you have had assignments which let you demolish > >that "knowledge" in a few months! Thing is, you have no idea if they > >are actively working on networking for the 3 years. For the flying > >case you are directly clocking them for... flying. It is not even > >necessarily a "production network" (as in, commercial flying... :) ). > > When I did IBM system programming, we had an informal rule that you > couldn't call yourself a REAL system programmer until you had done > something that brought the mainframe down in the middle of prime > operations. People learn from sheer horror as well as study. True. However, I also know some people did risky moves however what they also learned was they were potentially risking their job. (Strongly depends on the employer of course) Afterwards, they clam up, and do not try risky things anymore. Bringing down critical services accidentally may be a good way for you to know "whoa, better NOT try that one again during production hours", but sadly it is not encouraged despite what you may learn from it. "What, some show commands on a Nortel router force it to core dump?" "Whoops, I did not know that.." I suppose you could argue the experienced guy who knew that would have avoided running the command. The smart, younger guy might have looked into it being documented, finding out if it was fixed in a bug released through the documents, or finding out what conditions brought it to do that and patched accordingly. How they react to that in the future depends, and it is not necessarily from their experience. One might say never to use Nortel again. One might say never to use that version of code. One might say never to run that command. One might say to verify if it was fixed according to Nortel and try it again. You do not need years of experience to say any of those answers. So to keep the job, people have to be stagnant and not try wacky moves. In fact, frighteningly enough, they may be mentoring off of someone with "incorrect" experience. With no way to verify (since it might bring down the production services/network), these poor guys have to hope they are being fed the right info, instead of being passed "holy knowledge" from the years earlier. > >The only thing you did was delay them, and delay potentially > >qualified individuals. Are you even sure they will have even a SHRED > >more experience after doing carressing for so long? Is that shred > >going to really help them when they "study" for the exam by going to > >bootcamps, reviewing braindumps, etc? > > > >> Again, it doesn't eliminate those kung-fu masters forever, it just forces > > > them to wait. Is that really so bad? > > > >Right, but it does not eliminate those lab-rats either (who will have > >a name change). It only delays bright individuals who wanted to > >succeed at their own pace. Let the test judge them, not some silly 3 > >year requirement which does not necessarily result in anything that > >will contribute to the exam experience, or even their real world > >experience. > > My personal experience is that the ability to analyze and design > should be tested along with configuration and troubleshooting. The > person I want is the one that knows how to think, not just memorize. > Agreed. In high school one bright teacher told me that, and in college yet again another bright teacher told me. "Why do you think you are really here?" The answer was mainly to "learn how to learn", in the most general sense. With that kind of ability that really gives you a big jump tackling any new problem, ignoring experience. It is unfortunate there has been no way to quantify this value in an individual accurately. The key you mentioned there was you want someone to knows how to think, not just memorize. One could argue after years of "experience" they learned how to think a bit more. Sadly, this is not guaranteed at all from what I have seen. However, I think a fair percentage of the basics can easily be learned and at a much faster rate. Memorization in the IT field is dangerous. It tends to become obsoleted so fast, you are really safer off throwing in "as of today" as a catch phrase behind any overencompassing statement. Surely one does not want to end up quoted like Bill Gates "You will never need more than 640K of memory". With a solid ability to think, you can reevaluated and dynamically make decisions depending on system goals. You avoid those boneheads chockful of years of experience who insist "always use vendor XYZ, they are the best", even when they are NOT the best. One big reason they want you to use vendor XYZ, they are too lazy to figure out how to use the better vendor's product, or simply put, learn as such a ridiculously slow rate, you would not want to wait for them to get up to speed on that product. Give me a break, some products, to get them to do basic features are very general and sheesh, what else are manuals/documentation for. While people balk at those who have to "read the manual", somehow I trust them a lot more than the "monster keyboard masher" or wait no... the "monster mouse clicker" who keeps saying "Try again now!" or.. like the Verizon commercial "Can you ping me now?... good!" With obvious exceptions, you configure one firewall you have done them all, you configure one router you have configured them all, you configure one vpn concentrator, you have configured them all, you READ a network sniffer's output, you can use any network sniffer. All of this assuming the vendor has ... some level of documentation that is remotely comprehensible. :) Basically after doing at least one of them very well and knowing the theory of operation behind it, you have a very good shot of learning the other vendor's version of it. A lot better than HR people give credit for. "Oooh you did Cisco VPN solutions, but you never touched a Netscreen, no way you can know how to work the Netscreen then." Gosh this sure sounds like the "Oh... you have 15 years of experience in C, well we were looking for the pure Java head". Sometimes the C guy might be better (experience in large projects), sometimes he might not (turns out he's very bullheaded and insists on using some monolithic design). When a new feature changes, Mr. Monster Masher with loads of experience doing the Monster Mash and relying on his screen shots of previous configs fails to see the new ERRATA that says "XYZ changed in what not" all because he did not read the manual. We all know reading the manual means you are "inexperienced", right? (sarcasm) > >advisors to review, yes, it would be better. But as Howard pointed > >out, this is too slow... and I am sure even you would agree it would > >be great but WAY too slow and expensive for Cisco, who clearly wants > >to see their CCIE count grow... just like the rest of the major > >vendors. > > I think, however, it's worth exploring how some of these things could > be scaled. One-right-answer CCIE labs aren't the best way. I think > there's significant benefit from spending some time with a true IOS > simulator -- NETSYS, BONES, etc. -- something that lets you > demonstrate you can make a system of tens or hundreds of routers work. > > Cisco, I believe, really needs to soul-search if knowing every > obscure knob is really useful. When I do complex network design, I > decide what I want to accomplish -- often that's more from reading of > RFCs, professional group participation, etc. -- and THEN look up the > commands. Most of the "busy body" corporations tend to care more about the "now" and the "instant command" gratification. "ooh ooh he can make it better". There is a very nasty stigma that "design is easy, but who cares, can he make it work?" Personally I am a bigger fan of a solid design, and so are quite a few of the more exceptional companies, and obviously the research field. Unfortunately, I think the market plays down the very area we care for, and because of that it is not marketable for Cisco to push that angle. Furthermore, one could easily argue that the design aspect, unless carefully monitored, would be even easier to "copy" than the labs now. "Oh I just happened to like that design layout... " "Really? The last 50 individuals all did it the same way too hmmmmmm... and it's wrong." :) -Carroll Kong Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71626&t=71143 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
