JRT

July 31st, 2004

James Strachan puts forward a proposal that Sun opensource the standard Java libraries and I see no problems with it. In general I don’t think we’ll see all the benefits James predicts from it though we would see some. In particular I want to point out one benefit that James claims we’ll get but that we definitely won’t get:

more eyeballs are now looking closely at the code

This is the biggest advantage opensource proponents put forward for opensourcing any code but it just doesn’t apply to Java. Why not? The source code to the standard Java libraries are included with every copy of the JRE. You can already go and inspect the source code, find bugs and submit patches to Sun. The fact is, most people can’t be bothered. They have real work to do and don’t want to be wasting time analyzing the source code for the library their using, they just want it to work. When it doesn’t work then people tend to turn to the source and people are already doing that.

I also don’t believe that people really want to write Java code that can run on the .Net platform. Java has always suffered from people feeling that it was second rate due to it’s cross platform nature. This is true to some extent, when writing any cross platform code you inherently make it harder to use the platforms native resources due to the extra layer of abstraction. Why would you use the .Net platform when all of the extra functionality it would provide (like tie-ins to word, infopath etc) wouldn’t be available from Java (because they’re not cross-platform). You’d have to use JNI or similar to call “native” .Net code and so you have to learn C#, the .Net libraries and their toolsets etc.

Also, opensource developers who are refusing to use Java now will refuse to use Java then. Read some of the blogs coming out of OSCON at java.net and you’ll realize that the majority of the opensource world is just unreasonably bigoted against Java. That’s okay though, I’ve grown to really dislike the GPL anyway.

Why You Shouldn’t Employ “Great Hackers”

July 31st, 2004

This article entitled “Great Hackers” really pissed me off. It is just so far off-base that it’s annoying. It’s not the kind of article that is generally wrong on facts, but just wrong on intentions and the concepts of what’s good and what’s bad. There are a few really, really stupid and outright wrong statements in it though. The worst of these is:

The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python.

That statement referenced a footnote as well which I thought might point to some scientific survey of Java programmers vs Python programmers so that the statement at least had some backing. Sadly, the footnote was:

[2] When Google advertises Java programming jobs, they cleverly require Python experience.

Honestly, doesn’t everyone know that real programmers code in C? Smart programmers aren’t Java hackers, smart programmers aren’t Python hackers, smart programmers use the best tool for the job. Sometimes that’s C, sometimes that’s Java, sometimes that’s Python and sometimes it’s a pen and paper.

Also:

Great hackers also generally insist on using open source software.

Maybe, but probably not. Great programmers use the best tool for the job regardless of whether it’s open source or not. Furthermore, programmers who aren’t in the opensource world tend to be unknown and you definitely wouldn’t know if they were great or not because you most likely won’t see the result of their work.

My biggest complaint about the article though, is that it espouses “Great Hackers” as something to aspire to. Great hackers have their place - they are really good at quickly creating prototypes because they are just so efficient at writing code. The golden rule of prototypes definitely applies though: always throw it out. Great hackers are dangerous because they write code so rapidly and are so focussed on doing what they enjoy that they don’t stop to design, document and test carefully. In software development, writing the code is the easy part. The design is the critical part to get it working correctly, the documentation is critical to keeping it working correctly and the testing is the part that takes up most of the time (while being necessary because of the problems introduced in the coding stage).

So when we look at a project the thing we least want is someone who is obsessed with writing code and who makes a habit of rushing in and implementing code without first designing it and rushes off to the next thing before they’ve properly documented and tested it. In short the worst advice you could give someone who wants to be a great programmer is:

make the following deal with yourself: you never have to work on boring projects (unless your family will starve otherwise), and in return, you’ll never allow yourself to do a half-assed job.

Paul Graham said that was the way to become a great hacker because:

All the great hackers I know seem to have made that deal, though perhaps none of them had any choice in the matter.

Which is precisely why I wouldn’t ever hire a great hacker. I’ll hire the great software engineer instead.