Dan Moore!

On 'The Perils of Java Schools'

Joel has another interesting article, The Perils of Java Schools, where he laments the fact that many CS degrees are focusing on Java. His main points are that if you don't focus on the harder parts of CS (recursion and pointers) then you don't weed out inadequate programmers, and that Java doesn't allow for adequate examination of those harder parts. Weeding is needed, even though the harder parts aren't--for most jobs. (His example of the need for pointers is working on operating systems--how many programmers really need to do that? Darn few. [Of course, for those who are interested in working on operating systems, I'd recommend avoiding a Java based CS degree.]) In addition to weeding out those who don't have a talent for programming, recursion and pointers are a great interview topics (see his Guerrilla Guide to Interviewing) for finding smart people to hire.

When I read his article, I thought about the two related responses to his lament. The first is that coding isn't the most important thing for many 'programming jobs' anymore. For a large number of them, the ability to relate to business problems and solve business needs is much more important. See this article for a related discussion on how to avoid being outsourced. A pure coder is more likely to be outsourced than a coder who also knows the business. I'd argue that at many organizations, a brilliant pure coder who can't relate to the business folks is less effective than a decent coder who can extract requirements.

I don't have a CS degree. It has definitely hurt me at times: I'm not as comfortable with some of the lower level constructs (parse trees, pointers) as other colleagues with a traditional CS degree. However, my liberal arts education has benefited me, because the writing and oral communication skills that I honed at college help me pinpoint what non-technical folks want to build. In fact, while building a system is fun, the real challenge and reward of software engineering is finding out what needs to be built, and figuring out how to build it. Both types of skills are necessary.

But, the other point of his lament remains. How do you find intelligent software engineers, and how do you distinguish those who talk a good game from those who can actually play it? I was sitting around the poker table a few days ago and some friends were discussing MVC and n-tier architectures. It's so easy to toss around those high falutin' words--it's another to understand the nitty gritty of building them--I don't. But I don't think anyone who hasn't worked on those large scale systems really does--CS degree or not.

I don't know any one way to distinguish good workers. The closest thing to a methodology I have is to ask them questions about real world situations that stonkered me, and see if their answers make sense. Joel still makes sense in the Guerrilla Guide when he says you want people who are "smart and get things done". But I believe that the focus of development has changed enough that the lack of C knowledge is not a loss. Just as the lack of punch card skills is not a loss.

(Note that I've used software engineers, developers, and programmers synonymously above, which may or may not be a justifiable abuse of the English language.)