Needle in a haystack
Why is it so hard to find good Java developers?
Like needles in a haystack of bored programmers, good Java developers are in short supply. But who's to blame? Disinterested programmers? Misguided recruiters? Or is it the language itself?
Whether or not you agree, here are some of the most commonly spouted arguments as to why it’s so hard to find a decent Java pro.
The problem isn’t the language, it’s the people
Most developers want to make a difference. Most developers even want to experiment. But more than all of that, most developers want a job (and a well paid one). The easiest way to get one is to stick with Java – whether or not you enjoy writing it. That’s why many of the world’s less passionate developers end up with the Java flock.
“I'm not implying that all Java developers are sheep,” writer blogger Sandy Walsh, who argues that too many developers are rewarded for blindly learning software packages without understanding them. “There are many, many awe-inspiring Java developers out there. Sadly, there are far more sheep.”
Meanwhile, Neil Sainsbury, an Android developer “stuck using Java”, says the problem is Java writers trying to be architects. “[...] so often I find I’m reading code that looks more like a plan for something that solves a problem, rather than something that actually solves a problem.”
Rather than being able to skim code and see what the person is up to, supervisors often have a tough time trying to make sense of what developers pass on to them. “You have to dig deep, you have to learn a whole new vocabulary of abused and tortured words (“AbstractAdapterFactory”), you have to become part of the system.”
The problem isn’t the people, it’s the language
Java blogger Michael O.Church argues it’s the other way round. The issue with Java is that it’s hard to tell whether a developer is good or not based on a short sample of code. The average company will try to take a look at some examples of the applicant’s code before hiring. The more careful dev teams will usually call their applicants in for an assessment day filled with various coding assignments.
[...] a bad hire can derail a project and, for small businesses, sink a company. For this reason, technical interviews at leading companies tend to be very intensive.
But given the notoriously long-winded nature of Java, even a 500 line sample (which is often beyond the time constraints of some supervisors) will not be enough to get a sense of what the programmer is trying to do. And neither the recruiter nor the developer have time for more.
Everyone speaks Java
As the first language everyone learns, many developers can claim to have a “background in Java”. It’s a bit like finding someone that speaks English. Most people claim they can speak it, but finding someone that writes can eloquently finish a sentence is… well, kinda hard… right?
To make it even more difficult, a Java developer with only basic skills can make themselves look experienced. The more simple test assignments put to them by a recruiter can often be solved with a copy-paste from Stack Overflow. Meanwhile, a good developer will often be too busy (or proud) to be subjected to complex or lengthy coding assignments.
At the same time, young, ill-educated recruiters are busy hunting for “ninja programmers”. Cordelia Dillon argues that the ideal developer is less like the “rockstar coder” that many recruiters target, and more like a sculptor or archaeologist.
If recruiters really want to talk about ninjas and rockstars, or even sculptors and archaeologists, they should spell out the qualities that are shared between those roles and the software development roles they’re advertising. Candidates will identify more with a list of desired skills than with a list of arbitrary buzzwords.
You’re not looking properly
Companies are afraid of hiring employees whose skills will date quickly, because most companies don’t like to start projects in languages where it’s tricky to find developers. By playing it safe with their enterprise solution, companies are essentially looking for developers to blindly code Java. They enter as Java developers, and they leave as a Java developers.
That’s why Sandy Walsh says the problem isn’t the language, it’s the way companies hire. “If you build a product that is going to have a long life-cycle, you have to assume the software is going to have to live beyond the developers that assembled it. If the application is written on niche or trendy languages or tools it will be harder to replace these developers later. This is broken thinking.”