Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bloom-beacon!mit-eddie!apollo!perry
From: perry@apollo.COM (Jim Perry)
Newsgroups: comp.software-eng
Subject: Re: software engineers
Message-ID: <42fba1e1.183dc@apollo.COM>
Date: 2 May 89 15:42:00 GMT
References: <854@odyssey.ATT.COM>
Reply-To: perry@apollo.COM (Jim Perry)
Organization: Apollo Computer, Chelmsford, MA
Lines: 64

In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes:
>
>Real programmers spend 90% of their time debugging.  Computer science
>curricula ignore debugging, perhaps because it can never be reduced
>to a theory.  But debugging skills are what I would look for *first.*
>(By the way, I am using "software engineer" as synonymous with "programmer."
>Separating design from implementation is usually a mistake; ask the DoD.)

Unfortunately I believe real debugging skills can only acquired with
experience.  You can teach techniques for writing relatively bug-free
code, the hard part is when you have to debug someone else's code (or 
spec/interface, whatever).  I generally have confidence that my code
will do what I intend, but can still have a good time tracking down a
subtle bug in the compiler or OS.  There's a leap of faith in believing
that compilers *have* bugs, the sad realization that most "compiler bugs"
aren't, and finally the ability to track down the real ones.

>Other skills I would look for:
>
>2. The ability to "port" software.  This is an acid test for distinguishing
>   able programmers from mere C.S. grads.

A lot of this could and should be taught, in the hypothetical S.E. curriculum.

>3. The ability to maintain somebody else's code.  Most C.S. students have
>   no experience in this.

And the flip side, the ability to write code that can be maintained by
somebody else with a minimum of difficulty.  There's a trade-off here, in
that a programmer in an environment where high standards of maintainability
are followed can be at a loss when presented with a more real-world poorly
documented program, while a programmer very adept at maintaining bare-
bones code may not appreciate the value of the additional work involved
in (structuring, documenting, modularizing) code.
>
>4. The ability to work from specifications.  This includes getting them
>   changed when they need it, and filling gaps by making inquiries or
>   using your own judgment.
>
>5. The ability to write software with clean, convenient user interfaces.
>   A good programmer can "see" his software from the user's viewpoint
>   and write for the user's benefit.
>
>6. The ability to write adequate user documentation.  See 4.

Where "user" under 5 and 6 refers not just to an end user of an application
but also clients of libraries, etc.  

>7. Experience with a variety of languages, environments, and methods.
>   Not that this experience will necessarily prove useful, but it shows
>   that the programmer is versatile, and probably understands some of
>   the underlying principles of software environments.  By the same token,
>   beware of dogmatism; a programmer with an antipathy to Pascal, COBOL,
>   or VAX/VMS may have a stiff neck.  A programmer who stops learning
>   is technologically obsolete.

AMEN.

(I have more follow-up material on this but it's getting long so I'll
post it separately).
-- 
Jim Perry   perry@apollo.com    Apollo Computer, Chelmsford MA
This particularly rapid unintelligible patter isn't generally heard
and if it is it doesn't matter.