In their book The Pragmatic Programmer, David Thomas and Andrew Hunt urge programmers to learn a new programming language every year.

Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getter struck in a rut.

In fact learning a new programming language every year was a Internet meme a few years back, and with with good reason. I often turn to Martin Fowler for sage advice and he largely agrees with with what PragProg has to say (words in parenthesis are my extrapolation):

For many developers, the [knowing only] one-language notion is a sign of lack of professionalism. This is best exemplified by the Pragmatic Programmers' advice to learn a new language every year. The point here is that programming languages do affect the way you think about programming, and learning new languages can do a lot to help you think about solving problems in different ways. (It's important to learn languages that are quite different in order to get the benefit of this. Java and C# are too similar to count.)

although with a little caveat:

My personal scripting is pretty much all done with Ruby and I've been loath to any more than play with reasonable alternatives like Python, Groovy, or PowerShell. It's not that it's hard to use the alternatives, but with Ruby I know too much that I'd have to look up with the alternatives.

I think Martin Fowler offers a great reason to learn new languages and an equally strong reason to stick to the ones we know for most work. The former opens our mind to different paradigms and alternate/fresher ways of thinking and the latter ensures productivity by doing professional work in the language/platform that we know like the back of our hand.I personally think this is a great way to view learning. Especially the learning of new languages. I have worked in Java pretty much all my programming career, but there was a time when a lot of people felt (and I agree with them in most parts) that Java did not lend itself well to rapid application development. Even though there was a strong use case for using Java in enterprise applications, there was a growing consensus that it was not the right choice for many other use cases. Languages like Ruby had an edge over Java when it came to writing scripts, creating prototypes and even building small to mid sized web applications. It is testament to this opinion that Ruby is now used in devops for writing Chef scripts as well as building web applications of all sizes. Back then in the late 2000's, Groovy was seen as an alternate to Ruby within the Java/JEE ecosystem because it compiled to Java bytecode and could make use of regular Java libraries. I was pretty excited at the time and started learning Groovy. I learned it mostly out of curiosity and for fun. I wasn't expecting to do any professional work in it. But something interesting happened a while after I learned Groovy. I got to work on a project that used the Gant build system which used Groovy to create build scripts. My knowledge of Groovy came in very handy while working on that project.So don't worry too much whether you will actually use that new language for work. If you learn something new to expand your mind, it's likely that the knowledge will come in handy at work, and even if it doesn't, it will have helped you cultivate an alternate perspective towards problem solving.Deciding to learn a new language is a step forward. However, many programmers get stuck on which language to learn next. Obviously there's no one right answer to that problem. It depends a lot on what you already know, how much time you have and which ecosystem you work with. As much as I am a fan of learning new things, I have preferred to maintain some boundaries to protect my sanity. Since I have worked largely in the Java ecosystem, I tend to stay away from all things .NET. Not that there's anything wrong with .NET, to those who primarily work in .NET, I advise them stay away from Java unless their work demands it. There's way too much to learn. If we don't set some limits then the possibilities and the mental overload can cripple a developer more than helping her. Also since it is better to learn across paradigms, learning .NET for a Java developer really doesn't help much.The real benefits of learning new languages shines when we learn across paradigms. The way an object oriented language like Java approaches problems is different from the way a procedural language like C did, and the way a functional language like Clojure sees the world is different than the world view of Java. So if you are a Java or a C# developer I would suggest that you learn Ruby because even though it is Object Oriented, it offers a very different paradigm, and has metaprogramming as an added benefit. I would learn Ruby purely to understand how metaprogramming works. Another choice would be to learn a functional language such as Clojure or Haskell or Elixir. If you haven't spend time mastering SQL, then put everything aside and do that first. Do it even if you don't write raw SQL yourself. Understanding different queries, joins and how they affect performance is  must-have for any developer. If you have never worked with Assembly Language, then that's one more thing I am going to suggest very strongly. Even though you may never ever write machine  code, every programmer should know (at least to some extent) what happens at that level. Then there is Google's go-lang which seems to be gaining in popularity, or perhaps Lua for game programming. So really, sky's the limit here. Pick up something that looks like fun or something that you really need to learn and set up a schedule to get going.We are still in October 2015. That's about two and a half months to learn a new language if you haven't done so already. It's a good enough time to learn something small if you aren't swamped in deadlines. How about something useful like SQL or Ruby, or something fun like Elixir? Whatever your learning goal, we are here to support you with our online labs and exercises.