Re: Perl Apprenticeship Program

On Mon, 04 Dec 2000, Steve Fink wrote:
> One comment -- an apprenticeship is a two-sided relationship. Bryan, I 
> think you've done a great job of describing the apprentice's 
> responsibility to the master. But what about the master's responsibility 
> to the apprentice? The apprentice is entering into the relationship with 
> the intention of getting experience and skills out of it. I think you 
> should loosely describe what a master is expected to do to facilitate 
> the apprentice's progress in exchange for the grunt work. Just so a 
> master can know whether he's being a good master, if nothing else.
> 

And if I were a master at anything, perhaps I'd be able to.  ;-)

In truth, I *do* have a hard time describing how anyone on the mentoring side
can do their job better.  Having been both a trainee and a trainer in a wide
variety of fields, the only observation I can state for sure is that every
student-teacher relationship is different, and the true masters are those
that find their own way to tailor that relationship.

But you did say "loosely" describe, so here's a couple of key principles.

Be unselfish.  Masters need to be able to increasingly delegate work to those
ramping up. It can easily get frustrating to see someone taking a couple days
what you could easily do in a good two hour session.  Spend that extra time
reviewing what some other apprentice has done.

Be willing.   Sponsor an apprentice.  In most cases, it will be easier to
pull from a general pool, and at the beginning, this is expected.  (It will
allow everyone to get a general feel of everyone else, and allow for "natural
selection.")  If you find someone that matches or complements, your style and
interests, you have a partner in the making.  Better yet, take on two or
three.  Allow them to tag team on projects - learning and helping each other,
as well as you.

Be available.  Don't give a task, then disappear until its due, accept it,
then disappear again.  Answer questions.  Check the work.  Give feedback.

Be realistic.  If you don't have the time to invest, don't do it.  If your
apprentice doesn't know diddly about VMS, doesn't have access to VMS, doesn't
know how to spell VMS, then don't expect his or her code or comments to be
VMS-aware.  If your apprentice doesn't have clue one about anything, let him
know, and point them to what they need to work on, and where they need to be
to get back in the game.  If something needs to be done *now*, make sure it
gets done now, even if you have to do it yourself.

Be prepared.  You're going to be asked some pretty stupid questions,
particularly since blood-and-guts programming has been becoming a lost art
of late.  Bite your tongue and move along, don't judge until the questions
are too many too often.

Be yourself.  If you're harsh and abrasive, it's better for you to be harsh
and abrasive and send your helpers home crying every night than to try to be
anything else.  Most of the best help I've gotten from the p5p, Perl 6 *, and
Perl TK lists have been from people who probably didn't even know they were
helping me.

Too tired to come up with any more.  Most any book on leadership,
is a good place to start.  I don't have any real recommendations for the
reading list, mainly because my references aren't relegated to just
leadership, or aren't available to the general public.  But, if you're a
military buff, for whatever reason, here's two that I rely on: "Guidebook For
Marines", (0-940328-07-0), and "Handbook for Marine NCOs" (0-87021-254-0). 
The latter is out of print.  I also have, but have not finished, David
Freedman's "Corps Business: The 30 Management Principles of the U.S. Marines"
(0-06-661978-5).  Anyone care to guess what service I was in?  :-)

> You skipped journeyman. :-)

Uh-oh.  Now everyone will know I didn't pay my union dues.

-- 
Bryan C. Warnock
bwarnock@(gtemail.net|capita.com)