It took me decades to find a "learning routine", but it now looks like this:

1. Imitate. Find a way to boil down what I'm looking at to "monkey see, monkey do". Kindergarten songs and projects. Tracing the letters. Making the same poses as the athletes.

2. Isolate. Look for the drills that simplify the goal to particular success benchmarks. E.g. "drawing" -> "draw the outline without looking at your paper(blind contour)". Turn the isolation into a primary warmup for the activity.

3. Improvise. Now it's time to actually start making new things and integrating the concepts, using the structure from the previous practice. Improvisation can be practiced with games and challenges that are loosely structured(see: actual short-form improv games like "Five Things")

The learning in tech always tends to have either a "hardware up" approach(computer engineering, operating systems, low-level protocols) or a "abstraction down" approach(problem domain languages and application interfaces). The parts in between get swept up and rearranged with great frequency; they are the implementation detail, and may have some incidental automation, but usually they just reflect Conway's law in some form - they become standard because the situation asks for a standard, and then politicking proceeds to take over as career-minded individuals jump on board and try to steer the technical conversation their way, to their standard, where they will receive credit. We also keep coming up with new things to automate, motivating new problem domain abstractions.

Thus: you stand to gain a ton by closely examining the roots of the systems you work with, just sitting there with a pen and a notebook doing the earliest imitation processes on their code and documentation. Proceeding to the more isolated parts of building an actual project with the system is often superfluous, if you've encountered the main concepts before.