JavaSchools are not the problem

Post ImageJoel Spolsky is one of the most famous and respected software development commentators, so when he writes an article, it is usually a good idea to take notice. His latest article, The Perils of JavaSchools, was published today and is definitely worth reading. I think Joel makes some good points, but I don’t agree with his entire argument. I don’t think JavaSchools, as Joel describes them, are the problem.

First, Joel mentions that in the old days programmers chose C as their language of choice whereas now they choose Java. His first claim is that Java “is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.” He goes on to say that pointers and recursion, two of the most difficult concepts to understand, are no longer taught in so called “weed out” courses.

The lucky kids of JavaSchools are never going to get weird segfaults trying to implement pointer-based hash tables. They’re never going to go stark, raving mad trying to pack things into bits. They’ll never have to get their head around how, in a purely functional program, the value of a variable never changes, and yet, it changes all the time! A paradox!

The first problem with this argument is that pointers are rarely required anymore, and functional programming just isn’t used much. Joel himself identifies both of these facts. He also mentions that to work on an operating system, you pretty much have to understand pointers. That’s the second problem – while that may be the case today, it probably will not always be the case!

I don’t think that a programmer has to learn a really hard language with really hard concepts to be a great programmer. I don’t think it matters much if someone is an expert at recursion and pointers, or if they are an expert at object oriented programming instead.

How is anyone supposed to learn anything if the curriculum has been carefully designed to make everything easier than it already is?

I don’t think that you need to learn the hard way in order to learn anything.

The fact is, things are getting easier than Joel makes them out to be. Managed code is quite a bit easier to write than traditional unmanaged code, but that doesn’t mean it is limited. There is already a research project at Microsoft to build an operating system using managed code (almost entirely). And we’re inching closer and closer to a time when efficient programming is more important than figuring out all of the different ways to solve a problem and then finding the fastest one, or the one that uses the least amount of memory, or separating them on some other heuristic. We’re going to need rapid application development to get things done quickly.

Consider manufacturing. Do you have to know how all of the little pieces work together in a widget in order to make a useful contribution to the team building that widget? What if the widget has wheels, do you need to completely understand the wheel? All of the angles, the way it works, the problems it may encounter? I would argue that the best way to make a useful contribution is to specialize in a particular part of that widget, or even better, the process of building part of the widget. We’d be able to build far more widgets, far more efficiently, if everyone specialized in something than having to understand everything.

Medicine works the same way. All doctors have to learn the same basic stuff, but then they specialize in a particular field. The difference with computing sciences is that we don’t yet know what that “same basic stuff” should be. Is it object oriented programming, or something else? Certainly the conventional wisdom is that you should learn OOP, and thus we teach Java. The “same basic stuff” has become Java, and I have no doubt it will change again in the future.

Second, Joel seems to suggest that the only good programmers are ones with lots and lots of education.

But what about the CS mission of CS departments? They’re not vocational schools! It shouldn’t be their job to train people to work in industry. That’s for community colleges and government retraining programs for displaced workers, they will tell you. They’re supposed to be giving students the fundamental tools to live their lives, not preparing them for their first weeks on the job. Right? Still.

I can’t understand why the professors on the curriculum committees at CS schools have allowed their programs to be dumbed down to the point where not only can’t they produce working programmers, they can’t even produce CS grad students who might get PhDs and compete for their jobs.

I agree that CS students really should learn to do some actual programming rather than just theorizing about it. I don’t agree though, that a good programmer should be defined by their level of education! I think what needs to happen is a separation of what we currently call “computing scientists.” Those with the PhD’s, and those who like to do the research and try and wrap their heads around weird concepts should be the computer scientists. Those who are trained as good programmers, able to solve problems and actually implement solutions should be computer engineers.

Take my school, for example. We have Computing Sciences and we have Computer Engineering – but the two do not match up to the two types of people I just described. Currently, Computing Sciences encompasses both computer scientists and computer engineers. That needs to change. There should be different curriculum for each.

Joel says:

I’m going back to ones and zeros.

That’s too bad, because Joel is a very smart guy and could probably make a difference in how we move forward. The problem is not with JavaSchools. The problem is that the same school is trying to teach two totally different types of people.

Read: Joel on Software