Pointers For Success

Joel Spoelsky just posted an article The Perils of JavaSchools, which makes the claim that because schools teach students Java instead of a "lower level" language like 'C' or Scheme, he now has a harder time weeding out the "true" developer minds from the wannabes.

I realize that Joel is spelled G-O-D in some developers workbooks, and that his blog is sure read by a lot more people than mine. But he is just wrong, wrong, wrong on this topic. (Well, maybe he's right in that he has trouble sorting out his idea of a good developer. But that's a personal problem. And a little known and lesser used language like Scheme? Lisp maybe, or Smalltalk - I think even Pascal got more academic use than Scheme. What little Private Idaho of a CS world did he grow up in, anyway?)

The argument Joel makes is that, since most student's programming experience these days is in a language that doesn't directly represent pointers, they can't have ever handled a truly hard problem. (He goes on to make a point that this is similar to learning Latin or Greek, in that the experience of learning those languages somehow makes you smarter. Now I don't know if Joel took Latin or Greek, or can read or speak either now, but I know he considers himself pretty darn smart - heck, I do too. Perhaps learning Scheme filled his ancient language requirement.)

Let's examine this a bit.

Like Joel, I started my programming career using punch cards. Writing programs was a long, laborious, tedious affair. Much planning was done before even writing the program (flowcharts, etc.), because producing a deck of punch cards that implement a poorly designed logic flow was a huge waste of time (not to mention trees).

Fortunately, some smart people (who still must have been taking Latin) came up with the idea of abstraction in computer languages. Each generation of computer language further abstracted the developer away from the bits being toggled in the computer. This abstraction, like any abstraction, allowed the developer to fit a broader scope into his limited working memory.

Most people have a working memory of about 7 'chunks' of information. It those 7 chunks are filled with seven octal representations of byte instructions, then it's hard to think about much else until you've worked through putting those seven bytes into a more persistent form, like punch cards. If those 7 chunks are filled with seven SOAP services, each of which perform large complex operations, then the breadth of scope at which the developer is working is dramatically larger. This is why Abstraction Is Good.

Learning the seven assembler addressing schemes of the DEC RSTS and VMS operating systems, learning how to "cold start" (boot) our old IBM by entering the correct address space via toggle switches - none of this made me more equipped to deal with J2EE, SOAP, or (god forbid) Visual Studio.

In fact, I would be so bold as to say that developers who work in Java today are dramatically more productive than the 'C' developers I used to have on my teams. This isn't because they're smarter. They're just working at higher levels of abstraction.

Is it useful to ask a candidate to demonstrate basic concepts like pointers, linked lists, and recursion? Maybe. It would at least sort out those with some CS education from those who just read Visual Basic For Dummies. But these concepts are first year CS concepts, so they're mostly just insulting to anyone that actually studied in the field.

Are there good Java programmers and bad Java programmers? You bet. The old 10x productivity ratio between the best and the mediocre still holds. But the way to evaluate good from bad isn't to see if they can demonstrate a great facility with pointers.

(What is the way then, you ask? Ah - that's for my next post.)

(BTW - one of the best hard data cases for the classic 10x difference in programmer productivity actually comes from Joel in this article...)