🚀 go-pugleaf

In article <1271@accuvax.nwu.edu> travis@delta.eecs.nwu.edu (Travis Marlatte) writes:
>
>Why does the idea of an apprentice not spring to mind quickly?

Travis has a good point here.  The analogy to a wizard's apprentice is even
better.  How do you become a wizard?  By studying with/for a wizard.
(or rather, what is the BEST way)

We must also cultivate a love of the craft.  This is the real difference
between being bored (in any position) and being happy with the workload.

Many really good programmers do it because they couldn't think of doing
anything else.  "Give me a workstation and a place to sit, and I'm happy." is
a common attitude among the wizards I have known.  The specific task, whether
it be maintainance or design, is seldom mentioned.  But rather, the usuall
conversations amongst these people lean towards new constructs, difficult
passages, tools, the latest and greatest hardware, etc. etc.

+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Honesty is in the eye of      |  Phil Meyer                               |
|   the creditor.               |  Usenet: <backbone>!attctc!lodestar!phil  |
|                               |  VoiceNet: (214) 991-0897                 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+

travis@delta.eecs.nwu.edu (Travis Marlatte) writes:

>I don't see the reasoning that novice programmers should be given the
>task of maintaining existing systems. I also don't see the reasoning that
>thou who creates it will maintain it even unto ball and chain.

This seems awfully absolute.  I didn't hear anyone make either of these
statements as absolutes.  In fact, as regards the second statement, it
was specifically mentioned as an option.  There are MANY people who find
the option to have responsibility for and commitment to a project from
"womb to tomb" VERY attractive.  There are others (myself included) who
like to do a certain amount of work on a project and then move on to some-
thing else.  The threshhold varies, but the desire tends to be one for
change and variety.

>Simple analogy: A team of crack engineers build a beautiful and structurally
>sound bridge that serves its purpose well. Five years after construction,
>it is learned that the foundation at one end is giving way due to water
>damage. The company assigns its newest employee to the task of designing
>the correction to the problem.

I notice that Travis said "newest employee", not "novice engineer" or
"recent graduate."

>Sounds absurd to me! I would hope it sounds absurd to the rest of you too.
>Isn't the analogy correct. Why would I want to assign inexperienced staff
>to the task of shoring up existing systems? Especially, since we know that
>mainenance is often a task of stretching the intent of the original design
>to meet current expectations. Further, why would I want my newest employee
>dedicated to mastering 5 year old technology?

Sounds absurd to me too.  No one said that was the idea.  The idea is that
through working on fixing bugs (maybe major, maybe not), a new employee
(not necessarily junior, however!!!!) can learn the systems, the techniques,
and the standards and approach used by his/her new employer.  While we
tend to think of YOUNGER employees when we think of NEWER employees, this
is CLEARLY not the case.  When you change jobs, do you expect to walk into
your new job and immediately start designing their hottest project?  While
it does happen, it is the exception rather than the rule.  New employees
have to learn their way around; socially, organizationally, and
professionally.  In our profession, this is frequently accomplished by
putting the employee to work on low- to medium-priority maintenance
tasks.

> [ lots of interesting stuff about apprenticeship approaches ]

I agree that apprenticeship is a terrific way to progress.  Once again,
I must point out that NEW employee does not translate to RECENT GRADUATE
or YOUNG.  Put the issue in perspective.

>By the way, my first job out of school was as a maintenance programmer
>for control systems. I didn't mind doing it but it certainly was a waste
>of time. Only by becoming involved in curent design effort does one come
>to understand the task of doing current design.

"A waste of time."  Does this let everyone know what Travis thinks of
maintenance and programmers who DO maintenance?  Obviously what is
important and interesting to Travis is design and being in on the
ground floor of a project.  While that's true of many of us, we also
learn to appreciate the time we get to work on maintenance.  It can
be a wonderful break from the pressure and pace of being at the front
end.  Like doing gardening or cooking or folding laundry.  Like doing
manual labor after programming all day.  Change.

Nurture versatility and an appreciation for ALL aspects of your
profession, and you will BE a professional.
-- 
 +----------------------------------------------------------------------------+
 :                Steven List @ Transact Software, Inc. :^>~                  :
 :           Chairman, Unify User Group of Northern California                :
 :     {apple,coherent,limbo,mips,pyramid,ubvax}!itkin@guinan.Transact.COM    :

The discussion was kind of heading in the direction of using maintenance
as a training vehicle for new engineers. I think most of us agree that
this is wrong. Exposure only to maintenance is probably not the
way to bring a new programmer up to speed for design.

Whoops. There I said it again. The goal is create good designers. Somehow,
to be a good programmer, I believe one has to become a good designer. Even
in maintenance, and we all know I think that job is scum, good design
techniques are paramount to making sound revisions - whether defect fixes
or enhancements.

Contrary to my sarchastic comment above, I love maintenance. I have always
been one to enjoy tearing something apart, figuring out how it works, and
how to make it work better. I would think that most engineers have this
same attitude.

I do think that maintenance as a training vehicle is a waste of time. The
trainee learns nothing except how stupid past developers were. The company
may benefit from freeing up its more highly prized programmers but there
certainly is a cost of poorly done maintenance.

Actually, maintenance is an important part of new design as well. I can't
count how much time I've saved by striping a piece of code from a past
product and using it in a new design. Gosh - reusable software.

To reiterate my position - apprenticeships or something similar seem
like a pretty clean way of approaching training. Note that this does
address the new employee whether novice or experienced. Some formal program
to help the experienced programmer fit in with the company is just as
appropriate as a formal program to bring the novice up to speed.

A few comments on licensing: (are you out there Ms. Richards?) Licensing
does not prove competence or ability. It merely transfers liability. And
that usually doesn't work either. Licensing should mean nothing to a fellow
programmer (or engineer). It is only a stamp of approval from a publicly
recognized body and it is for the benefit of the public.

Licensing can only be used as a first defense against blithering idiots
passing themselves off as professional programmers. I am quite confident
that the programmers responsible for recent widely publicized software
failures were nothing but professionals and would have gained a license
if such were required.

Travis