[So far I haven't been accused of a surfeit of hubris, so here's some more
grist for the mill. Though I may dial the grist back a bit if it generates
an excess of flammage. This and my previous posts are archived on my web
site.]
Clarity is the secret weapon of the beginner. To learn a new subject
quickly, learn to talk about it the way the experts do. Use the same terms
they do; if they appear to be splitting hairs, look closer, because the
distinction is likely to be important. (Insert the old saw about Eskimos
and words for snow.) For instance, although they appear similar, lists and
arrays are very different entities in Perl; be fanatical about using the
appropriate term for the one you're referring to. Likewise, people today
talk about "hashes"; they gave up on the term "associative arrays" many
years ago.
One reason for this is to help mark out the new paths in your brain faster;
picture a herd of cows being led across a corn field. If they're all led
along the same path, that path will be very clearly marked and the next
herd to come along will have no trouble telling which way it should go. If
the cows are allowed to roam ("What's the difference? Y'all know what I'm
talking about, right?") then there will be a maze of ill-defined paths left
behind and the next herd will be confused. You'll learn what you need to
know faster by being rigorous about how you talk about it.
Paradoxically, beginners often expend far more effort than they should in
trying to communicate about some problem. Think of the experts reading
your posts as an army of Mr. Spocks; they're capable of answering anything
as long as they're fed accurate data. Data, not assumptions. It's not
necessary to guess at what might be going on; it's not necessary to apply
any amount of imperfect knowledge. All they need are the facts: what did
you do, what happened, what were you expecting to happen? An ounce of
visibility into what you're doing beats a ton of unverifiable speculation.
Remember, the experts can't read your mind or look over your shoulder to
see what you see. If you got an error, at the very least, they need to see
the line of code that generated it; often, this isn't the line you might
think it is, and they'd be better off with the whole script. In which
case, the shorter it is, the better. You'd be surprised how often you'll
figure out the problem yourself on the way to coming up with a brief example.
Watch out for ambiguities and missing information in your requests. An
excellent way of training yourself to spot them and deal with them is in
what NeuroLinguistic Programming (NLP) calls the Meta Model; see
explanations at, e.g.,
http://ourworld.compuserve.com/homepages/PatrickM/metamod.htm (found
through a search, no affiliation). One way to test your communication
skill is a game to play with another person; pick a complex diagram that
they haven't seen, and using only words, describe it well enough for them
to draw a reproduction. (You can see the application of this principle in
the HBO miniseries _From The Earth To The Moon_ when the Apollo 17 crew are
trained to report their geological observations to Earth.)
Cut and paste is the easiest way to ensure accuracy and requires virtually
no thought. On the way, there's a good chance you'll catch "obvious"
mistakes that you'd be embarrassed to air in public, just by virtue of
doing this vicarious demonstration, as it were.
