TITLE: Professors Who Code AUTHOR: Eugene Wallingford DATE: September 18, 2006 6:03 PM DESC: ----- BODY: Steve Yegge's entertaining fantasy on developing programmers contains a respectful but pointed critique of the relevance of a Ph.D. in computer science to contemporary software development, including:
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 everyone. 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.
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 one 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 recent essay:
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.
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. -----