Learn a new language

One of my goals that I set for myself (it hasn’t come from any manager) is to learn a new programming language every year. I’ll admit to not have done it every year. Sometimes November rolls around and I’m like “well, nothing this year,” and thats it. But in recent years I’ve met my goal more often than not.

So why do it?

Programming changes dramatically really quickly. Just look at how quickly Objective C came into prominence and then faded as another language came out. Things change quickly. I look at Java now and see it looking like COBOL in another 10 years - I’ll still know it.

I’ve seen C programmers unceremoniously dropped into hundreds of thousands of line of Java code and try to write code where every method is static. I’ve seen COBOL programmers told to port their code to Java and write what amounts to COBOL in Java. The C coder found a job supporting some embedded code, and the COBOL coder learned Java after some time.

At my current employment, there are systems that are being turned off. Old main frames and batch processes are slowly disappearing. Their coders are retiring, or finding their way to other places where a few of the systems remain until they retire too. Unless I want to be the guy off at the edge of the cube farm, maintaining the antiquated system that hasn’t yet been converted to the technology that is being hired for, I need to stay current.

And to all those Python people out there who are pointing at big data and numpy, let me tell you about FORTRAN and how much numerical code is there. Java is the next COBOL and Python the next FORTRAN. They’ll live forever but in a few decades it won’t be fun at all. And to all those single language programmers who think their language is the best of all and everything else is deficient in some way, let me point to the wonderful language named blub.

While some languages may encourage a bit more mental agility than others, programming in them is the same routine. Using “the most powerful” language (whatever that may be today) over and over and over again is akin to doing the same sequence of Yoga without any corrections - you don’t know how poor your practice is until someone who knows that sequence better corrects you. And whats more, when you do something else, you will be exercising parts that you don’t use. The same is true of a programmer’s mind and the ability to think or solve unfamiliar problems - problems that aren’t neatly packaged within the paradigm that the language most comfortably works in.

Frameworks and the library of the day come and go at a dizzying rate. It’s even worse if you start looking at versions and consider how different OzymandiasLibV1 is from OzymandiasLibV2. Trying to stay on top of the cutting edge, or even the mature development hump of a library is often a full time job in of its own. They’ll keep marketability for a while, but these too will be gone some day. However mighty in its time, you will find vcs repos littered with projects that use libraries that are no longer in favor or have fallen into decay and disrepair.

The way to keep one’s mind flexible enough, and to be the technical lead when the department shifts from one language to another (rather than getting passed by on the interesting projects or find those offers of becoming a manager as the technology becomes less and less familiar more appealing) is to keep learning new ways of thinking about problems. In the programming realm, this means learning a language you are not already familiar with.

Learn a new language well enough so that you’ll be able put it on your resume with confidence and be able to answer the classic interview questions using it.

Learn a new language well enough that for any appropriate project that comes your way in the normal course of work, you could write any part of it in that language.

Learn a new language well enough that you’d consider it for the next home project rather than your tried and true language that you’ve got down pat and can use without needing to hit the documentation for 95% of the work.

Even if you don’t use that language in projects, it will challenge your thought processes. The concepts and greater understanding gained from this will help you write code in the language you are using for things on an every day basis. Learning Scala will help write better Java 8 code. Learning Perl will help write better Python code. Learning Php… will help you appreciate the small flaws in other languages more.

You already know all the languages? Great! Design one instead that plays with a particular aspect of computing. The esolang world is full of fascinating languages that try to make things a bit more challenging. And if you really like it, integrate with the scripting extensions for whatever your preferred language is. In the Java world, this is JSR 223 and the scripting API.

Me? What am I looking at for 2017? Its still two months off, but not too early to be looking at personal goals.

  • Learning Scala (expanding that JVM toolset)
  • Perl 6 looks nice (my first professional programming was with Perl 4 and 5)
  • Swift is finding its way outside of the Apple ecosystem.