Start building the things that you want to build, and you'll learn what you need to along the way. This is the strategy that has brought me the most joy and, not coincidentally, it has also been the most effective by far.
Often, a basic, naive solution will give you the understanding and domain knowledge you need to be able to read what others have said about the same problem.
It also allows you to more easily dive into the solution as implemented by popular open source projects. Even if they don't write about it, you can often learn a lot from the code -- even more if the rationale is written in comments in the code.
For example, let's say you're contemplating how to implement an audit log for your product. You've never done this before, but you're experienced enough to know that you might hit unexpected hurdles (such as features that are difficult to implement) well into development, or maybe after deployment. Something you might do is research commercial open source products which have an audit log, and read their code to understand how they did it and perhaps why. Another way you can figure out the rationale is by looking at their full set of features and asking yourself how might each feature be implemented in an alternative implementation. If alternative implementations don't work well with this feature, this could provide an answer for why they chose this implementation over the other. And then finally, you can ask yourself if you need these features, which brings you answers to the original question of what are your objectives.
Or the short version: there are indirect ways to learn from the experience of others. Looking at a battle-tested implementation of a feature you want to add is one -- and it's perhaps even better (= more enlightening) than reading some blog posts you might find.
In reality you need to compromise, but by keeping the scope of learning projects artificially small you learn a lot about that one aspect and the trade offs involved.
For example when I wanted to learn more about testing for front end applications in Angular, I wrote all types of different tests for a small sample project. By doing that and reflecting on how I could incorporate all those tests at work, I learned a lot about structuring my code to be more testable, when and how to use mocks, Angulars built-in testing utilities and much more.
By going very narrow it's easier to go deep. You won't learn about all the side effects and interactions with decisions in other areas, but at least you know more options and can try to find a better optimum.
"I have no special talents. I am only passionately curious."
For my personal projects - I set up the Linux server, I set up the MySQL/MariaDB instance, I design the database schema which follows first normal form, second normal form. I design the REST API in Python, then I get to my normal job of coding an app for one platform. Plus I do the graphics, which normally the design group does. I also do the advertisement on Google Ads etc., I pay the bills and do the accounting and so on. So it goes beyond even tech skills.
Thomas Huxley said a good liberal education is to know something about everything and everything about something. I am not an expert in creating ads on Google, Twitter etc., but I have done it and know something of it. Same with sizing or dropping graphical icons. Or designing a database schema. Or figuring out my side project cash flow, profit and loss, having my accountant help me set up an S corporation. This is all the knowing a little something about everything.
In my day job I primarily use one programming language to target one platform. In this subject I go deep and really try to learn as much as I can. This is what my main focus is on, learning the language well, and learning the platform well.
I should also point out, the smaller a company is, the more hats you will wear. I worked at a small company where I wore not only a programmer hat but a devops hat. I set up Google Cloud, Firebase Firestone, Apache web server, and wrote and modified Python scripts. At a larger company (where I am now), 99% of the time I do none of these things (actually they like I have these skills and can interact with our devops team). It doesn't take long for specialization to kick in either, by the time of the second tech hire you're already dividing up work. It is important to know your main focus well on job interviews though.