This post talks about a point raised in the pragmatic programmer book. It is to strive to learn one new language each year. We will also take a look at how this can be taken out of context and the anti patterns that comes from this. I think that with a little bit of realism, this is something that all engineers can strive for and can reap the rewards.

This is a short post about using the upcoming year to learn a new language. This definition can be extended a little bit to include learning a new platform, OS or a new framework. For the rest of this post, we will just refer to a new language, but it is interchangeable with platform/OS/framework.

The Intent

The intent behind learning a new language stems from the Pragmatic Programmer. The idea is that our programming language implicitly teaches you to solve a problem in a certain way. So by sticking with one language, we are narrowing our field of vision with regard to solving problems. I believe it's an unintended side effect, but it exists.

Learning a new programming language allows us to relook at existing problems and approach them differently. These lessons can then be brought into our main language and we eventually become more creative and effective at problem solving.

Choosing something new to learn

The way we choose of learning something new is very important. Generally, we shouldn't choose something just because it's similar to our existing language. We do not choose to learn C# if our main language was Java as an example. Nor do we learn Python if our main language was Javascript/Typescript for example. There are edge cases where a switch between similar toolsets makes sense. An example here is a Java engineer that wants to learn Unity has to inevitably learn C#.

In the general case, however, we want to be able to choose something that will force a change in our thinking. A nice way to approach this is to switch to a language with a different programming paradigm. So a switch from an object oriented to a functional programming/scripting language makes sense and so on.

The learning hurdle

This is the area where the least amount of advice is given to engineers. Sure, it's nice to talk about this in theory and market about how it will improve your life. At the same time, this is where engineers run into the most nastiest anti-patterns, so let's talk about success and failure.

What success looks like

Funnily enough, success is subjective and is limited to your availability. Let's be real for a minute, learning a new language is a huge undertaking because of the sacrifices needed to do this. Exponentially so if you're in a situation where you have responsibilities such as raising kids, looking after elderly parents or anything that takes up your time. These responsibilities are always more important.

So realistically, what does success look like? It is probably best to take an incremental approach to success. Starting with the end goal, we work our way down to the next acceptable form of success. So this is one form of a success ladder:

- Have a profit yielding app in production
- Have an app in production
- Have an app that works on my local environment
- I wrote X blog posts about the language
- I can solve interview questions with the language
- I got X points on stackoverflow from answering questions
- I can write small programs with the language
- I can write hello world 

Each person will have different forms of success with their new language. The main point is that they must be achievable.

Anti patterns for success

There are two main anti patterns that plague engineers when learning a new language. The one is setting up impossible goals. The other is destroying your work life balance for the goal.

Sometimes engineers set the loftiest, most unachievable goals for themselves. For example, we set a single goal like this:

Learn node.js and use it to build a game server for a multiplayer, 
browser-based game by mid 2020.

There are many problems with this goal. Does the engineer know what game they want to build? Why does it have to be done by mid 2020? Do they have experience in multiplayer game design? How do you know you're done with "learn node.js"?

Always remember that the goal is always to change our way of thinking, not to place extra burden on ourselves. The way out is to redo something you've already done in a new language. This way, you don't have anything extra to learn and you're able to focus just on the language. So reimplement an existing feature instead. Build up towards a small rewrite of your professional work application instead. This is much easier and more approachable than the big bang golden goal approach.

The other anti pattern is actually a side effect of the golden goal. When setting such a huge goal for yourself, sometimes engineers put pressure on themselves and pull off the big all nighters just to get the goal done. This decreases your quality of life and your main priorities suffer. Smaller goals helps you prioritise and backlog your goals. You'll also know ahead of time what's achievable and what isn't. Always remember that this is a hobbyist goal and should not decrease your quality of life nor add extra stress. If you can't finish it all, that's okay!

Conclusion

We looked at how we can use the upcoming year to learn a new programming language. We had a small look into why we want to do this. We also thought about how to choose something new to learn, what success might look like and probably more importantly, the anti patterns involved in learning a new language each year. Hope you enjoyed this. All the best for the upcoming year!