This is not about Pied Piper’s famous (and fictional) “middle-out compression.” Sorry to let you down. Instead, I’m making a point: that we learned “how to learn” the wrong way, and it’s not our fault.

When we (as humans) were doing our formative learning, we learned from the very baseline up. “Here are letters, these are numbers.” It was only later that we started to combine them to form more complex ideas, like language and math. And that’s all well and good for toddlers, but that’s not a great way to learn complex stuff fast.

From the time we start school, we’re all forced to start with chapter one and never skip ahead. You have to know addition before you can multiply, multiplication before exponents, etc.

I’ve found that’s a terrible way to learn almost any hobby or subject (except math, I guess). We’ve been taught to think that learning in this way will net us a solid understanding of the foundations.

We shouldn’t be learning that baseline first. If I want to learn how to change the spark plugs in my car, I don’t need an understanding of internal combustion first. If I want to try my hand at sewing a pair of cotton pajamas, I don’t first need to learn about the many types of fabric. And yet that’s how so many courses, books, and instructional videos start the process. It’s as if they’re teaching us an entire career instead of showing us how to sample one. Put another way, if I want to learn how to build a house I need to start with something smaller. But I don’t need to learn about all the different types of wood and screws to get moving.

For the sake of simple analogies, let’s assume software and house development are similar in complexity. You can start with the simplest shape (the sandbox), and work up to a medium sized project (a shed). One day you’ll have earned the confidence to build a house-sized project and beyond.

When it comes to learning a new subject, you should dive into the middle of that learning curve and work your way out. Codeburst wrote a great article on the 2018 web developer roadmap. I’m going to borrow their image for learning front-end development to make my point.

This roadmap view makes it seem like you have to dive deeper into each subject to properly learn it. Even worse, it might leave you with an impression that you need to know most of this to be able to function as a front-end engineer. In reality, you should learn what you need to get by. Let’s use that same example again, and let’s say you wanted to learn React. Your journey would look more like this:

The downside to this method is that the learning curve is more complex. Because you’ll be learning as you go, each time you dive into some new piece, your progress will slow down. That can frustrate some. But learning in this way allows you to focus on only learning what you need right now. It also (typically) means that your sandbox/shed is going to look a little funky in some areas. It’s the nature of “the first project” because at that point, you don’t know what you don’t know. When you learn by doing, you get a real-world experience that teaching can’t match. It’s those insights that create better, future projects: more stability, lower cost, better use of time, etc. This is also a good way to become very quickly familiar with the tools and materials you’ll need to use to get it done.

So dive into the middle of the next project you need to learn. Don’t build something just to learn. Build something you actually need/want and don’t expect perfection (this is key). By the time you finish your first project, you’ll have insights that take much longer learning the traditional way. You won’t know it all, but you’ll know “enough to be dangerous”, as they say.