Kirill Grouchnikov's Blog

When you know that a programmer is a Java programmer

Comments

• Some management models are spreading the idea of process instead of individual knowledge . This disgusting philosophy is pushing salaries and quality down. Experienced developers will always make a better job than novice people using the same processes. I think the programming language itself is not the key on the real world problems, the maturity of the crew is more important - yes, I think expert Perl programmers are better working with Java than Java novices doing the same job. If you got experienced persons in many fields of technology, just do a careful management in order to put each expert in the position he could produce more.
  Perl, Java or Ruby ? doesn't matter - technology will always evolve for the next stage. The wisdom seem to be to keep your experts close to your projects. People are much more valuable than processes - I guess.
  

  Posted by: felipegaucho on December 04, 2005 at 07:31 AM

• Felipe,
  Note that i was talking about good Java developers and not novice Java developers. In addition, i did mention that i still haven't reached a definitive conclusion :(

  Posted by: kirillcool on December 04, 2005 at 07:45 AM

• Truly excellent programmers are really hard to find, and can be worth ten times a "good"/average programmer. I would take the "excellent" Perl programmer any day, providing they could convince me that they were enthusiastic about learning Java on the job.

  As to what turns a programmer into a Java programmer, I not sure exactly what you mean. But a lot of the power of Java resides in the APIs - so knowing in outline what's contained in those might be a good start.

  Posted by: psynixis on December 04, 2005 at 08:35 AM

• I don't think that the collections API is a good indicator because it is still too fundemental. Every Java programmer that deserves to get paid should know that stuff, even those on the bottom of the totem pole.

  I think that the focus during hiring should be on API's that are more specific to your project. For example, if you are building a GUI using Swing, then you can see whether the developer develops her own TableModel implementations, or whether she (implicitly) uses DefaultTableModel for everything; does she know what the event dispatching thread is, and how to write thread-safe GUI code? But, if you are developing a web application then you would want her to know how and why it is usually better to avoid putting lots of code in a JSP, how to control session state, etc.
  

  Posted by: briansmith on December 04, 2005 at 08:53 AM

• I broadly agree with what you're trying to say, though maybe for different reasons.

  A well-versed Java developer won't just know Java, they'll know a variety of Java tools as well. In addition to the Java syntax, it's going to take that Perl developer quite a bit longer to learn the syntax for things like Ant build files, web deployment descriptors, JSP files and more. Then there's knowing their way around a Java IDE, most of which will provide a terrific boost to productivity if the developer knows how to use it well. if they're going to be doing web development, knowing some of the ins and outs of a servlet container like tomcat will help a lot too, obviously.

  On top of that, a decent Java developer will bring with them an understanding of a fairly large number of class libraries; JDBC, the servlet API, Swing, XML APIs, etc. etc., not to mention the third-party ones like Spring, Hibernate, Struts/WebWork and log4j (and those are just the more common ones).

  If your project is extremely complex and will take a long time to develop then maybe you can afford to hire the generalist and train them up, but if it's like the majority, of course you're better off with the Java programmer.

  Posted by: recoil on December 05, 2005 at 12:44 AM

• ok, kirillcool

  that I guess at the end of my comment express my doubts about this subject. I also don´t have a definitive conclusion about such controversial subject.

  I guess the time a good indicator ;)

  Posted by: felipegaucho on December 05, 2005 at 04:45 AM

• briansmith,
  As said, knowing your way around collections is only a good sign. Then you need to see the specific portions of the JDK API that your project requires. However, working with data structures is a very pervasive aspect of programming and can be viewed as a deal breaker when you are interviewing a candidate for the specific language.

  Posted by: kirillcool on December 05, 2005 at 04:55 AM

• Krill,
  Perhaps it has more to do with paradigm then with language... Perl seems to be a very different philosophically from Java, and that paradigm mismatch is going to trip you up.I've recently had discussions with two folks that I consider to be good Java programmers. One of them is sold on O/R mapping, the other thinks that O/R mapping is hogwash and we ought to use straight SQL. Both think Java "hung the moon", so it's not a language issue per-se.

  --JohnR

  Posted by: johnreynolds on December 05, 2005 at 05:40 AM

• Java to perl is a loaded question to start with, at least compare oo to oo. (package and bless is not oo =p). Java to python, or .NET may have more answer as to why a developer becomes a "language" developer.

  As for finding a good to great programmer, if you start by asking about languages (or worse, looking for a language) you've already started asking the wrong questions (sadly, this is 90% of IT managers, blinders to the acronym list and see nothing else).

  You want to find a hacker, in the origional sense of the word. I'm talking about the guy Eric Raymond describedin How to be a Hacker. Do they have a love of writing code? Do they have other interests that show a creative mind? Ask them about their favorite language, and why it's their favorite. Last give them a challenge, something no hacker can resist. I put together a feature spec for a very basic website, gave them a server to use with a database server installed, a design template, and asked them to build the site in 10 days - the catch was in python, something they had never used before (now you might have to use ruby as python is getting bigger). I was always amazed by the results, and they often came from people I wouldn't have guessed just from an interview alone.

  Posted by: neelm on December 05, 2005 at 05:53 AM

• johnreynolds,
  Exactly the case. Take C developer for instance. I was once in that position (about 5 years), and you just think in pointers and shifts. Take C++ developer. Most chances are (although i left the field about 2 years ago, i see it in the interviews) they are not well-versed in STL (except Vector maybe). That's why i compare good programmer in the language you are using and an excellent programmer in quite a different language. The "apples vs. oranges" metaphore is really handy here, because you really need apples.
  neelm,
  Exactly the same as above. Sure, it will take .NET developer a lot less time to migrate to Java, but the original posting was about excellent developers in languages with different mindset. About giving the candidates ten days etc. - it depends on how much time you can invest in each candidate, and how much time the candidate is prepared to invest in you. It's not like you are going to a single interview and then have tons of spare time at home. In most cases, it's going to different places, sometimes 2 or 3 interviews in the same day in different locations. Give an excellent candidate 10 days and he will be somewhere else in 5 :(

  Posted by: kirillcool on December 05, 2005 at 06:08 AM

• kirillcool, you've hit on an essential point with collections usage, but to me that behavior is only useful when it's a symptom of a rare attitude I find rare in programmers: humility.

  The best java progrmmers I know are skilled and knowledgable, but they're not arrogant enough to think they can build everything from scratch. When they want some functionality, the first (and second, and third) thing they do is search for someone else's solution. They search the API. They search the development community. They know they could do it themselves, but they also know that should be the last option. And, finally, this is a basic instinct. When solving a problem they 1) go to the API, 2) go to the community, 3) go to the API again because you might have missed something.

  You're right in saying that syntax can be learned fast, but Java is so much more. It's the API and it's the community as well. The best Java developers realize that and use it.

  Posted by: gbarton on December 05, 2005 at 09:05 AM

• It's really a double edged sword. Our company just hired an 'experienced' Java programmer who did not know anything about Hibernate, Spring, and all the goodies. I am just wondering how experienced he really is, or how open minded. He has shown that he has ideas and sometimes good ones but I keep finding that nobody should let him loose, or he just creates something that nobody can understand or maintain - things that are cool to him. Sort of a loose cannon problem.

  Posted by: tvaananen on December 05, 2005 at 11:21 AM

• I humbly disagree with the assertion that comparing Perl to Java is comparing apples to oranges. It is true that in languages like Perl or C++ the OO aspects of the language aren't as integral - i.e. it is easy to write code that is not OO and more difficult to write code that is OO. However Perl and C++ developers who create objects generally do it for a reason.
  Java programmers on the other hand, have developed an awful lot of "patterns" to avoid the OO paradigm. I have seen a lot of J2EE code by so called experts with value object that look like structs and utility objects that look like procedural libraries. It takes just as much effort for a Java programmer to write procedural code as it does for a Perl or C++ programmer to write OO code, yet it seems to happen quite often.
  My point is this, understanding programming paradigms and design concepts is a separate skill from knowledge of a particular language. OO concepts can be applied in a non OO language (And Perl *is* an OO language regardless of how you feel about the syntax.) Procedural coding can be performed in any OO language (Even if you have to subvert classes to accomplish it as Java programmers do *daily*.)
  The best programmers are the ones who can demonstrate *both* a high level understanding of design principles, programming paradigms, and problem solving skills *and* can express those ideas fluently in at least one language. Identifying whether a candidate has those things is difficult. In my experience there are no bullet points. You have to take an actual problem and work through it with that person before you will have any hope of understanding how they will work on a team.

  Posted by: xagile on December 05, 2005 at 12:41 PM

• Hey neelm, are you crazy? You would like to test me how can I do something in Python? I'm programming in Java for maybe 10 years and you will test me with Python because I would like to apply for Java job? I know all features of Java language, OO programming, many Java APIs and many existing frameworks. You would like to test me in Python - I see only reason to do it - your fun.

  Posted by: pavelt on December 05, 2005 at 04:36 PM

• Judging a java programmer by how they use collections is short-sighted, IMO. I tend to use vectors frequently because I do a great deal of programming with webservices, between java and C#, so collections are a bad choice, in that environment.

  Also, with JDK 5 it is pointless to use iterators, as the for each loop construct is so much simpler, and less coding. :)
  

  Posted by: jblack1395 on December 05, 2005 at 05:49 PM

• According to Matz Ruby is heavily derived from Perl - so maybe if you had a good Perl programmer you should see how far they get with something like JRuby.

  You might find that the Perl prgorammer is good for different things, such as writing (or maintaining) your build scripts. You may find that there is a win-win if they can automate a lot of things which previously your dedicated Java programmers were getting bogged down in.

  Posted by: rickcarson on December 05, 2005 at 07:59 PM

• "Our company just hired an 'experienced' Java programmer who did not know anything about Hibernate, Spring, and all the goodies. I am just wondering how experienced he really is, or how open minded. "
  So what? I've not used those because I've never had the opportunity to. The projects I work on have different infrastructures in place, I'm not going to throw all that away to use something just because it's the latest buzzword.
  Last time I was involved with starting a project large enough and in the right type of work to warrant things like Spring and Hibernate Spring didn't yet exist and Hibernate either didn't exist or was way too immature to even consider a serious choice.
  While everyone likes to think that all programming is launching and building a completely new application using the latest hyped tech every week it's not. 90% is expanding or maintaining existing systems written originally by others that often have been in place for years, others quite often who are (like so many programmers) addicted to the hobby of writing their own frameworks and libraries (which is how Hibernate and Spring came into existence too, their authors could have adopted and modified something else after all).

  "Judging a java programmer by how they use collections is short-sighted, IMO"
  It isn't. Using the understanding of the Collections framework as the ONLY indicator is shortsighted, but it sure has a place in an evaluation. Certainly it's less shortsighted than judging someone's knowledge of databases only by checking their intimate knowledge of obscure SQL details (and yes, I've seen that happen during job interviews).
  Knowing other languages never hurts, and using the right language for the job is always a good thing. BUT the right language for the job might not always (usually?) be the one that has the most technical merits. As Kiril stated if you're in an environment with one Java guy and 10 C++ people Java won't often be the best way to go as you simply don't have the resources available. I've advised one company to NOT use Java when they came to me asking which J2EE appserver to employ. The reason? They were a Delphi/.NET/C# company with a LOT of Windows server experience, the application would be deployed on Windows servers already running IIS and would communicate only with a desktop client on Windows workstations. Even if J2EE would have been the technically correct choice for the serverside, in such an environment its introduction would likely have led to disaster for the project as they lacked any skills at all to properly use and implement it.

  Posted by: jwenting on December 05, 2005 at 11:27 PM

• Jeroen,
  Use <br> instead of <br/> for formatting, I took the liberty of fixing them for you.

  Posted by: kirillcool on December 05, 2005 at 11:37 PM

• 
  I feel the best quality you can have in a programmer is an open-mind to new types of solutions.

  Lets face it. 75% of the programmers you encounter out there view programming as a means to an end, or simply work time exchanged for money. Not everyone loves our jobs, loves tech, so much as we do who post here. I apologize for posting such a dark picture, but I've seen no other explanation in the past 10 years. It would be elitist to think I am not above needing a paycheck, realize I do work for a living as well.

  But back to the open-minded theory. An open-minded programmer will not despise learning new techonology to solve problems, but relish the chance to do so. An open-minded programmer will not throw out the same tired solution to a problem every time (ORM persistence on a new project? Just use JDBC, that's what we always do!). An open-minded programmer will try new solutions, will research & keep up on news about new solutions. An open-minded programmer will not throw up their arms when asked to modify source code that uses a new technology solution they are not familiar with - an open-minded programmer tries without complaint. An open-minded programmer doesn't insist on using the same solution behind other's backs to management - an open-minded programmer doesn't undermind the tech.

  Without such a single quality, a new hire will be a consistent drag on any project. Will the programmer be sufficient to do the project? Probably. Will the programmer be as fast as an open-minded programmer? Never, in the long run.
  

  Posted by: phlogistic on December 06, 2005 at 09:58 PM

• IMO, judging a true Java programmer on how they behave and use Collections is shallow. What makes a developer is knowledge of Java SE fundamentals. And with that, I mean a comfortable, non-bullshit knowledge of it. But really, there's no point of comparison with any language or with any standards at all whether one is a Java programmer. It is much better to compare which Java programmer is a novice, lousy, expert or a go-to-guy programmer.

  Posted by: richardqr on December 07, 2005 at 04:06 AM

• 
  "Our company just hired an 'experienced' Java programmer who did not know anything about Hibernate, Spring, and all the goodies. I am just wondering how experienced he really is, or how open minded. "

  
  So what? I've not used those because I've never had the opportunity to. The projects I work on have different infrastructures in place, I'm not going to throw all that away to use something just because it's the latest buzzword.

  Last time I was involved with starting a project large enough and in the right type of work to warrant things like Spring and Hibernate Spring didn't yet exist and Hibernate either didn't exist or was way too immature to even consider a serious choice.

  But isn't this part of the problem where a developer is not exposed to all kinds of things? Getting stuck maintaining old applications can be a harzard to your career in an environment that moves ahead very fast.

  My comment about being open minded also had to do with an attitude that people sometimes have. If they do not know it, they are hostile and shun technologies without much consideration. In my case, the "star hire's" solemn opinion was that hibernate should not be used at all, and that the only right way to access data is via stored procedures, never use inline SQL either. That sort of left me scrathing my head since these technologies are widely used in the company.

  
  

  Posted by: tvaananen on December 07, 2005 at 12:02 PM

This work is licensed under a Creative Commons License.