Over the years I've seen many students succeed, but I've also seen many fail. The failures are more interesting to me, and I've come to develop a theory of why people fail to learn complex skills. If you're about to pick up a new skill, I think an understanding of why people fail can help you avoid failure yourself.
Most Fail Because They Quit
Without a doubt, the most common failure mode is quitting. I have very rarely, if ever, seen a student fail because they weren't "good enough" or "smart enough". Students that stick with it succeed, and students that quit fail.
This alone isn't enough to understand failure. Maybe if there were a handful of common failure modes it would be useful to talk about each one. But it turns out that to ask "why do we fail" is really to ask "why do we quit?" We can also ask the inverse, "why do we succeed?"
Frankly, it really is all about practice. I've never seen a student practice guitar for 1,000 hours and then fail. The same goes for computer science, the same goes for math and physics. Many people dislike Malcolm Gladwell's form of journalistic pseudoscience, but I've seen his "10,000 hours" theory play out time and time again.
Great -- so if you practice, you get better. This still isn't too helpful. If we're concerned about avoiding failure, we need to dig deeper still and talk about why people fail at achieving the practice hours they need. This is where it starts getting interesting.
What I've seen is that there are three primary reasons students quit: confusion, frustration, and boredom. There are others, but those three are the most common.
When both teacher and student solve those three problems success rates shoot way up. Let's talk about each in turn and discuss some ways to get around them.
Learning a new complex or valuable skill is difficult. If it were easy, everyone would know it, and it wouldn't be so valuable. Confusion is the first problem that students tend to run into.
Let's say you decide to learn computer programming as an example. The first question you're faced with is "what language should I learn?" Well, there are dozens. How do you choose from those? Maybe you know you want to write Android apps; it's good to have a specific target like this in mind, but even narrowing the scope only helps a little. Do you pick Java or Kotlin? How do you set up your emulator? What are all these tools you need? What is object oriented programming?
After that, you also need to understand the difference between a domain name and a host. There's shared hosting and virtual machines. If you want to run your own webserver, you've got to decide between Apache and nginx. Should I use DigitalOcean, AWS, GoDaddy, or one of the thousand other companies out there? Again, the ecosystem is vast.
Many students quit at this point. Stepping into a new world is incredibly daunting. I don't have numbers to back this up, but a good portion of people quit right here, before they even get started.
Frustration is a huge problem and is probably responsible for more failures than any other mode. Let's say you've figured out exactly what you want to learn. Now it's time to actually learn it!
But learning new skills is hard. Learning new things is hard. That's what learning is -- it's the process of going from not knowing anything about a skill or subject, to knowing lots about it.
Learning to program is frustrating. Why doesn't this code work? Why does my page crash? How come this doesn't do what I expected? There are also times when a student just can't figure out how to solve a problem. The patterns aren't intuitive to them yet. This causes a great deal of frustration, and often the student will put down the problem and never pick it up again.
I see this a lot with learning to play an instrument as well. Learning guitar is tough. The fingerings are awkward and often painful to a beginner. Transitioning from one chord to another is difficult. These students know what they have to do, but they don't have the muscle memory and articulation to do it yet. This is frustrating. Eventually the student puts down the guitar and never picks it up again. How many of your friends in high school got a guitar for Christmas one year, played for a week and then never touched it again?
I find that students will often make up excuses to justify their quitting to themselves. "My fingers just don't move like that" for guitar, or "my hands are too small" for piano, or "I'm just not a math person" for STEM subjects. These excuses provide a level of cover for the student to protect their egos, when the truth is that they've really just gotten frustrated and quit. If Django Reinhardt, who has only two fingers, can be considered among the best guitar players in history, I assure you that your fingers can move like that.
It's important to understand that frustration is a natural part of the learning process. It gets easier over time if you stick with it. I always tell students that there will be times when they get frustrated and want to quit. Just telling them that helps them get past it -- they now know that everyone gets frustrated and wants to quit at some point.
Learning a skill is more about practice than it is about play. Often students will get through the initial confusion and frustration, reach a level where they can play a couple of songs on guitar or throw together a couple of simple programs, and then plateau. The problem here is that continuing to grow this skill through practice becomes boring.
With computer programming, the types of homework problems you get in a 101 course (Fibonacci sequence, bubble sort, etc) are great practice, but frankly quite boring. Similarly, running scales all day on guitar or piano is boring. Students will often revert to play, ie, playing the same song over and over again without stretching their abilities, or else they get too bored with what it takes to reach the next level and quit.
At this stage it's important to be able to balance practice and play. Writing code to design 101-level algorithms is boring on its own; but finding a larger motivating project that requires those algorithms is not. Playing scales and practicing fingerings on its own is boring; but picking a challenging song that uses those scales is not.
This is a bit pseudosciency, but I claim that teachers and students need to figure out ways to trigger the dopamine rewards at this stage. Every hour of practice should be related to an hour of play, otherwise the student will say to themselves "this is not what I expected programming/guitar/physics to be like" and then quit. It's another ego-covering justification. Of course it's not what you expected; you didn't actually know before you started. But if your teacher only ever gives you practice and there's no play or larger goal, that skill will become fatally boring.
How to Succeed in Learning
If you want to succeed at learning (or teaching) a new skill, the ultimate goal is to rack up hours of practice towards the skill. This will sound a bit Malcolm Gladwell-y, but let's say that the three tiers of skill occur at 100, 1,000, and 10,000 hours of practice. Those tiers translate roughly to basic understanding after 100 hours (ie, having a rough understanding of how programming works), proficiency at 1,000 hours (ie, I could get a junior/entry level programming job), and expertise at 10,000 hours (ie, I can get basically any job I want).
To reach those tiers, you need to solve for confusion, frustration, and boredom. When I teach entry-level computer programming, for example, I teach "Building classic video games in Processing". Let's break that approach down.
(Processing is an all-in-one IDE and programming language based on Java; it's geared towards canvas drawing/animation and mouse/keyboard interaction. You don't see it being used "professionally" but it is a fantastic educational tool.)
Confusion: building video games in Processing readily solves the confusion problem. You use one tool as your platform. You write in one language. All the documentation and tutorials are in one place. It doesn't matter that you're not going to become a professional "Processing developer". Processing is simply the platform on which you become a programmer. Become a programmer first, and then figure out where and how to specialize. Don't worry about the huge ecosystem of programming languages, technologies, libraries, and so on, just focus on this one platform that you can install within second and immediately get everything you need to start with.
Boredom: when I teach this topic, I show students how to build Pong in about an hour in Processing, and then tell them to pick 5 other classic Atari arcade games and then go build them. Programming video games is challenging; you'll need to learn about data structures and algorithms, object oriented programming, and so on. It's also fun -- Processing gives you an immediate feedback look. Writing algorithms to solve the Fibonacci sequence is boring; the output is just numbers in a console. Writing video games is rewarding and gets that dopamine flowing. It also makes the process very tangible and visual. Accidentally making a number negative when it should be positive has the clear and distinct effect of moving something in the wrong direction. Overall, recreating these classic arcade games forces you to practice the skills while also contributing to the sense of play and work towards interesting and achievable projects.
Frustration: another reason I teach students to recreate classic video games is because they're narrower in scope than other types of projects students might be interested in. Deciding to build a new social network might be an interesting project, but it's way bigger than the student expects it to be. On the other hand, classic video games tend to be small and achievable. A novice can build Pong in a day. Breakout in two days, asteroids in three. Being able to start and finish many small projects is more rewarding than starting one giant project that has no end in sight. The scope of these games is well-defined, and that keeps frustration in check. It's a lot easier to avoid frustration when you're able to write out a list of 100 discrete tasks that need to be accomplished and check them off one at a time. You also know what the end product is supposed to look like.
Keep in mind that accomplishing 1,000 hours of practice might require 2,000 hours or more of total effort. If you're building your third video game, there's a whole bunch of stuff that you already know how to do -- setting up the canvas, setting drawing modes and colors, things like that. Those tasks might have counted as practice the first or second time you did them, but they no longer count the 10th time around. They're simply reinforcing the muscle memory; they become play.
The same applies to guitar or piano. It's only practice if you're doing something new(ish); it's only practice if it's hard. The first few times you play Wonderwall count as practice, the next 200 times you play it are just that: play.
For this reason it's important to continually level up by choosing more difficult projects as time goes on. Otherwise you'll plateau if you keep doing easy things; you'll rack up a whole bunch of hours that are all play but don't actually contribute to the development of new skills. Every project has a certain amount of boilerplate that goes into it, and as you develop more skill, a larger proportion of your projects will become boilerplate. This is why many students with years of experience may never become experts; if 99% of the things you do are things you already know how to do, you're not actually practicing anything new.
What About "Natural Skill"
What about the claim that some people have natural skills? Some people are naturally better at math, or art, or music. This is a big nature vs nurture debate, and I won't address the question of whether innate skills from birth actually exist. That said, it's clear that some students have a stronger starting point than others (whether that comes from birth or simply early childhood).
I believe that these natural abilities give students a small advantage that apply only at the very beginning of the learning process. Your natural skill in math or logic, or your previous exposure to technology might give you, say, a 20 hour advantage over the next person. Those hours apply only to the earliest stages of learning. If the goal is to reach 1,000 hours of practice, that 20 hour advantage doesn't count for a whole lot.
That slight advantage can be significant, however. I don't think it's significant in terms of the actual skill learned, but it is significant in the context of confusion, boredom, and frustration. Students that start with this advantage tend to get less confused or frustrated, and they're less likely to quit in the crucial first 100 hours. But for me the important point is that students that don't have those natural abilities can still learn the skill to the same degree as those that do; they just need to be more careful to avoid the pitfalls in the early stages.
A Note on Intuition
Ultimately, learning a skill and following it through into expertise is about developing intuition. Intuition is a form of muscle memory, but not just the physical aspect of the skill. Intuition is a sort of muscle memory related to both the practice and theory of the skill.
If you want to develop expertise, therefore, you must develop intuition. To develop intuition, you have to practice both the theory and the execution in lots of different ways. You need to experience, firsthand, how the theory applies itself to lots of varied situations, and how the interface between theory and environment manifests into execution.
Developing intuition once again comes down to practice. But it requires a different type of practice than the practice you need to develop the skill initially. You need to practice taking things you know, or things you think you know, and varying them, using them in different ways and in different places, with different audiences or different environments.
If you want to develop intuition for machine learning algorithms, for instance, you should write the algorithms from scratch lots of different times, in lots of different ways, in different programming languages, using different problem sets, using different constraints, using different parameters.
The way I see it is that every subject or skill is a highly complex multi-dimensional shape. When you solve a problem one way you illuminate one side of it and come to learn a bit of that shape. But if you want to truly understand the shape, to develop an intuition for it, you need to illuminate all the sides. This requires turning it around, redoing the problem, turning it around again, illuminating another side, and so on, until you've ultimately seen all the possible facets of your crazy, complex idea. Eventually you reach a point where you understand the shape of the thing so well that you can intuitively predict what will happen when you shine a certain type of light on it from a certain angle. This requires a thorough understanding of the theory as well as lots of varied experience and exposure; only then can you claim expertise and intuition about a subject.
Final Words of Encouragement
Everything I've experienced in my teaching life leads me to believe that you can learn it, no matter what "it" is. You absolutely can do it.
You'll be confused. That's what learning is. That's ok. Keep reading, keep grinding, keep practicing. You can, and should, limit the scope of the thing you're learning in order to make it less confusing. You can always expand the scope later.
You'll get bored. That's ok. Just make sure you have a bigger, motivating goal in mind. Playing scales is boring. Remind yourself that you have to do the hard parts so that you can get to the fun parts. Make sure that you have a fun part in mind.
You'll get frustrated. That's what practice is for. It's supposed to frustrate you. Practice enough and you won't get frustrated as much. And then pick something harder to practice, so that you get frustrated again. It's ok to get frustrated, it's part of the process. Take a break but make sure to come back later.
If you don't quit, you will learn it.