Creating Projects Isn't The Best Way to Learn

"How to learn to code fast" might be one of the most popular Google searches. And you can find plenty of advice online. Typically, the answer is "create your own projects".

When I studied music, the question was similar - how do you get good fast? The advice was the same. Play concerts! Simply play.

Creating your own projects makes a difference, and it's the logical next step after you've internalized the absolute basics. But it's neither the fastest nor the best.

It's true; there are problems you'll only encounter in practice: Your code becoming too complex, requirements your libraries don't support, or in music, less than ideal lighting and monitoring on a foggy club stage.

You will learn from solving these problems. However, you'll keep using your existing vocabulary - the last working solution can also be applied to your current problem, so you solve it the same way.

What's the issue here?

Your vocabulary doesn't grow if you don't build it. The only reason to devise new solutions is for problems you can't solve with your existing vocabulary. Those problems become rarer over time. So, instead of building your vocabulary, you are rehearsing your existing one.

A single solution might fit ten problems, but it could be a crappy solution for nine of them. Besides, if you encounter a problem you can't solve with existing solutions, it's difficult to come up with a pattern you have never seen.

So, what is a way to keep growing instead of repeating what you already know?

It's a process I call "transcribing".

In music, I learned most from listening to the great players and their recordings. You imitate them, and you learn their parts, note for note.

In coding and even entrepreneurship, you can do the same: Look at the code of the greats and imitate the patterns of their repositories. Study successful entrepreneurs' marketing campaigns and product validation strategies and apply them yourself.

The trick lies in the balance, though.

You should keep working on your own projects. All newly found solutions need to be for real-world problems and goals.

But if you encounter a situation where you're recycling a suboptimal solution, one that you use simply because it was the first one available, pause for a moment and look at what others have done.

To supplement this actively, make time solely to study others, even without an actual problem. A couple of hours per week is plenty - three hours to read through a repository or a SaaS case study.

You'll get back the time since you'll be quicker in your own projects. (If you disagree, riddle me this: Why do people pay huge sums to consultants who can improve your company's bottom lines, consultants who merely give you advice to imitate?)

Again, make sure to ground everything in the real world. It's stupid to study patterns of SaaS products if you sell courses. There might be some nuggets there, but it's unlikely.

Balance is key.