Skip to main content

When you know that a programmer is a Java programmer

Posted by kirillcool on December 4, 2005 at 4:47 AM PST

A long long time ago in a blog far far away I wrote about JDK collections and how should you choose your data structures. This topic has been on my mind during the past year, and I still haven't reached a definitive conclusion.

First, I should mention that i have interviewed about 40 people this year for the technical positions in our project, which gave me an opportunity to see a large variety of programming backgrounds, styles and approaches. Second, we program in Java, which is quite important for the following discussion. Now that this is said, let's continue.

There are numerous techniques for interviewing candidates for technical positions. They range from writing the code on the paper to open-ended design discussions. Most would argue that the best candidate should be well-versed in many conceptually different languages (such as Java / Perl / Lisp), but doesn't have to be a master of any. This will allow him / her to pick the tool (language) that best suites the task. This is true in theory. In practice, however, there are quite a few formidable obstacles to this.

First, most existing projects have already chosen an implementation language, so it would be quite annoying hearing "Let's do this in Ruby" when you have hundreds of man-years invested in the project under your belt. In addition, it's not only your decision - you have existing deployments at customer sites, when sometimes the customer is the one dictating the language (say, somebody invested in a farm of WebLogic servers and wishes your application to be a part of the eco-system there). Furthermore, what about other developers? Sure, in Ruby you can do it in half the time, if only you have 10 experienced Ruby developers (not all applications are CRUD in the real world, unfortunately). Until we get that many available Ruby developers, curb your enthusiasm :(

And now, for the interesting part. Suppose you have an excellent Perl developer and a good Java developer. Which one should you take to your Java project? 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?

Which brings me to something that has been on my mind - what turns a programmer to a Java programmer? In my opinion, it's the correct way of working with collections. Once I see a candidate using iterators and maps, this is a very good sign. Most of the people coming from C or C++ work only with arrays or vectors. They sure look like hammers, but most of the real-world problems are bolts. It takes some time to get used to the syntax, it takes more time to know the available options, and it takes much more time to make the correct and informed choice. During this time, an excellent ex-Perl developer is prone to make your code base slower, dirtier and a mess to maintain.

Any thoughts?

Related Topics >>