So you struggle initially, and when you master the basics, the fun might begin, at last? Well, it is, IMHO, not so simple.
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.
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:
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.
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.
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:
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.
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.
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.