What language should you learn next?
When you get that thirst to #level-up as a developer, you invariably decide: What next?
Should you learn Go? Python? Maybe Cobol.
It doesn’t matter what language you think you should learn! (Spoken like Dwayne ‘The Rock’ Johnson)
After many years creating and enhancing software, I’ve found that the language doesn’t matter.
In fact, you’re selling yourself short by even thinking of yourself as a C#/JavaScript/[POPULAR_PROG_LANG_NAME] developer.
How should I think of myself then?
Firstly, save this article from Patrick McKenzie to read when you’ve got a few more minutes. The advice is timeless and you’ll be happy you read it.
The short form? Businesses looking to hire you care only about how you are going to help them by way of increasing revenue or decreasing costs.
In that light, being a JavaScript developer sounds more like a limitation than a feature.
Besides differences in syntax, programming languages all do just about the same thing. They all have logic and control flow statements, variables, looping, and large libraries to build on top of.
When you learn one, it takes very little time to learn another.
That’s why I say it doesn’t matter.
Another useful tip that comes to mind is the idea of just-in-time learning. Something I believe I originally heard about from Tim Ferriss.
If you spend time learning something that you don’t use right away, you’ll forget it.
What a waste of time, right?
What should I spend time learning?
With these ideas in mind, I’ve found that it is much more cost-effective to take a number of different strategies:
Learn language-agnostic, high-level paradigms and design patterns.
Although this is still susceptible to amnesia, higher level software design patterns and paradigms are more memorable because they aren’t as detailed and can be applied in more areas than just code.
Design patterns are also invaluable when you are building things from scratch. I can’t count the number of times I’ve felt handicapped by fear of building a new feature without a proper guiding pattern or framework to follow.
A good pluralsight course on design patterns
Learn ways to create business value with software
This is something I haven’t actually done but would do if I could start over. Learn about common pain points in businesses first, and then learn ways that software can improve those problems.
You’ll nail every job interview if you can eloquently explain exactly how you’d improve the prospective employer’s deepest issues, with or without code.
Common problems like growing or scaling a business are good places to start.
Learn a language while building something new
Finally, if you’re about to start a new role and you know you’ll be using a programming language you aren’t familiar with, learn the language in the context of building something.
Don’t spend time reading language syntax documents, line by line. Instead, pick something to build that’s related to the industry and use the language. You’ll without a doubt learn the most common features of the language in the process.