I’ve been a Java programmer for the last seven years, I’ve mostly used it in a professional context. But when coding during my spare times I often looked at other programming languages, in no particular order : Python, Ruby, Groovy, Scala, Clojure, Erlang, Elixir, …

But why would I look anywhere else if I have such proficiency in Java ?

Even if, like everybody, I have my own personal tastes about languages and their syntaxes, and I did choose some of them for that reason in the past, nowadays I tend to choose a language because of the tools it provides.

My motto is now :

Think tools, not language !

When I say “tools”, I mean what you have in your toolbox to achieve a certain goal, whatever the latter is : rapid prototyping, high availability, high throughput, correctness, … For example, if I want to quickly prototype a web application, I definitely won’t choose Java because all it has to offer are either some third party libraries (think Spring and Hibernate for example) that you have to integrate with each other or you can choose the JEE full-stack, which is, in my opinion, totally unproductive for the context, that is rapid prototyping. I might use them for a real application that would go live, but then it’s another context.

In the context of a webapp prototype I’d rather use some framework like Rails, Grails or Django, which are specifically designed for that purpose, as they all claim.

With such tools, you can create your prototype within a few hours - literally. And when come requirement changes it will be easy to adapt your prototype to them.

It seems too good to be true ! Indeed, there’s a catch, nothing comes for free.

… but it’s also about the language

Of course, in order to use these tools proficiently you’ll have to learn the language it’s built with.

Learning a new language takes time, and you don’t have time, don’t you ? Also, it demands humility since you surely will have to begin from zero or not far for from it. You’ll make mistakes, many of them, and you’ll soon start to wonder if this is really worthwile.

You know the answer : yes it definitely is.

New ways of thinking

Most, if not all, polyglot developers will tell you that learning new languages, even if you don’t use them daily in your professional environment, will make you think about problems in a different way, you will see things through a different angle, and that’s always a good thing. You certainly know the quote :

When all you have is a hammer, you tend to see all problems as nails

I know we overuse this quote but I cannot stress enough the truth of it : if you train your brain to new ways of thinking, you will be able to see solutions you wouldn’t be able to see otherwise !

Most Java developers I know routinely try to answer a problem the same way they always did, they don’t seem to think anymore, they’re like machines.

(Lack of) time

As mentioned hereinabove, it takes time to learn a new language, that’s true. But often you don’t have to master it in order to be productive with it, or with the tools. But yes, you must be prepared to read books, documentation, code, and to do some exercices, some tiny projects emphasing on a few functionalities provided by either the language or the framework you use.

I’m currently reading The Clean Coder, which is a great book by the way, and the author states that you should work 60 hours a week, that is 40 hours for your employer - the paid work - and 20 hours for you. During these 20 hours you should work to keep your knowledge up to date. You should be reading, practicing, learning, and otherwise enhancing your career. Don’t worry you will still have plenty of time for you and your family.

What if you don’t want to do that kind of commitment ? Uncle Bob has the answer : you should not consider yourself as a professional. That’s it.

I must say I completely agree with him.

So, you have time to learn new languages and frameworks. You have the equivalent of three working days a week to learn new tools.

Humility

Probably the least known problem when learning a new tool is humility. You have to be sincere with yourself : you will make mistakes, you will probably be a beginner for a certain amount of time. You won’t be the best in class anymore - if you were it before. And for some developer that’s completely unbearable. Needless to say that these developers will soon fade away as their ego will eat them.

You will be out of your comfort zone, and that’s fine. Embrace uncertainty, it’s where magic happens. By the way, in IT, everything is uncertain, change is the only constant. So if you cannot work with it, you’d better be doing something else. It’s rude, but it’s the truth.

In my current job we are building a client/server platform. The server is currently built in Ruby on Rails while the client side is done in Android (so Java). I didn’t have any professional experience with Rails but I decided I would be able to take the plunge because I knew there was a senior Rails developer that would act as a mentor. And he did ! For a few months I was the worst developer in the company, at least for the backend side of the project.

Unfortunately he left three months after I came and since we had to focus on the commercial demos we did more Android development than Rails. So I was left with nearly no experience with Ruby/Rails and many pressure upon my shoulders.

At this moment I still struggle with this framework but it gets better everyday. And I can say that I enjoy making mistakes, reading documentation and then getting better.

TL;DR

You certainly don’t want a surgeon operating the same way as he used to operates a few decades ago : techniques have evolved, surgeons have to learn them. Same for engineers, materials evolve, new ones are constantly created. We don’t build planes the same way as we did before. You don’t build a jet fighter the same way as you build a deltaplane.

The best tools are not necessarily built with the languages you know or those you like, but that shouldn’t prevent you from learning them. You should use the tools that fit the goals you’ve set for the project you’re dealing with. Of course, if there are alternatives - like the case of rapid prototyping for a web application, like I’ve shown here above - you should choose the framework, and thus the language, based on other criteria.

You will, in either case, learn new ways of thinking, you will expand the techniques you use, and all your future projects will benefit of that.