NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9419

Internet Message Format | 1992-09-14 | 4.0 KB

Xref: sparky comp.arch:9419 comp.lang.misc:3074
Path: sparky!uunet!munnari.oz.au!goanna!ok
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: "Training" of programmers
Message-ID: <[e-mail]>
Date: 15 Sep 92 00:19:49 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Followup-To: comp.lang.misc
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 58

In article <[e-mail]>, [e-mail] (Daavid Turnbull) writes:
> To me software engineering is a little like driving a car.  You get to square
> one by reading the manual or taking some lessons, getting a mate to show you
> etc.  The real learning however takes place once you hit the road on your
> own... and god heap anyone who gets in your way during the first couple of
                 help?
> months.  For motoring the statics show that experience counts heaps.. seven
                            statistics?
> years down the track/ 25yo you are much cheaper to insure for example.
> This does not necessarily mean that you are a good driver however... all
> it means is that you consistantly meet the bottom line.  What is rarely
                       consistently?
> taught are the clever driving skills that can only be learnt after you
> know how to drive.

A spelling flame is appropriate here, because one of the _major_
software skills that people need is the ability to proof-read.  (And in
areas where they are weak, good software engineers use such automatic
tools as are available.)  Indeed, critical reasoning in general is
important for software engineering, which is why I think it appropriate
to explain that the analogy is bogus.  The insurance companies _are_ to
some extent interested in how much experience you have had.  In Victoria
the key question is whether you have an "L" (learner), "P" (probationary),
or full licence.  That doesn't measure your driving _experience_, just
how long since you first applied for your licence.  You can graduate
from "P" to full (and from one insurance risk category to another)
without as much as touching a car in the intervening time.  What they
are _mainly_ interested in is age for its own sake.  The simple fact is
that newly adult males are at high risk for just about everything.  The
25 year mark has nothing to do with whether you "consistently meet the
bottom line", and everything to do with whether you are _likely_ to
behave responsibly.  If driving skill is the major factor, why don't the
insurance companies have their own driving tests.

I put it to the net that a similar question does apply to software and
hardware design.  Is so-and-so able to criticise his/her own work?
Is so-and-so willing to let others criticise it, or is s/he defensive?
Is so-and-so, in Dijkstra's phrase, a Humble Programmer?

> In software skills that seem not to be taught (at least effectively) to
> undergraduates are those that make code happen, eg: knowing when to stop
                                                  e.g.?
> thinking about the task and start coding; when to throw away bad code
> and start again, when to assume that a frequently hit section of code is
> as efficient as it can get, etc. (IMHO almost never, frequently and never)
> These skills may only be learnable well down the track, after the mechanics
> have become second nature and the real task can be understood for what it is.

Hmm.  I teach my students _never_ to "assume" that code is efficient,
but to _measure_ it.  I also teach them never to assume that a particular
section is frequently hit, but to analyse if they can, and measure, measure,
measure.  A mathematical analysis might apply to the code you _meant_ to
write, not the code you _did_ write, and a discrepancy may be the sign of a
mistake.  Whether they _learn_ what I teach is another matter.  There's a
lot of "if it won't be in the final exam I don't want to hear about it" around.

--
You can lie with statistics ... but not to a statistician.