TITLE: Professors Who Code
AUTHOR: Eugene Wallingford
DATE: September 18, 2006  6:03 PM
DESC: 
-----
BODY:
Steve Yegge's
<A HREF="http://steve-yegge.blogspot.com/2006/07/wizard-school.html">
   entertaining fantasy on developing programmers</A>
contains a respectful but pointed critique of the relevance
of a Ph.D. in computer science to contemporary software
development, including:

<BLOCKQUOTE><EM>
You hire a Ph.D., it's hit-or-miss.  Some of them are brilliant.
But then some subset of virtually every educated group is brilliant.
The problem is that the notion of a Ph.D. has gradually been watered
down for the last century.  It used to mean something to be a Doctor
of Philosophy: it meant you had materially advanced your discipline
for <EM>everyone</EM>.  Von Neumann, Nash, Turing -- people like
that, with world-changing dissertations, ....

...  These kids have to work hard for their Ph.D., and a lot of them
never quite finish.  But too often they finish without having written
more than a few hundred lines of code in the past five years.  Or
they've over-specialized to the point where they now think Big-O is
a tire company; they have no idea how computers or computation actually
work anymore.  They can tell you just about everything there is to
know about SVM kernels and neural-net back propagation, or about
photorealistic radiosity algorithms that make your apartment look
fake by comparison.  But if you want a website thrown together, or
a scalable service written, or for that matter a graphics or
machine-learning system, you're usually better off hiring a
high-school kid, because the kid might actually know how to program.
Some Ph.D.s can, but how many of them is it, really?  From an
industry perspective, an alarming number of them are no-ops.
</EM></BLOCKQUOTE>

Ouch.  I'm sure Steve is exaggerating for dramatic effect, but
there is a kernel of truth in there.  People who study for a
Ph.D. in computer science are often optimizing on skills that
are not central to the industrial experience of building software.
Even those who work on software tend to focus on a narrow slice
of some problem, which means not studying broadly in all of
the elements of modern software development.

So, if you want to apprentice with <STRONG>one</STRONG> person
in an effort to learn the software industry, you can often
find a better "master" than by selecting randomly among the
run-of-the-mill CS professors at your university.  But then,
where will you connect with this person, and how will you
convince him or her to carry you while you slog through
learning the basics?  Maybe when Wizard Schools are up and
running everywhere, and the Ward Cunninghams and Ralph Johnsons
of the world are their faculty, you'll have a shot.  Until
then, a CS education is still the most widely available and
trustworthy path to mastery of software development available.

You will, of course, have to take your destiny into your own
hands by seeking opportunities to learn and master as many
different skills as you can along the way.  Steve Yegge reminds
his readers of this all the time.

In this regard, I was fortunate in my graduate studies to work
on AI, in particular intelligent systems.  You might not think
highly of the work done by the many, many AI students of the
1980s.  Paul Graham had this to say in a
<A HREF="http://www.paulgraham.com/copy.html">
   recent essay</A>:

<BLOCKQUOTE><EM>
In grad school I was still wasting time imitating the wrong
things.  There was then a fashionable type of program called
an expert system, at the core of which was something called
an inference engine.  I looked at what these things did and
thought "I could write that in a thousand lines of code."
And yet eminent professors were writing books about them,
and startups were selling them for a year's salary a copy.
What an opportunity, I thought; these impressive things seem
easy to me; I must be pretty sharp.  Wrong.  It was simply a
fad.
</EM></BLOCKQUOTE>

But whatever else you say, you have to admit that most of us
AI weenies produced a lot of code.  The AI and KBS research
groups at most schools I knew sported the longest average
time-to-graduate of all the CS areas, in large part because
we had to write huge systems, including a lot of infrastructure
that was needed in order to do the highly-specialized whatever
we were doing.  And many of us wrote our code in one of those
"super-succinct 'folding languages'" developed by academics,
like Lisp.  I had the great good fortune of schlocking a
non-trivial amount of code in both Lisp and Smalltalk.  I
should send my advisor a thank-you note, but at the time we
felt the burden of all the code we had to produce to get to
the place where we could test our cool ideas.

I do agree with Yegge that progressive CS departments need
to work on how better to prepare CS graduates and other
students to participate in the development of software.
But we also have to wrestle with the differences between
computer science and software development, because we need
to educate students in both areas.  It's good to know that
at least a few of the CS professors know how to build software.
Not very many of us know when to set the fourth preference
on the third tab of the latest .NET development wizard, but
we do have some idea about what it's like to build a large
software system and how students might develop the right
set of skills to do the same.
-----