Transitions

Back when I was learning programming and software development in college, I began a practice of learning a new programming language every year. I started with Java, then moved to Perl, C#, Visual Basic, Python, Ruby, Groovy, Scala, PHP… etc. I still think it’s a good practice for every developer. It’s even a recommended practice by many other developers on how to stay in your game. You don’t want to be stuck in a situation later on in life where you have to quickly learn a new language (including new concepts) after you’ve been using the same one for decades. The COBOL programmers learned that about a decade or two ago.

So learning a new language is good. It’s not just good to have the ability to use that language in your current project, which you may not be able to do, but also if you switch projects to one that uses that language. However, even beyond direct use of the language is how learning new ideas and ways of doing things will change your code in your language of choice, or at least the language you have no choice in because it’s the one your project uses.

I doubt that The Matrix was programmed in single language. I bet even an AI uses an abstraction to reduce the processing power needed to design something like that.

Of course, this actually brings me to my second topic about projects themselves. The idea that you should learn a new language every year isn’t really new to many people. However, I think that the idea should be extended further to encompass switching projects every few years as well. In a large project this could mean just switching from one portion of the project to another, but with smaller projects it might mean switching completely to a different project (or at least dividing your time between the two).

The reason behind this is actually similar to why you should learn a new language. By being forced into thinking in the new language and solving problems with a different set of tools, it can increase the breadth of your experience and help you perform better on that original project or ones you face in the future. Similarly, being forced to work on a new project will make you think in new ways about new problems that will help you in old projects and even future ones. If you stay with a single project for too long, you’ll star to stagnate and be unable to really explore and incorporate new ideas that your project’s problem domain doesn’t cover. Lack of exposure to new ideas will prohibit growth. Your resumé won’t be improving, and you won’t be growing as a developer.

Ideally, if you switch projects you would want to switch to one in a different language than your last project. This will help cover both aspects of learning a new language and a new project. While you can always learn a new language in your spare time and on personal projects, you will generally learn faster if you’re thrown in the water as it were. Similar to learning a language by living in a foreign country, learning a new programming language is much easier if you’re thrust into the depths of it with no choice to procrastinate. You have to learn it to work on your project, which will help you gain new insight into development in general.

I’ll be starting this exciting adventure myself as I transition from my current project in Java to a new project in C++/Perl. While I’ve been meaning to for a while, I’ve never done any serious work in C/C++. Being forced into it by having to work on a code base that is primarily in C++ will help facilitate that learning process through experience. I’m excited for the opportunity and I feel that everyone should strive to make those sorts of changes in their work from time to time to keep fresh and productive.