From: daavid@bohra.cpg.oz.au (Daavid Turnbull)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: "Training" of programmers
Date: 8 Sep 92 13:43:51 GMT
Organization: Computer Power Software

In article <Bu5qD3.GAM@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> In article <1992Sep4.151001.9886@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>>In article <Btx4vF.Jx6@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>>>What is relevant is
>>>the translating of the problem to be computed into the collection of bits
>>>which the machine can understand to accomplish the task.  This involves
>
>>>	Knowing the algorithmic processes which can be applied, their
>>>	strengths and weaknesses, and what happens to them on the particular
>>>	machine when they are translated using the available languages.
In my view this can be learned far more effectively in the real world...
... but I get ahead of myself.

>
>>Now, these people were not fools - they were PhD's in computer science
...
>>the most grotesquely inefficient way imaginable, with a design one would
>>expect a developmentally-challenged tree sloth to be able to pick to
>>pieces in ten seconds?
>
...
>>"isomorphic" over morning coffee.  And, in all that time, they had never
>>been taught to visualise *what really happens when real code runs on
>>real machines*.
>
...
> in proving that the traveling salesman problem is NP-complete, but it gets
> nowhere in implementing code to run in a reasonable length of time.
>
... etc etc.

I missed out on the computer science undergraduate thing. I now describe
myself as a "Software Engineer", and believe myself to be reasonably
competent to boot.  I have a couple of degree's in psychology but have
had no formal training in software engineering.

Having learnt my computing via books and hands on experience etc I have often
felt that there may be gaps in my understanding and considered returning to
studies but I am now of the opinion that this would be of little benifit.

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
months.  For motoring the statics show that experience counts heaps.. seven
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
taught are the clever driving skills that can only be learnt after you
know how to drive.

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
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.

Does it matter how you pick up the mechanical part, book, peer or guru, if
the software industry is to become of age we need to find effective methods
to teach/learn the second wave of skills that are the means to producing
excellent code first time around.  In my observation these skills are
not picked up by those passing through the establishment teaching environments.
Perhaps by definition they never can be.  What may be required to be taught
is learning skills sufficient to ensure that the individual knows that at
the end of whatever course he/she knows nothing!

My 2.5 cents worth - daavid
-- 
	Daavid Turnbull
	daavid@bohra.cpg.oz   +61 3 823 0222    (fax) +61 3 824 8068
	uunet!munnari!bohra.cpg.oz!daavid
	CP Software Export Pty Ltd                   ACN 006 640 133
Xref: sparky comp.arch:9387 comp.lang.misc:3050