What programming language should you learn? Check this out.

Over the past few months, I've had the pleasure of teaching a wide variety of people Python, JavaScript, Ruby, command line, APIs, NodeJS, HTML/CSS and a bunch of the technical notions that come alongside.

The people learning are all brave individuals taking their first steps into the world of Tech, Digital and Data. Hence they all share the same question:

(P.S. The TL;DR answer is at the bottom if you only have 30 seconds to spare)

And it really is a great question. Sometimes this question even has a correct answer - for example, there's really only one way to build a WeChat Mini Program.

In other cases, I used to try and answer this question too, and that answer was typically followed by the student saying "but what about Rust/Go/Swift/Julia/R/TypeScript/Dart/Kotlin/etc...?" and me going "uuhhm... yes, there's also that".

And they are totally right! There are quite a few different options. In fact, asking 10 different developers for their recommended language, we might reach 10 different answers. And then there's also a score of frameworks for each!

And the same goes for the things we read online. I just Google'd "top 10 programming languages" and found three different indexes with a total of 19 different languages.

Great, as if the choice wasn't hard enough already

So, in this article, I won't give you yet another top 10.

Instead, I hope I can introduce a new mindset around this question. Hopefully, these thoughts will help you make a decision quicker and get started on your first project!

I am not an experienced developer. However, I have been learning a wide range of languages and frameworks through teaching others and collaborating with our awesome developer community.

And a lot of them will probably hate what I am about to say. ‍♂️

As far as things you can achieve with code, 90% can be achieved with any language or framework.

(P.S. I will refer to "programming languages and frameworks" as "Tools" from now on, so my fingers don't get tired. ️ )

Clearly there are languages which have their own place and purpose - HTML for front-end, Ruby for back-end, etc - these divisions won't be discussed in this article.

Think about a regular website. Does it function very differently from another website? Doesn't it have buttons, links, text, images, just like another website? User login, user registration, booking/buying something? Behind the scenes, there are dozens of different Tools to build these websites. But the end result is not that different in terms of technology. So maybe the choice of Tool is not that important either?

Indeed, each Tool does sport differences over others - otherwise, they probably wouldn't exist. Static vs. dynamic, more verbose vs. less, OOP vs. functional programming - these are some of the things that might tip a person to one language over another. But most of these things are not about what the code can do, and more about how you prefer to write and structure your code.

And how will you answer that question, if you are still considering which language to use??

Certainly, some Tools will also perform better than others - our technology is evolving after all. But in most cases, that 10% difference will only be noticeable after your product is already producing value and definitely waaaay beyond your MVP.

If you spend all this time thinking about those last 10%, how will you ever complete the first 90%?

Code is a tool.

The goal is not to write code.

The goal is to solve the problem. Code gives each individual a way to do that.

Once you adopt this mindset, a lot of the choices of Tools become arbitrary. You will start using the Tools which make you the most efficient and that is exactly the goal. Naturally you will encounter limitations of the Tools you are using. But then you will simply pick up a new Tool and keep moving.

At Le Wagon bootcamps, students have two weeks to build a product of their idea from scratch. Sounds intense? It is. They nail it every time

But with this kind of pressure, each person pitching their idea will naturally ask "but will we be able to build this with the tools we learn in 7 weeks?". My answer is always the same - tech is never the question when you have an idea.

Most of the things you and I will build will be a collection of features which tie together to help a group of people make their lives better. Potentially enough so that they will want to pay us.

When we break down these big products into features, we'll notice that each of those features can be implemented using any applicable Tool.

Remove some non-essential features, enhance key ones - you have a solid product that people want to use.

Got a 100k people who want to use it every day? Might be time for a new Tool. But get there first, and fast!

The best thing about working in a tech role? You are paid to learn new stuff.

Careful now. This doesn't mean that you need to learn a new Tool year after year. It means that the industry you are entering is constantly changing. It means that you should learn how to learn.

As a tech worker, you will be tasked with new problems, new bugs, new improvements every day. You will need to spend time reading about updates in the tech you are using, looking at other people's code, parsing the Internet for answers, plugins and useful tricks.

It's an exciting place to be in. But it can also become overwhelming if you're not used to doing your research. I've noticed that really good developers spend more time reading code than writing it.

Documentation, StackOverflow, GitHub repos, forums - these tabs should always be open when you are working with a new Tool. Particularly because you are never safe from our little friends...

And it's also something that a developer does. A lot.

Bugs are an inseparable part of programming. If you're coding without bugs, you are probably not stretching your skill level to new heights. Hence, it's important to learn how to deal with bugs.

During the bootcamps of Le Wagon, we often see students panic when they encounter their first bugs - "oh damn, it's all red, what happened, where to look, what to do, HALP!".

That's where I started too. Now I often help people debug in languages and frameworks I've never used before.

Regardless of the Tool, you are learning, do spend time with your bugs. Read the error messages, check the trace, see where the error is coming from, the test that part with debuggers or by printing stuff out. DO NOT click on that "Check Solution" button just yet! DO NOT stare at your code blankly thinking "why doesn't it work".

Bugs and debugging will always be there, regardless of whether you are just starting to build your personal page or you are working on the next SpaceX shuttle.

And when it comes to bugs, the saying of 3-times Tour de France winner Greg LeMond applies:

So you should already start learning the gold skill of debugging now because it will apply to any Tool!

As far as things you can achieve with code, 90% can be achieved with any language or framework. (where applicable, of course)

If you also have tips for what and how to learn, please drop me a comment. Stay curious, keep building.