Which programming language should I learn first? This is perhaps the most popular question of all time in software development.

Becoming proficient in a programming language, especially your first one, is a long-term process that requires significant volumes of study and practice. It’s only natural that you want to make the best choice possible for your career, and to avoid putting all that hard work on the wrong option.

I’m not referring to the languages you would use in college out of necessity, as these are more or less imposed by each given curriculum. I’m talking about the one you intend to use at your first job, the one that will put the first buck in your pocket as a professional software developer.

The good news is that no matter how tricky it appears to be, making the right choice is not as important as you think. The truly important part is making a choice and sticking to it. Let me elaborate.

Defining your mission

There is tremendous power in being a specialist compared to being a generalist. Although this is a much broader topic that needs an entire book of its own, it’s vital to understand that choosing the type of problems you’d like to be solving as a professional software developer is the first and most important step.

Just think about how many types of lawyers exist; family lawyer, employment & labor lawyer, corporate lawyer, real estate lawyer etc. Would you hire a real estate lawyer to help you set up a company? Probably not.

Although all lawyers have graduated from Law School and have some general knowledge about different categories of legislation, every single one of them has specialized in solving a specific type of problems. That specialization allows them to be very focused and effective at what they do.

Although our profession is not (yet) regulated the same way as with lawyers or doctors, there are many problem spaces you can choose to specialize in. A few examples are: mobile applications, web front-end applications, desktop applications, distributed systems, embedded systems, computer vision, artificial intelligence / machine learning, and data analysis.

For each of these areas, there is a number of apt programming languages and tooling to choose from. These are not that hard to discover. If what you find online does not convince you, locate 5-10 companies in your broader area specializing at the same kind of problems you’re aiming to, look at which languages they use, and just pick the most popular one.

It all starts with what you want to do. Start with defining your mission, and the process of choosing a language won’t be that tricky. Committing to your choice, though, is a different story.

Commitment is king

Imagine that you’re driving to the mall on a Saturday morning, and as soon as you arrive you realize that the parking lot is almost full.

What do you do after you find a spot and park your car? Do you look for more spots? Do you try a few different ones to see which one works out the best? Or do you simply lock your car and go shopping?

The parking spot is just a means to an end. Focusing too much on that would be a waste of your time, and would keep you from doing what you actually came to do. A programming language is also a means to an end.

Your purpose as professional software developers is not the act of producing code itself, but rather solving problems and delivering value to real people through developing software. The longer it takes to pick your tool and learn it well, the less effective you will be in delivering value.

And trying to master multiple languages at once is not such a good idea. It’s like chasing rabbits;

Try chasing two rabbits at the same time and both will get away.

You might read this and think, “I don’t want to pigeonhole myself into a single language, I want to leave all options open. And what if my choice is not the right one?”.

We’ve already discussed about the importance of having a mission and aiming at becoming a specialist. Having that in mind, you can’t go that wrong with choosing a language. Therefore, in that context:

You’d rather commit to the “wrong” language from the very beginning, than delay and commit to the “right” one half-way.

My language is better than yours

The industry is a battlefield. Companies developing programming languages, frameworks and other developer-targeted products want you to pledge your loyalty to them, and they constantly fight for that purpose. They utilize every trick in the book, from influencer marketing to organizing communities and conferences.

The goal is to make you formulate certain perceptions about how their offerings are cool, superior to the competition and fit perfectly into the puzzle. Perceptions are powerful, but also often disconnected from reality. No amount of coolness or hype can replace usefulness.

Moreover, software developers enjoy debating and arguing about technology, especially programming languages. Each of them has invested their time and energy learning what they chose, and it’s only natural that they are quite passionate when it comes to explaining, defending, and selling their choices to others.

Unfortunately, these discussions often have a snobbish tone, with people trying to discredit other peoples’ choices in attempt to feel better about their own.

This can make the process of choosing your first language stressful and confusing.

Sometimes it even makes seasoned programmers suffer from developaralysis¹, a crippling sense that the industry is evolving so fast that they cannot possibly keep up. They come to believe that they are losing the fight, that their grass is not as green as their neighbor’s.

This line of thought is dangerous at its core.

Yes, your neighbor’s grass might be very green, but it’s only because your neighbor shows it love, he spends time and energy keeping it healthy and making sure that nobody steps on it.

On the other hand, if you start having doubts about your own grass, something inside you will change. You will unconsciously stop caring about it as much, and you will be holding back every time you try and look after it.

What is the most resilient parasite? … Resilient… highly contagious. Once an idea has taken hold of the brain it’s almost impossible to eradicate. – Cobb, Inception (2010)

Know the trap and avoid it. Commit to your choice, filter the noise out, and win big.

A guideline, not a rule

The advice on sticking to one language is more of a guideline rather than a rule. In some cases a different approach could be more appropriate.

A prominent example is full stack web development, where you need to learn JavaScript to build your front-end, as well as one more language that you can use to build your back-end with². Such an approach is challenging and more time-consuming than going after a single language, but it is viable as long as you pay an equal amount of attention on both ends.

I’ve met plenty of “full-stack” web developers who hold a grudge against JavaScript, simply because they were forced to use it at some point but they didn’t bother committing on learning how it works in depth. It comes as no surprize that they end up shooting themselves in the foot, but instead of taking responsibility they chose to accuse the language for their own failure.

If you don’t know how to play the violin, it’s not the violin’s fault.

Bigger fish to fry

Becoming a professional software developer has actually very little to do with programming languages. It won’t be long before you start putting pieces of the puzzle together and realize how many different elements are involved in this craft.

To provide real solutions for real people, you will need to know how to effectively work with people, and master several soft skills such as communication, collaboration, negotiation, persuasion and many more. At the same time, you will also need to learn how to properly approach any given problem, analyze, plan, execute, verify and reiterate if necessary.

Did you notice that the execution phase takes place towards the end of the process? That is where the programming language gets involved, and that is why jumping straight into the code as soon as a new business problem arises is hardly ever a good idea.

Especially at the first stages of your career you have bigger fish to fry than questioning your choice of programming language, trying to tackle more than one at the same time, or even debating with others about that choice. Focus on what matters the most, and that is becoming a great engineer.

Laser. Beam. Focus.

Going forward

What we’ve discussed so far will get you started with a bang and keep you going for a good while. The question is, what happens next?

As you keep progressing with your career, it is expected that your responsibilities will keep increasing along with it. It won’t be long before you find yourself in a position of higher stakes, where you will be expected to quickly learn, utilize, and be productive with an unfamiliar piece of technology on demand, whether that is a language, a library, a framework, a platform, etc.

In other words, you will be expected to use the right tool for the right job, not just what you already know. And since there are endless options out there, learning a piece of technology you don’t intent to use anytime soon is a waste of time. There is not enough life for that.

Treat your time as your most valuable asset.

Hence the most critical skill of all is to know how to teach yourself anything, and quickly. You need to learn how to learn, and be able to adapt to the ever-shifting Software Industry at a moment’s notice.

Mastering this particular skill is one of the best investment you can ever make. Should you choose to make it, I promise that you will never have to worry about the effort of learning another programming language, or any other piece of technology, ever again; learning will become your second nature.

Here to help

Not sure which language to pick up first? Drop me a line and I will be more than happy to help you make a choice. Don’t forget to subscribe to my newsletter for even more action!

¹ Source: TechCrunch

² Unless you build your back-end with NodeJS, in which case you’ll only need JavaScript for both ends.