Good Java Developer vs Excellent Perl Hacker?

December 5, 2005 8:45 AM

Kirrill Grouchnikov asks who it's better to hire for a Java project: a good Java developer, or an excellent Perl developer?

Arguably, an excellent non-Java developer can learn Java syntax in 4-5 days. But is syntax everything you need to know to write excellent Java code? How much time will it take until he starts to write Java code that looks like Java code and not like Perl code (don't forget that working on team means that the code is maintained by everybody, and even if somebody leaves, his code stays)? Do big projects really need "stellar" developers, or perhaps a team of good developers with solid Java knowledge does better job in the long run?

For the sake of argument, let's substitute Perl with Python (or Smalltalk, Ruby, Lisp or C++), because even great Perl programmers tend to have strange ideas about object orientation.

We'll also skip the false dichotomy -- a lot of "great x programmers" are also competent Java programmers so it's possible to hire both in the one person -- and ignore the fact that you'd get the best of both worlds hiring one of the many already-great Java programmers out there before you raid the scripting-language gene-pool.

I'll also assume that both applicants are equally committed, and the Python developer won't jump ship the first time they get an offer to work in a language more to their taste.

I think my answer would be: if I was hiring someone for a six-month contract on a straightforward project, I'd go with the merely good Java programmer. If I was picking someone to work full-time with/for me on Confluence, I'd be more tempted by an excellent programmer, whatever language they happened to excel in.

(At this point it is, of course, obligatory to mention that we're hiring, but that I don't actually decide who makes the cut.)

The crux of the matter is the oft-repeated, and at least partly grounded in truth, old saw that an excellent developer can be an order of magnitude better than a good one. It may take the Python developer 12-18 months to build a comprehensive knowledge of the libraries and syntax, but you'll be seeing the advantages of having them around significantly before that.

As an aside, the "order of magnitude" thing is hard to measure. For certain godlike hackers it's a given -- if you're writing a 3d engine, you'd be better off with John Carmack than you would with a hundred lesser lights -- but in the realm of mere mortals it's not so clear-cut.

A great programmer may not crank out features ten times as fast as a good one, but they still may have that much performance benefit overall. For me, what gives great the edge over good is some combination of: attention to detail, which means their features will be more completely implemented with fewer incidental bugs, attention to design, which means they'll leave the code in a better state than they found it, and inspiration, where they will find solutions to a problem that simply wouldn't occur to other programmers. All of these have really, really powerful flow-on productivity effects for the whole team.

Ideally, I'd hire the great Python programmer and have them pair-program with a competent Java developer. The Java developer could provide expertise on concrete things like the minutiae of the Collections classes, and the probably-frequent-at-first "no, in Java you do it this way", moments. The Python nerd could chip in with "what about this case?" and "why don't you do it this way?", and the whole would be greater than the sum of its parts.

You just have to put up with the constant complaining that whatever feature you're working on could be implemented better in five lines of Python.

5 Comments

Don't you think that Python programmer will quickly annoy make Java guy to hell explainting how easy, quick and simple they could do their currrent task in Phyton? After all he may even try convert you all to JPhyton. :-)

> even great Perl programmers tend to have strange ideas about object orientation.

Excuse me? I think you are rather mistaken. But I would say that anyway. :-)

If you care to get a real idea, stop by your favourite book shop and leaf through Damian Conway’s books on OO in Perl and on Perl Best Practices if you want to get an idea of the state of the culture.

I started off programming in Perl. I take swipes at it every now and then as a matter of course. :)

If I could have written what you've written here, I would have. You're spot on.

The hardest thing to teach is that the code should be expressed in terms of what the intent of the programmer is and not in terms of what the machine wants to see. If someone writes code code that human beings can read, and it clearly expresses the requirements in something close to the native language of the team, then I'm not too concerned about what their favorite language is.

Previously: December 3rd, 1975

Next: Humane Interfaces