Comments: on Leadership - tech teams and the RTFM factor

The problem is actually that people ask the wrong question. They tend to ask, "How do I do xxxx?" when they really need to ask "Where can I learn to do xxxx?". Usually someone shouts RTFM when the answer is something that a simple google search could answer so people tend to get annoyed by people not doing basic research. I don't mind helping people learn. What I do mind is people wanting to be spoonfed.

Posted by Wofl at June 28, 2006 03:27 PM

I've been re-reading "Agile Software Development" by Alistair Cockburn and two relevant things from this book stick out.

1. As a programmer gains experience in a domain he/she moves through three levels of understanding. The first is where the only things done are by rote, the second is where some experiments are undertaken and variations are understood, the third is where variations are almost invisible and the most appropriate variation appears without any real mental energy being expended.

2. People that work together or who come from very similar backgrounds/subcultures form their own private languages that allow them to communicate in a kind of shorthand.

I suppose that these two effects make it appear to a level three expert in systems programming that someone asking a question using the wrong terminology and seeking a level one answer is somewhat below par and simply not making sense. Level three people find it very difficult to give level one answers. It takes awareness that the different levels of comprehension exist and and then there is the problem of forcing oneself to operate at such a naive/literal level.

Hard stuff. I'm looking forward to the rest of the series.

Posted by Michael at July 3, 2006 06:26 AM

this is a slightly different issue ... it is a lot easier to answer the question when it is a level 1 question ... when a level 1 person asks about some level 3 issue ... the person asking the question frequently doesn't have the context to understand any answer. i've periodically used the analogy of a five year old asking a question about some issue involving graduate school mathematics or physics.

there is also issue of whether they are trained professionals or somebody that has no professional experience or training in the area. a side issue is a lot of system programming being much more like a craft than a science (need long years of guild apprenticeship)

periodically when you attempt to gracefully explain to a grown person that they lack the context to understand the answer ... you get a response that claims their lack of understanding is because you aren't capable of explaining the answer (its your fault not their fault).

slightly related, in various usenet news groups there is sporadic antagonism ... not so much about the level 1 questions ... but when the questions appear to be blatent homework. in comp.arch (computer architecture) there use to be some correlation with homework questions and the start of a semester (entering freshman having their 1st exposure to online computing) ... but now it seems to be randomly distributed year around.

and of course, one of the ultimate authorities on "agile" was boyd

Posted by Lynn Wheeler at July 3, 2006 11:16 AM

Which raises an interesting question. If there is a vast difference between level 1 and level 3 expertises, and I don't suppose that is so controversial, then why is it that in computing sciences in general, this isn't well understood and isn't well accepted? Not a day goes past when I come up against someone with a month's experience in Ruby or REST or Ajax or something equally current and hot, and find that this encourages them to assume and demand equality in knowledge. It seems like it is almost the opening gambit: "I'm hot in this month's flavour, if you're not, you already missed the boat, you're so past it, dude!"

At first blush, the notion that the young turks can put together fast hard apps with these tools is great, and does deserve the credit. But there are too few examples of success from what I've seen to make that a reliable guide. For the most part, these great tools are 99% bluster; after the hype has become boring, the hard work is still left to do.

At second blush, it might be a reflection of silver bullets. The old arts tended to solve this with a guild or professional structure approach. But that hasn't worked for computing for various reasons.

Posted by Iang (The Market for Silver Bullets) at July 3, 2006 01:53 PM

to some extent guilds persisted over long period of time in relatively stable (stagnic) environments.

in rapidly changing and expanding domain ... a 20 year (or even five year) apprenticeship may leave you with a lot of obsolete skills.

some number of the tools, SDKs and development environments from the 90s ... especially object-oriented stuff ... where heavily laced with GUI capabilities that allowed toy demos to be turned out quickly and cheaply ... but rarely had any significant support for hard-core industrial strength data processing (and there frequently was a large gap between the toy demos and real deployable operations ... other than using the toy demos for entertainment situations akin to games).

one example was the taligent stuff ... we had done a one week JAD (with dozen people from taligent) look and came up with a 30 percent hit to existing taligent base plus 30 percent new code ... in order to add any appreciable support for industrial strength data processing.

finally, in a rapidly changing and expanding domain ... the demand for "experts" can far exceed the supply ... and so many have to make do with what they can get.

this can lead to chicken and egg situation ... if the demand for experts far exceeds the supply, vendors will frequently try to adapt their products to the skill level that is available ... trying to make do w/o requiring real experts.

Posted by Lynn Wheeler at July 3, 2006 03:34 PM
Post a comment

Remember personal info?

Hit Preview to see your comment.
MT::App::Comments=HASH(0x561c7af5dc50) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/ line 125.