Learning doesn't have to take that long

Here is how I approach learning a new skill and why I think you should do the same

Hi there! How have you been?

Lately, I’ve been thinking about the path every developer takes to learn a new skill, be it a new language, a new tool or even a whole new paradigm. Learning is a key skill in itself for us in this industry, since it’s something we’re constantly doing, and the faster you can get to a point where you can utilize that new knowledge, the more efficient of a developer you become.

Notice how I didn’t say “the faster you learn something”, though.

Learning vs making use of a new skill

There is a difference between “learning” something to a point where you can explain it to others and simply being able to apply that new knowledge to your work and get something out of it.

Think about them as 2 different states.

In the first state, you’ve integrated that knowledge into your day-to-day, you’ve explored every nook and cranny of this new practice and you’re ready to exploit it however you want.

The second state, however, only allows you to use part of the knowledge you’re learning. You’re able to improve your current work thanks to it, but you don’t fully understand it yet.

Many developers think that learning means reaching that first state, skipping the second one altogether.

I’d like to disagree.

Being an expert is overrated

I know how that sound, but consider the time it takes to become one and the number of different branches of knowledge there are in our industry.

Do you honestly think you have the time to become a true expert on web development, OOP, functional programming, Machine Learning, Data Engineering, Software Architecture, PHP, Ruby, JavaScript, Python, and on, and on, and…. on?

Let me answer that for you: No you don’t have the time.

I just listed a few areas that I can see being related and overlapping at some point in time during the career of a developer. But there are more, and the more you learn, and the more areas you interact with, the better of a developer you’ll become.

But do you really need to be an expert on all of them? The answer is “no, you don’t”.

Here is how I approach learning about something new

Look, this might work or it might not for you, everyone learns differently and through different means. Some of you are more visual learners, others most likely would prefer to practice vs learning theory, etc. So take what I tell you and adapt it to your own learning process.

Take the example of learning Git. That’s a skill most developers should have right now, since it’s one of the top version control systems out there and you’re more than likely to use it on any job you get.

If you’re picking up Git for the first time, learning how to commit code is easy, just read about git add, git commit and then git push.

Boom, you’re done!

But when you start scratching the surface of the Git command, you’ll start seeing that there is a lot more than meets the eye. You start learning about rebasing, commit hashes, logs, refloging, cherry-picking, different merging strategies, and on, and on.

And here is where some of you will dive right into it. You’ll assume that since Git is such an important tool, you need to master it right away.

So you’ll start reading documentation, getting courses online, and asking other developers what cherry-picking is and how you can use it.

And then when you hit that wall where you just don’t understand a concept, you get discouraged. You think you’re not ready, the impostor syndrome sets in and you’re looking around waiting to be fired.

You don’t need to go through this.

What should you have done instead?

Mastering a tool or a skill takes time. But more importantly, it takes practice.

You can’t hope to master anything by reading about it and testing a few things on your own.

If you truly want to master Git, you will, trust me, but over time. After you’ve been part of multiple projects with different branching models. After you’ve had to spend hours merging two commits and solving countless conflicts.

And more importantly, after you’ve screwed your local repos so much that you’ve had to clone the remote repo into another folder and started over.

In our industry, you’ll be more likely to learn something better through making mistakes. In other words, through practical experience.

Yes, it might seem like it takes longer, but you’re also able to apply part of the skill you’re learning a lot sooner and you can start seeing the benefits from it a lot sooner as well.

You’ll stay motivated to learn more, and you’ll also pick up on which parts to tackle first, based on your own needs.

The way I learn a new skill

I’ve been part of the software industry for almost 20 years now, and I’ve picked up a few tricks here and there.

When it comes to learning something new, I always try to do the same: I come up with a silly project, something simple that focuses on that skill/tech/tool. So I don’t get distracted implementing code that is not related to what I want to learn.

Then I read enough to get the basics of what I’m trying to learn working. I don’t go deep all the way, and whenever I hit that learning wall (when you get to a point where you just can’t understand the concept you’re reading about), I just try to keep going around it. I’ll come back to it later, but if I can get it working without understanding 100% how it works, I’ll go for it.

Why would I skip steps? There are two answers to that:

1. Because I just don’t need it to take advantage of the thing I’m learning. Maybe I’ll come back to it once I understand other aspects better, but right now I’m good.

2. Because even if I don’t fully understand the concept, if I can make it work, I can go back to it and play around with the code to understand how my changes affect that piece of knowledge I skipped. I’ll be able to learn about it by seeing the effects it has on the thing I built, which is a lot easier than trying to understand something without seeing it working.

I love learning by doing, that’s my “secret sauce”.

I can’t just read a tutorial about Remix Run for example, and consider myself versed in Remix. Instead, I’ll build my own simple project following some tutorials, and then I’ll start changing things here and there to see what happens. I’ll go back to reading about “server-side rendering” and “nested routes” once I have the basics under control, not before.

The more you can apply the basics in real-world scenarios, the better prepared you’ll be to tackle more complex concepts soon.

---

In summary, just don’t get hung up on things you don’t understand right now, focus on the things you DO get, and build around them. You’ll end up hitting those advanced concepts later anyway, but you’ll be more prepared for them when that happens.

What’s your learning process like? Do you also focus more on the practical side of things, or are you known for staying inside tutorial hell for a while?

Are you more of a theory person or are you more practical?

Leave a comment and let’s talk, I’d love to know what you think about this!