Some thoughts about learning curve

So you struggle initially, and when you master the basics, the fun might begin, at last? Well, it is, IMHO, not so simple.

Permalink to heading Fast Learning curve Fast Learning curve

It can be a language, a technique, a pattern, or whatever you want. You want to learn it quickly because you want to do something very concrete with it, such as an application or a website.

More pragmatically, you don’t want to spend your life learning something because you don’t have that time. You can’t afford it.

If you take Python, PHP, or React, they are very different programming languages, but they have something in common: people say they’re fast to learn.

It’s pretty much the same with frameworks and libraries. The learning curve is often a significant criterion to select your tool for your next project.

If you’d sell compilers or frameworks to developers, you’d probably use the “fast learning curve” argument.

Permalink to heading So you think you have learned? What have you built? So you think you have learned? What have you built?

How do you quantify your learning curve? Is that even possible?

Many portfolios use progress bars and percents to describe skills. You see that all the time:

JavaScript 80%

I’m not pretending I’m the truth, but I don’t understand why people overuse those figures. So you think you know 80% of JavaScript?

It’s probably wrong. Most of the time, it’s less. Even when it’s true, it does not matter. What matters most is what you can do with it and, above all, what you have built with it.

Permalink to heading What happens when you have learned What happens when you have learned

When you have built things and don’t have to look in the documentation every minute anymore, you start to have absolute certainty. As a result, you learn less intensively.

It does mean you’re unusually lazy. It’s human. Fighting against that natural inclination is hard but necessary because stagnating is terrible.

The solution might be to keep the beginner’s state of mind, especially when you start feeling comfortable.

Permalink to heading Solve problems every day Solve problems every day

There are A LOT of free resources developers can use to improve their skills.

It’s not an exhaustive list at all, but I like the following resources:

You think you are skilled or even an expert in PHP and JavaScript, try those resources and start solving mathematical problems and build concrete projects.

Note that Project Euler allows you to use many languages (such as Python, Php, Java, Kotlin, etc.) to solve problems. If you have the right answer, you unlock hidden pages where people post their solutions. Thus, you get the solution in various languages for a given problem.

I like this project because having the solution does not matter if your code is junk. Crazy loops over millions of items that take hours to run might allow you to solve the most fundamental problems (the first ones) but not the other.

It has to be super-efficient. It often requires recursions and other key-concepts for programming.

Permalink to heading Build more every day Build more every day

If you think you know everything in your area (which is probably wrong), start building more.

You don’t have to spend all your free time on side projects. Building small things every day is enough.

Are you tired of making websites? Start building games and applications.

Permalink to heading Wrap up Wrap up

Learning is a complex process. You have to find what works best for you. To me, nothing compares real challenges outside the comfort zone.

Having deadlines and goals is also a great way.