At 11:19 AM -0400 6/29/03, Carroll Kong wrote:
> > 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.
let's put it this way...there are ways of correlating medical
laboratory tests that I worked out on my own. Indeed, when I was
about 16, I came up with a hypothesis independently (but triggered by
an aside in a paper on something else) that;
(1) it would be clinically useful to be able to give penicillin along
with something that protected it from penicillinase, a bacterial
enzyme that destroys it and is one mechanism of resistance.
(2) there existed at least one compound, which really hadn't been
investigated, that could inhibit penicillinase.
When I entered college, I did get permission to do this as
independent research, but it didn't go very far for many reasons. The
big one is that I wasn't economically or emotionally ready for
college. Second, I had no real budget for the project, and my
"basement biological warfare lab" (well, it was for a fungus, not a
bacterium, but in principle could have grown anthrax) was just too
improvised -- I lost about 2 out of three batches due to
contamination in the air supply. Third, while I actually understood
the theory of some of the measurements I wanted to take, I didn't
have the hands-on skill to use some of the instruments. (Again a
.well... I'm now ok with using a dual beam UV spectrophotometer,
but I still can't do RJ45 crimps worth anything0.
But in the current case of monitoring potential infection, I learned
that from a particular physician -- I've never seen it in a textbook.
What I'd say is that a bright med student will work out some
techniques, but there are a very wide range of unwritten methods that
are best learned by mentoring. Learning to take blood from a vein is
a reasonable example -- oh, it's written up well, but there's no way
I know to learn the feeling of the "two pops" -- once when you get
through the outermost skin, and once when you enter the vein. It
takes constant practice to remain competent at this -- I could still
probably draw blood from you, but it wouldn't have been fun for
either of us.
>
>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. :)
Hahh...Doogie had MUCH better social skills.
>
>> 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.
The variant I see a lot...and probably led to a fair number of dot
com failures...is when some bright people would build a proof of
concept on a LAN-based system, maybe with broadcast-based NetBIOS
name resolution, and get funding from venture capitalists.
Unfortunately, the dumber VCs would demand the conceptual system get
put into revenue operation right away, rather first doing a review
and tuning to make it work appropriately over a WAN.
>
>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!
>
>
> >
>> 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?"
One of my cats, Ding, seems to worry about that a lot. Sometimes I'm
convinced the thoughts are really profound, sometimes they are on the
level of "why is air? (Bill Cosby reference)," and other times "I
have misplaced my tail and this upsets me."
"Ding, look over your shoulder (or, in more complex cases, when he's
tangled in a ball washing himself and can't remember where he put his
tail.)." My late and dear feline friend Clifford, however, generally
believed there was a hot standby processor in his tail, and there
were occasionally race conditions when the main processor and tail
processor disagreed about the routing table.
>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.
>
>> >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." :) ways>
It's pretty trivial to be able to auto-generate small but important
changes in design scenarios. I even have a test engine that for
adaptive administration of lab secenarios.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=71675&t=71143
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
