How To Learn Stuff Quickly

It's often said that the internet has democratized education: the sum of human knowledge is only a Google search away! And yet, having access to information is only half of the story; you also need to be able to convert raw information into usable skills.

For a lot of us, the gap between the two can lead to things like tutorial hell—getting stuck doing tutorial after tutorial without ever feeling like you're making substantive progress.

Learning how to learn effectively is super important, especially as a software developer; learning new things is practically the whole gig! If you can learn to quickly pick up new languages/frameworks/tools, you'll be able to be way more productive than the average developer. It's sort of a superpower.

In this blog post, I'll share what I've learned about learning, and show you how I pick up new skills lickety-split!

Broadly speaking, there are two categories of learning:

1. Guided: Reading a tutorial, taking a course, watching a YouTube video. Anything where you're following a guide.
2. Unguided: Creating your own projects from scratch, extending a tutorial, looking things up in the docs. Anything where you aren't following a guide.

If you only follow guided resources, you'll wind up in tutorial hell. You won't develop the problem-solving skills needed to succeed as a developer. When you try to build your own project, you won't know where to start. It will feel like you've spent so much time practicing without developing any tangible, practical skills.

On the other hand, if you focus entirely on unguided learning, it'll take forever. Without an experienced guide, you'll need to reinvent every wheel, spending days or weeks solving already-solved problems. This is a long and frustrating road. In the worst case, you might wind up quitting altogether, convinced (incorrectly!) that you just aren't smart enough for this stuff.

Some courses are aware of this dichotomy, and will include opportunities for unguided learning. Things like stretch goals, thought experiments, and challenging exercises. I wish these types of resources were more common!

Let's look at some ideas for how to mix some unguided learning into guided resources.

If you're anything like me, you don't like making mistakes. You want everything to go perfectly, the very first time.

This mindset is generally helpful in life, and it's helpful in other fields. If you work as an auto mechanic, mistakes can cost hundreds of dollars in parts. If you work as a dentist, a mistake might ruin someone's smile.

With software development, though, mistakes are free! If we make a mistake, we can tab back to our editor, change the code, and try again. We even have helpful error messages that can (sometimes) point us in the right direction. This is an incredible luxury, and not one that we take advantage of enough.

When I follow a tutorial, I like to play with the code. Instead of copy/pasting the provided code verbatim, try experimenting with it: what happens if you omit one of the lines? Or if you change some of the values?

I try and act like a scientist. If I have a hypothesis about how this code is supposed to work, I test that hypothesis by changing the code, and seeing if it breaks in the way I expect. When I discover that my hypothesis is flawed, I might detour from the tutorial and do some research on Google. Or I might add it to a list of "things to explore later", if the rabbit hole seems to go too deep.

This process helps us avoid the sinister rhythm of following a tutorial on autopilot, copy/pasting code without really understanding what it does or why we're doing it.

Learning is an active process. Poking and prodding at the code will help us build a mental model for what's going on.

Let's suppose we're learning React by building a tic-tac-toe game, following the official tutorial.

By the time you've finished the tutorial, you will have created a fully-functional yet pretty-minimal game.

There are all kinds of fun bells and whistles we can add to it:

• Keep track of how many games each player has won
• Enhance the UI with more presentational components
• Allow the board size to be configured (4x4, 5x5)
• Add an AI that the player can play against
• Whimsy! (animations, sound effects, confetti on victory, etc)

Be creative, and pick things you're genuinely interested in!

This strategy is nice because you avoid the stress of a blank canvas. You already have a fully-functional, well-understood project. You're adding bricks to a solid foundation.

It also has a nice side-benefit: if you add significant extensions to a tutorial project, you can take credit for it in your portfolio! I cover this strategy in depth in my book, Building an Effective Dev Portfolio.

Once you've finished the tic-tac-toe project, you might be a little unsure about what to do next.

Before hopping onto another tutorial, it might be a good idea to try building a similar project from scratch.

For example, maybe you can make a bingo game! You'll be able to leverage some of your new skills (state management, event listening), but in a slightly different context. You'll likely hit a point where you don't know how to do something, because it wasn't covered in the tutorial; you can do some sleuthing on Google to try and find a solution!

If you really can't crack it, you can set this project aside for now. Do a few more tutorials, and then check back later to see if you've learned enough to unblock yourself.

I've seen this strategy described as "one on, one off". Follow a guided resource like a tutorial, and then spend an equal amount of time creating a similar (but unguided) project. If the tutorial shows you how to build an Instagram clone, try building a Twitter clone on your own!

Many years ago, I went bowling with some friends.

I didn't do well. Most of my balls wound up in the gutter. By the end of the game, I had the lowest score out of the group by far.

There are two different ways to interpret this scenario:

1. I'm just not good at bowling, and I never will be. Bowling just isn't my thing.
2. I'm not good at bowling. If I want to, though, I can become an excellent bowler.

There is a self-fulfilling prophecy aspect to this: whichever interpretation you choose will be correct. If you think that your level of bowling skill is fixed, it will be. If you believe that you can improve, you will!*

If you want to learn new skills quickly, it's critically important that you cultivate the right mindset.

Things never go smoothly when it comes to software development. Inevitably, we'll hit a rough patch where the code doesn't do what we expect.

This can either lead to a downward spiral—one full of frustration and self-doubt and impostor syndrome—or it can be seen as a fantastic learning opportunity. Nothing helps you learn faster than an inscrutable error message, if you have the right mindset.

Honestly, we learn so much more from struggling and failing than we do from effortless success. With a growth mindset, the struggle might not be fun exactly, but it feels productive, like a good workout.

Learn more about cultivating a growth mindset.

We live in a world of social-media hype, and it's easy to feel pressured to stay current, to learn every trendy JS library that floats by on Twitter.

Personally, every time I've tried to do this, it hasn't worked out. 😅

I'm just not particularly motivated to learn for learning's sake. In order for me to stay motivated, I need to have an exciting and concrete goal in mind.

For example: a few years ago, I discovered Beat Saber, a VR video game. In this game, you attack blocks with lightsabers, timed to music. Every song has a unique choreography.

Software existed to let users create their own choreographies (known in the community as “maps”), but I wasn't a big fan of it. I wanted to build my own map editor for Beat Saber.

After a few months of hard and occasionally-frustrating work, I achieved my goal:

(If you're interested in this project, you can view it live, check out the code on Github, or watch a conference talk about its development!)

Prior to this project, I had no 3D experience, and I had to learn a ton about WebGL, Three.js, and react-three-fiber. Learning is hard, and no matter how cultivated your growth mindset is, there will always be days where things just don't go well.

But because I had a concrete goal, something I really wanted, I was able to push through the frustration and continue making progress. If I had been learning this stuff just for fun, or because I thought it would look good on my résumé, I would have probably given up pretty quickly.

Different people are motivated by different things, so I don't mean to imply that you need to find a niche project to build. But I do think it's important that you have a goal in mind, something you're truly excited about. Otherwise, it'll be hard to sustain the motivation required after the initial novelty wears off.

I have a terrible memory.

This can be a bit problematic; it's hard to learn stuff if you can't remember things! Fortunately, I have a system: spaced repetition.

Here's the core idea behind spaced repetition: in order to strengthen a memory, you need to access it right as it's about to fade away. And every time you strengthen a memory, it lasts just a little bit longer.

It sounds complicated, but there are tools that can keep track of this for you. Personally, I use a leitner box, a physical box that holds a few hundred index cards. Every day, I'll review a small handful of cards.*

If you're interested in learning more about spaced repetition, I strongly encourage you to check out this explorable explanation by Nicky Case: “How to Remember Anything Forever-ish”.

Let's suppose that we commit to spending 7 hours a week learning something new. Do you think it's more effective to spend an hour a day on that activity, or 7 hours on Sunday every week?

Anecdotally, I've had way more success spending small amounts of time more frequently.

I recognize that not everyone has the luxury to structure things this way, but if you can manage it, I'd strongly recommend trying to spend some amount of time every day on the thing you're trying to learn.

I have some hypotheses about why it's so much more effective for me:

1. Every night, the brain processes and commits what you've learned that day. I want to take advantage of this every day, not just once a week!
2. Because I practice every day, I can pick up right where I left off. I don't have to spend a ton of time refreshing my memory and ramping back up.
3. As we've talked about, it can be hard to sustain motivation after the novelty wears off. If you can work it into your daily routine, you don't have to worry about motivation as much; it becomes something you just do, regardless of how you're feeling.

I'm a big fan of Swyx's Learn in Public philosophy.

The main idea is that by publishing what we learn, we help our future selves. When we discover something new, we should create an artifact that documents it, like a blog post or a tweet or a YouTube video.

This can feel a bit counter-intuitive; why would you spend your "learning time" writing blog posts? Isn't that a big waste of time?

There are a ton of benefits to learning in public, but here are the ones I've found:

1. Have you ever tried to explain something to someone, only to realize that you don't quite understand it as thoroughly as you thought you did? Writing a blog post has the same effect. It's the best way to uncover flaws/holes in your mental model, so you can fix them.
2. The worst feeling in the world is hitting a bug that you know you've solved before, but you can't remember how you solved it. If you had written a blog post about it, you could reference it!
3. By sharing what you learn, you become an active participant in the dev community. You can make friends and connections. This can be fun and fulfilling, not to mention beneficial when it comes to finding a new job or starting a new enterprise!

One word of caution: don't fall into the trap of spending weeks setting up the perfect blog from scratch! Start by publishing on a platform like Dev, or even just on Twitter! I published dozens of blog posts on Medium before I built my blog. If you discover that you really enjoy learning in public, you can always migrate to a fancy custom blog later. 😄

Recently, I started teaching myself how to create 3D illustrations using Blender.

I'm still a beginner. At this point, I'd say I've invested maybe ~150 hours into the skill. But I've been able to create some decent-looking art. Here are some of the things I've made:

I've been able to learn so quickly by following all of the techniques laid out in this blog post. But there's one other ace up my sleeve: complementary skills.

The thing is, 3D illustration isn't a single skill; it's a collection of dozens of individual skills. Some of these, like creating 3D models, were totally new to me, and I had to learn them from scratch. But some of them are part of a constellation I have experience with.

For example: I'm a bit of a hobbyist photographer. Years ago I learned about composition, how to arrange elements within the viewport for compelling shots. I can leverage those skills when positioning objects in my renders.

That's a particularly concrete example, but others are more nebulous. I've spent years and years developing an eye for detail in my work as a front-end developer. All of that pixel-pushing has helped me come up with suitable values for bevels and thicknesses. And my work doing UI design has helped me understand color theory and aesthetics.

You wouldn't necessarily think that the skills I already have would synergize with 3D illustration, but it's given me a ridiculously unfair advantage.

The way I see it, skills are like wealth. The more skills I pick up, the faster they accumulate. Ideas and techniques gleaned in one domain can help in another.

I'm not saying you should become a total generalist—it's still worth having pockets of deep expertise! But the wider your skill network grows, the bigger your advantage will be when it comes to learning something new.

Sometimes, learning resources will take advantage of that idea. For example, I'm working on a CSS course, CSS for JavaScript Developers. I'm building it specifically for JS developers, because I know I can leverage a bunch of pre-existing knowledge to make it easier to learn CSS. Instead of starting from ground zero and building up from nothing, we use your knowledge of JS to explain CSS, copy/pasting the mental models you already have.

My goal is to change your relationship with CSS. So many JS developers find it frustrating and counterintuitive. If you want to level up your CSS skills, you can learn more about the course.

I covered a lot of ground in this blog post, and I really appreciate that you made it all the way to the end 💖 Best of luck on your learning journey!