Tag Archives: Jobs

Scala, Groovy, Clojure, Jython, JRuby and Java: Jobs by Language

In a previous post I pointed out that one of the more obvious recent changes in the Java landscape has been the meteoric rise in popularity of other languages for the JVM.  Some are old and some are new but JVM compatible versions of established languages with the likes of JRuby and Jython, Java-esque languages like Groovy and Scala and brand new languages like Clojure and Kotlin offer genuine options for those that appreciate the performance and reliability of the JVM but also want a different syntax.

In an ideal world all developers would be able to develop in the language of their choice. The reality is that as developers we are constrained by the suitability of the language, the tooling support and by what languages companies are actually using. Firstly, you choose the language appropriate to the domain – one that lets you do your job quickly and easily but with the appropriate level of support for your non-functional requirements like performance.  Secondly no one wants to be slogging through the coding process in a simple editor. Yes, I know that we could all use vim or emacs but being able to refactor large swathes of code easily and quickly (hello TDD!) kind of demands a modern IDE like IntelliJ or Eclipse. Thirdly, the reality of the situation is that very few of us are in the position to be able to dictate to our employers what language we should be using. Learning a language with rising popularity also means that you have a greater chance of being employed in the future (which is nice) but employers drive the acceptance of new languages.

The fact is that many companies boast about using the latest and greatest languages since it makes them more attractive to candidates. You can barely move for the blog posts and tweets of people raving about how their company has completely changed their development process with a new language but what is the real picture?

For a useful indication of industry acceptance we can go on the job trends on indeed.com. The grand daddy of language charts is Tiobe but it’s no use at this point since a) it does not provide sufficient information and b) is too easily gamed – yes Delphi dudes, we know what you did. Now before you complain, I know that using something like this is far from perfect and a long way from scientific but unless you fancy doing a longitudinal study going asking all the companies what they are using and believing their answers are real rather than marketing fluff, it’s probably good enough to be illustrative.

So what can this tell us about the how the industry sees the major language of the JVM: Java, Groovy, Scala, Clojure, Jython and JRuby*. What happens when we have a look at the percentage of all jobs that mention these languages

Umm, well… it’s pretty obvious that despite all the industry noises about other languages, Java is still massively dominant in the job marketplace with almost 3.5% of the jobs requiring Java knowledge. We all know that Java is an industry heavyweight but it is a bit of a surprise that in comparison the other languages are an indistinguishable line. Welded close to the 0 line, they would need some seriously exponential grow to start to threaten Java.

So what happens when you remove Java….

This is a lot more interesting. Firstly Jython was the first language other than Java that was really accepted on the JVM. Groovy started to pick up in 2007 and quickly became the first of the alternate languages, no doubt driven by Grails. Clojure and JRuby have never really garnered much support despite the recent rise in the last 18 months or so. I think the most interesting point is the recent increase in the acceptance of Scala. Currently third behind Jython, the gradient indicates that it will soon move into second. Comparing the grow rate of Scala and Groovy on a relative basis we see the following.

So we can see that Scala has finally crossed over Groovy’s growth rate. It’s completely reasonable to say that this could be temporary and that we should not read too much into this but there are a few data points there so it does not appear a flash in the pan.

So what can we say; while you’ll want to dust off the old Groovy text books and maybe have a look at some Scala tutorials, the best thing you can do is to keep your Java-fu in top notch order. As far as the industry is concerned Java is still the Daddy of the JVM languages and seems to being staying this way for some time.

* – I did originally include Kotlin and Gosu but since there were 0 jobs for Kotlin and only about 9 for Gosu they would only have been noise.

The Characteristics of a Good Developer

The recent rash of interviews have made me think a little more about what makes a good developer and more importantly, which of these qualities can you try to spot during the interview process. After having a conflab with a couple of other devs and one of the few recruiters I know that isn’t a shark, I came up with this list. Of course this is going to be a personal list but some of the points seem to intersect with some other resources out there so I don’t think I’m too far out there:

  • Polyglot in outlook
  • Able to learn quickly, and happy to learn
  •  Open to new ideas but capable of defending their own
  •  Technically able
  •  An Influencer
  •  A Producer
  •  Not too proud to ask for help
  •  Knowledge across a broad spectrum of topics
  •  Determined

Polyglot in outlook
One of the Java devs I work with recently coded up one of the most elegant solutions to a complex problems that I’ve ever seen. When asked how he came up with it, he mentioned that he based it around some of the structures that Make uses internally. Too many developers only live within the walls of their favourite language and never see what else is out there that they could take advantage of. As a Java house, currently I would have to say that anyone with Scala or Clojure on their CV will be seen far more favourably than someone with just Java and someone with half-a-dozen languages is almost always going to be going places. In fact during interviews I will deliberately ask questions on concepts in languages that aren’t on the candidate’s CV since I want them to at least be aware of these concepts even if they have never used them.

Able to learn quickly, and happy to learn
As a self-confessed knowledge junkie, I love learning. In fact I find it hard to comprehend what other developers do not. Given that we are in a knowledge industry, those that do not have a thirst to learn will find themselves going the way of the guys who thought that punchcards and ticker tape would last them a lifetime.

Open to new ideas but capable of defending their own ideas
What is the point of having great ideas if you don’t have the ability to defend them. Developers tend to have robust opinions about how things should be done so you have to be able to defend what you think is right. Otherwise you are condemning yourself to work on projects where you spend your time muttering to yourself “this could be done so much better”.

Technically able
You have to bring skills to the table. You can be the greatest person in the world but unless you have the technical chops to be able to develop you will just be a drag on the rest of the team. Don’t be the Net Negative Producing Programmer

An Influencer
This is the pro-active side of being able to defend your own ideas. You need to be able to change or at least shape the ideas of others and have the communication skills to do so. Especially at the level of senior developer or above, you have to start spending time educating and influencing others. If you fail to do this, all you are doing is making your job harder. You have to be able to prevent small problems blowing up into big ones and if that means you need to sell your ideas, then that is what you do. If you are a Senior Developer and above, I expect you to influence your workplace. For example, if your current employer does not use a Continuous Integration Server like Hudson/Jenkins or Bamboo, you have failed in your responsibilities if you cannot convince them that they should.

A Producer
Seeing someone’s work on something like Github gives me one of the best insights into what sort of programmer they are. Ultimately, it’s the Quarterback problem, it’s practically impossible to judge someone’s ability until you see them in action. The closest thing you can get to seeing them in action is to see the results of previous work and this is why we have a technical test as part of our interview process. And before you roll your eyes, we’ve made sure that the test is directly related to what we do and isn’t just some random logic puzzle. If you are already on a team, make sure that you take time to look at your work and check to see if there is anything your should be doing or anything you should not be doing that would improve your productivity. I knew of an Architect at a recent company who was obviously very bright but was unable to produce anything.  He literally produced nothing but ghosted around on his domain knowledge and reputation when he actually contributed nothing to the teams in his area.

Not too proud to ask for help
If you get properly stuck on something, no one will think worse of you if you ask for help. You will drive your team mates mad if you disappear off and take days with a problem, especially if one of them immediately gives you the answer that would have saved days. Your colleagues will quickly realise that the people who have to cover for you getting stuck is them.  The only time people will think less of you is when you get stuck and don’t even bother to try to figure it out yourself before you start asking for advice.

Knowledge across a broad spectrum of topics
Depth of knowledge demands breadth of knowledge. It is impossible to be an expert in one area without having a degree of expertise in others. The ability to link concepts is hugely important and if you already know something similar, even in an unrelated field, learning something else will be so much easier.

Determined
The tired old saw of ‘when the going gets tough, the tough get going’ aside, you have to have a certain cussedness to succeed in programming. Spending hours trying to pin down an elusive race condition or tracking an issue through layers of network infrastructure, web servers, caches, web services and database code means that you can’t be someone that throws in the towel early. Also, there are always going to be times when you are going to have to put in some extra work. Whether it is an approaching deadline or a sudden change in project priorities or roles, no one is going to thank you if you can’t manage your focus. If you are known to meet challenges head on, your team mates will always be there with you and will always have your back. If you have any tendency to slack off, you colleagues will leave you high and dry and I wouldn’t blame them at all.

I should also say that this also applies to situations where management are asking you to do ridiculous things. If the higher-ups have you on a Death March, I don’t want someone that meekly caves in an agrees to late nights and weekends in the office without seeing if it is the right thing to do. Determination is not the same as working insane hours and sometimes people need to remember that.

I was also going to put in something about leadership. This is a hugely important skill but you can be a very good developer without it so I felt I could leave it out without it being to big an issue.

Anyway, that’s my list. What do you think?