I would say this article is discussing two separate problems: (1) the gulf between research and practical software development, and (2) low-quality C.S. graduates.
IMHO, the first is not really a problem, or at least not a big one. Part of the way a field advances is that researchers are free to try out any old idea, to see if it is any good. Most of them aren't, but we don't know which are worthwhile until we try them out. So it helps that researchers are disconnected from the process of making salable products. "Make something that sells in two months" is not a good way to get people to try out interesting new ideas.
The result is a slow filtering of ideas from research into practice. Occasionally, a university researcher comes up with something that the programmer on the street can immediately pop into a product (RSA encryption, bump mapping, Introsort, ...) but this is not the norm; nor, I think, should we expect it to be.
The second problem (low-quality C.S. graduates) is more serious. The writer's suggestions are not particularly new; they amount to putting more of what is often called "software engineering" into the C.S. curriculum. And part of the problem there is that it is difficult to do large projects in a university course setting. When you don't do large projects, all that stuff (teams, complexity management, ...) is not really needed. So, while this second problem is worth pointing out, I don't think there are going to be any quick fixes for it.
Much can be learned by looking at other fields which do complex "design based" work and are much older than Computer Science. In particular the various other engineering disciplines and the discipline of architecture. In these fields you go to school to get a broad-based exposure to the various facets of the field, learn the critical mathematics and language used in the field, get some in-depth information about some slices of the field which particularly interest you, and do some simulation of "real world" design work which involves the creative aspects, teamwork, etc.
When you come out of these programs you're neither an "Engineer" nor are you an "Architect" and using those titles next to your name is actually illegal. There is no expectation that the academic training produce a finished professional.
You then continue on another multi-year process of test-taking and working as an apprentice. Of learning the actual real world facets of the field. Facets which involve management, teamwork, business, people, design, how to deal with long, complex projects, scheduling, budgeting, etc. In short all the boring details which separate the dilettante from the professional.
Finally after you complete your state-mandated term as an apprentice you take some tests, submit a portfolio of your work to the government and assuming you are actually good enough you get your stamp, can use your title, and basically be counted on to do a professional job.
This system while cumbersome actually has a proven track record of working and producing capable professionals. Buildings often actually get built on time and budget and they rarely fall down onto people.
Definitely agree with apprenticeship. I've learned more through a couple hours of pair programming with an experienced coder than I did at the university.
This isn't to say university is bad. Data structures, algorithms, etc.. should all come at an instructional level, but good design practices definitely come from coders.
As a side note, is there any sort of organized apprenticeship program, or are we dependent on introductory training at a job/Open Source level?
The FreeBSD project has an institutionalized mentor program. So before/when you are raised from just an occasional contributor (someone sending in occasional patches) to a commiter (someone with commit access) you are given a mentor, who teaches you the culture/process/methods to commit changes.
Not quite as good as a apprentice/mentor day-in day-out but it is supposed to work pretty well.
Definitely. It's not too hard to teach a smart but inexperienced employee things like how to use source control, automated testing, multiple language paradigms, and "why deadlines are important".
In my opinion, a university education should only be about intellectual curiosity with the greatest research minds. If you are only interested in the practical aspects of programming, I don't think that a university fits your needs.
To extend this thought, I also believe that someone majoring in any field--from English to art history--should be able to become professional programmers. I feel that industry is trying to make universities technical schools, when they have an academic focus.
That is not to say that I don't agree with some of the previous posters. We do need more training centers for people with practical inclinations.
I feel that the problem with this whole system is that people are automatically expected to go to university if they did well in high school. If not they will violate a social norm, and shame their parents. There should be practical schooling options for students that are also hard and prestigious.
In my opinion, a university education should only be about intellectual curiosity with the greatest research minds. If you are only interested in the practical aspects of programming, I don't think that a university fits your needs.
I agree with this. I've been working as a programmer for a couple of years now and I'm planning to go to university to study computer science. I'm kind of annoyed that all of the universities I've looked at are all business now: the brochures are full of how students won't "miss out" on the practical, real-world side of things.
That's exactly what I'm not looking for, but unfortunately there doesn't seem to be any place to go if all you want is computer science.
I don't understand how the contrast -- using category theory to derive notions of computation and something attempting to patch up Perl's object system -- relates to the rest of the essay.
I don't mean to be coy, but what's the point? Is it that business skills are important, too, and that universities (and their CS departments in particular) are underserving the computing industry? That's what one of the comments (http://use.perl.org/comments.pl?sid=42485&cid=67709) seems to indicate. The American education system needs some work, but I think it's a mistake to see a university education as vocational training: the "fields" in a university don't correspond to "fields" in the world. It's a coincidence that computer science roughly corresponds to a field in high demand these days.
I agree that university education shouldn't be vocational training, but CS graduates need good programming skills. Computer science is very useful stuff, with a lot of applications in the Real World, and just because there are subfields in CS that don't have any obvious application, that doesn't mean that CS folks shouldn't at least try to be useful. Have a look sometime at Simon Peyton-Jones' Haskell-related papers: they're pretty far removed from grunting-in-the-dirt Java monkeying or hacking up a quick Perl script, but they're very readable, and someone who knows Haskell can generally see the usefulness of them on the very first page.
(Also, CS people should be comfortable slinging code around. Some would argue this point, but having decent programming skills makes anybody whose work involves computers much more effective. Ideological purity be damned.)
I think the kind of education and training needed for most software development situations is not widely available. What's needed, and starting to show up is a software engineering degree that bridges the gap between code-monkey and computer scientist.
Vocational education programs in computer programming tend to produce code-monkeys who produce internal applications that don't do anything especially interesting. The applications are usually web and desktop GUIs over some database, and tend to be written in Java, C#, VB and the like. Most people with this level of training would have trouble picking up a new language without more formal training.
Computer scientists tend to know massive amounts of theory. I suspect most computer scientists could pick up a new language simply by glancing over the documentation, and write a paper describing the theories the language implements. If you asked a computer scientist to create an application the accounting department at a big company could make use of, however, you'd probably have bad luck.
What's often missing is education and training for software engineers. Finding solutions to difficult problems requires a good grounding in theory, but actually implementing them requires a background in tools that meet real-world needs. It does appear that degrees in software engineering are starting to appear, though I know essentially nothing about the programs. Most hackers fall in to this category, though their learning tends to come from less formal sources.
You overestimate(wish fulfillment?) the prevalence of difficult problems. The vast majority of work involves problems that you classify as not doing "anything especially interesting" and written by "code-monkeys".
Universities cannot churn out people who have real world experience. That is a fundamental contradiction.
Where do we find programmers who understand both the theory of algorithms and the practice of software engineering? It's simple - find someone who learned the theory in school and also has a few years of experience applying that theory. There are many of these people. If you can't find them, maybe the opportunity you are offering is not very attractive.
IMHO, the first is not really a problem, or at least not a big one. Part of the way a field advances is that researchers are free to try out any old idea, to see if it is any good. Most of them aren't, but we don't know which are worthwhile until we try them out. So it helps that researchers are disconnected from the process of making salable products. "Make something that sells in two months" is not a good way to get people to try out interesting new ideas.
The result is a slow filtering of ideas from research into practice. Occasionally, a university researcher comes up with something that the programmer on the street can immediately pop into a product (RSA encryption, bump mapping, Introsort, ...) but this is not the norm; nor, I think, should we expect it to be.
The second problem (low-quality C.S. graduates) is more serious. The writer's suggestions are not particularly new; they amount to putting more of what is often called "software engineering" into the C.S. curriculum. And part of the problem there is that it is difficult to do large projects in a university course setting. When you don't do large projects, all that stuff (teams, complexity management, ...) is not really needed. So, while this second problem is worth pointing out, I don't think there are going to be any quick fixes for it.