Learning to learn

“Read the docs. Struggle. You’ll learn how to learn. It’s really important for you to be able to do this as a developer.”

What does “learning to learn” mean? (in the context of developers googling and reading the docs in order to figure stuff out)

Well, what does “ability to learn” consist of? (loosely; and in this context)

• Knowing where to look. Knowing what sorts of terms to google, how documentation is usually structured, what blogs to consult, how to use Stack Overflow, etc.
• Being persistent. Having the emotional capability to not give up too easily.
• Knowing when to quit. Stubbornness often interferes with this.
• Knowing when to ask for help. Pride and shyness often interferes with this.
• Knowing how to break problems into their components. This (obviously) is huge. You have to be able to figure out what it is exactly that you don’t know.
• Being able to construct a mental model. When programming, you have to keep track of many different things and how they relate to each other. Most people try to store this model in their head, and so short-term memory capacity is important. But having the sense to diagram things out when appropriate is also important.

Does struggling through the docs help you “learn to learn”? Let’s use my bullet points above as an operational definition of “ability to learn” and explore this question.

• Knowing where to look. This isn’t too difficult. Once you hit a certain point, there isn’t much more to learn about this.
• Being persistent. In my experience, people get a little bit better at being persistent, but their ceiling is largely determined by their personality.
• Knowing when to quit. Same as above: people get a little better, but their ceiling is largely determined by their personality.
• Knowing when to ask for help. Same as above.
• Knowing how to break problems into their components. I’m not sure exactly what I think about this. I view learning as “there’s a concept you want to learn and it has dependencies; ie. you have to know A, B and C before you can learn the concept”. Basically, I think that for these types of problems, you can’t really do a deep analysis and break them down too far because there are too many dependencies in your way. I’m not really sure though. However, I do feel pretty sure that it isn’t the optimal way to get practice in developing your ability to break problems into their components.
• Being able to construct a mental model. Pretty much the same as above.

I’ve hinted at it, but I think there’s one more *crucial* factor that determines ones “ability to learn” — what you already know. I said that I view learning as “concepts have dependencies”. The more knowledge you already have, the more “building blocks” you have to work off of. The building blocks that you do/don’t have play a large role in your ability to learn.

I think that in the average case, the amount of “building blocks” you have completely overwhelms the other factors. To the point where your ability to learn is mostly a matter of how many building blocks you have. Sure, there are some people who really don’t know where to look, or who are really bad at being persistent. But once you hit some sort of low threshold, I think it’s mostly a matter of how much you already know.

Implications

A lot of people think that it’s good for you to struggle with something because you’ll “learn how to learn”. I don’t.

I think it’d be better for someone (or some resource) to just explain the answer to you. That way you’ll acquire building blocks faster and more thoroughly. When you have a) more building blocks and b) building blocks that are linked together nicely, it’s easier for you to learn. I think that the benefits of this outweigh the costs that come with not spending the time struggling.

Practical points

To make a practical point, most of the time spent struggling isn’t productive time. Productive time is when you’re breaking the problem into its components, figuring out what you don’t know etc. There’s a lot of what I’ll call unproductive time spent trying to understand poorly written explanations, chasing false leads etc. (I’m pretty sure you know what I mean).

Another practical point: if you want people to learn the things in the bullet points, teach them more directly.

• Show people what the good resources are. Don’t just have them figure it out on their own.
• Call people out when they give up too easily. Explain why/if they’re being irrational (undervaluing the benefits to their future self and overvaluing the short-term pain of persistence).
• Call them out for being too stubborn to give up (they aren’t spending their time optimally; the terminal goal is to learn the most, is persisting the best way to do that?).
• Call them out for being too prideful and/or shy to ask for help.
• ^For the above 3 bullet points, these are things that are largely personality-based and are highly resistant to change. If you want someone to get better at them, you pretty much have to call them out and talk to them about it. You can’t just expect them to get better by struggling themselves (at least in my experience, people don’t change these things).
• As far as developing the ability to break problems down, I think this too can be better taught more directly as opposed to having some figure it out on their own.