Back in the day (in my PHP days), I just built a ton of things. Not many projects were finished or even deployed but I had some fun doing them.

That’s my preferred way of learning things as well. I have not idea how many projects I have started building but gave up again down the road. If I should try to make a guess, I’d say I have 5-10 such projects a year. Some of them are never intended to become anything, and are just pure experiments (try a new approach or a new language). Others have practical usage, but I either lose interest or time.
Usually that doesn’t bother me, as I mostly do these spare-time projects because they are fun and I keep learning (should they turn out to be anything more that’s just an added bonus).

I also have a couple of projects where I adapt some open source libraries / applications to fit my needs. My only regrets with those projects is that I don’t get them pushed upstream often enough.

So basically, I learn best by actually building things.

I agree with what the other say, about building new projects. and try to experiment with new technologies is often a big leap forward.

But there are three points that helped me a lot so far:

1. Automate Things

I think the biggest step for me was to learn shell script and help myself and others to automate routine tasks.
I have several people around me who go great lengths and tedious workflows just to avoid the shell. I developed an attitude that, after doing a stupid task several times, I start to think how this can be automated.
I have gone so far to internalize the good old “Is it worth the time?”-xkcd

In hindsight this already provided valuable lessons for programming with elixir and thinking in pipelines. These small tasks offer a great opportunity learn to think about problems in the right scope, they offer fast
rewards and the risks are not high.

2. Reading

I encourage everyone to read not just docs about programming languages (but those too, of course), but also essays about the ideas behind them, like Hackers and Painters by Paul Graham. I see this as an important way to see what other concepts are offered by different approaches.

3. Switch to Emacs

Another big chance to learn was when I migrated from vscode to spacemacs. I never assumed that this would improve my skills as a software engineer (beyond an increase in speed, I guess), but I think it did. By learning some fundamentals of emacs, I had so understand the fundamentals of lisp, which in turn reminded me about central concepts of programming languages (like the abstract syntax tree). This again helps me now to cope with thinks like ets.

Disclaimer: I do not think that emacs is necessarily the best editor for everyone and everything, but I perceived some benefits after migrating to it. This might also be Stockholm Syndrome.