Why I Learn a New Programming Language Each Year: Insights After 15+ Languages
Really? New language every year?
Two questions come up, even when I’m writing that one.
- “Are there even that many languages to learn?”
- “Do you really learn one language every year?
Yes and no (or kind of…).
The Numbers Game
Yes, there are many languages. I couldn’t find specific number of programming languages. Many pages states there are more than 700 programming languages. TIOBE index lists 100 most popular. So yeah, if you want to learn new programming language every year, there are bunch to choose from. That’s more than enough to keep you busy for a lifetime.
No, I’m not learning new language every year. But it gives a good picture. It’s more complex. After 15+ years in trenches, here’s what my language portfolio looks like:
The Money-Makers (Languages I've Used Commercially)
- Java
- Obj-C
- JavaScript
- Scala
- Swift
- Kotlin
- TypeScript
- PHP
- Go
The Side-Project Squad (Languages I've Tinkered With):
- C
- C++
- Python
- Haskell
- Elm
- Rust
That’s 15 languages total. So that would be almost 1 language per year. But distribution is not uniform. E.g. when working on mobile projects, I’ve been coding & learning Swift, Kotlin & JS (React Native). The other time, I was working Java, PHP & TS at the same time. Currently, I’m diving deeper into Go (day job) & Python (learning ML).
"But Isn't One Language Enough?"
Here’s a thing: it’s more than enough to master 1 language for a solid career. And yes, mastery takes time. Like a lot of time. But there’s something in learning new languages that can support “main” language.
In ML, there’s a concept called transfer learning.
Transfer learning (TL) is a technique in machine learning (ML) in which knowledge learned from a task is re-used in order to boost performance on a related task.
Languages come with its own philosophy. Each has different set of feature. They approach problems from different angle. Or, they solve different problems. Most importantly, they have different assumptions.
The idea of learning many languages is to transfer concepts between ecosystems. E.g. you can learn about functional programming in Haskell and transfer some ideas to React. AFAIK, Redux is an example of transferring concept. It was inspired by Elm Architecture and moved to JS world.
Modern languages evolve. New features arrive. Different languages often have the same concept, called differently. They get more similar to each other (I don’t know if that’s a good thing - more on that here). Take a look at Goroutine vs. Java Virtual Threads vs Kotlin Coroutines.
So you can either transfer new concepts yourself or be prepared for upcoming changes. Both ways, you get benefits.
Not to mention curiosity. I have a pleasure to work in team where I can jump between different layers & systems. I can work in different ecosystems. That’s really important to me.
Everything is interesting if you go into it deeply enough. - Richard Feynman
The Good, The Weird, and The Go-ly
Let me give you some examples of my latest finding. I’m diving deeper & deeper into Go. Things I found interesting/strange/odd:
- there’s only
for
loop -> there’s nowhile
ordo while
- there’s no terinary operator - It makes some code bloated. I’m used to terinary operator in JS. I use it often. But, I understand the idea of simplicity & straightforwardness.
- no inheritance but embedded types
- there’s no direct definition that type implements interface
- compile time errors for unused variables
- channels & goroutings - that’s big topic & I want to get deep into Go concurrency model
- type definition scattered across many files
- error handling -> no check nor uncheck exceptions
You can find concepts, techniques and approaches that are interesting or weird. Some can be questionable. Often the ones that look strange or stupid are worth digging. What seems weird at first might open new paths in your brain.
Getting Started: The How
There’s no one-fits-all solution. There are few options. You need to choose the ones that make you happy & excited:
- attend conference
- read a book
- take a course
- make mini-project
- join communities
Active learning gives better effects than passive learning. Try to incorporate some real life examples. I gather ideas for projects. So then I have a list to choose from. Going back to my Go lang example. Apart from working on production system, I want to prepare CLI tool for internal use.
Another thing that works for me is conferences. I find it really valuable to attend conference from other ecosystems. It’s great to talk with people and discuss problems. Also, at the beginning everything is new, so I’m excited about each & every presentation. It’s so better to attend conference in person. You can easily join conversations, talk with presenter or just listen to what people are discussing during breaks. It’s hard to replicate that experience online. Communities could be helpful as well. For Go, I found Twitter community - GoLang Insiders & golang subreddit.
Getting Started: The When
I wrote about 80/15/5 rule earlier this year - Beyond the Code: Balancing Work, Growth, and Passion in Programming
- 80% on daily work
- 15% going extra mile
- 5% fostering curiosity
That 5% translates to about 25 minutes a day (1 pomodoro). Doesn’t sound like a much? Neither does compound interest until you check your account after 10 years.
The 100-Day Challange
Try 100x LAW (shoutout to Noah Kagan). Complete 100 iterations without fixating on the result. Focus on journey instead. That's roughly 50 hours (100 days × 30 mins/day) of focused learning.
To read more, check out:
What does “Knowing” a Language Mean?
And how long does it take to learn language? That’s hard one. There’s no objective measure of learning language. Everyone has a different perspective on what “knowing language” really means. For me, it’s when:
- I understand the core concepts & idioms
- I can read code without constant lookups
- I can implement simple features without feeling lost
- I can navigate codebase freely
It doesn’t mean I know ins & outs of the language. It’s not about every library nor framework. It’s about getting the fundamentals right.
The Plot Twist: When New Knowledge Backfires
When you learn new stuff, you can become frustrated with your current stack or even current job. That’s good. Use that energy to transfer some concepts. Try improving codebase. Try to use your new knowledge in current circumstances. There’re bunch of possibilities.
If your frustration hits limit, move on. There’re so many interesting & hard problems to solve. There are only few people that want to grow. Most won’t go extra mile. Most are fine with current job (or they even don’t enjoy programming). And that’s also good. Someone has to do that job. Someone has to maintain Java 5 or Angular 1.3.
Remember:
- grass is always greener on the other side
- everyone is different; that’s hard to believe but there are people who like to dwell and improve “legacy” systems
- few are going to do the work - most people are fine with current job & won’t go extra mile
Just keep grinding. One step at the time.