In my last blog post, I talked about what kinds of things people should do to make sure they're learning development as efficiently as possible. Almost immediately after publishing that post, I realized that I had neglected an important topic when it comes to learning: how to avoid overlearning.

What Does Overlearning Look Like?

Overlearning was definitely an anti-pattern that slowed me down in the earlier days of my learning software development. To be specific, I'm talking about overlearning in the forms of both:

• Spending too much time trying to learn or memorize peripheral details about a certain technology or subject.
• Having too wide a scope of subjects that you keep bouncing between, and not getting a strong grasp or deep knowledge of key related topics in any of those subjects.

A large focus of my writing about development is directed towards reducing decision fatigue and learning faster by staying focused, so I'm going to take a few minutes to talk about strategies to keep overlearning from rearing its ugly head in your development journey!

Be Strategic About What You Memorize

In a production environment, you'll often have to implement features or techniques you've never done before, so research is a vital skill for a developer. When you take this into consideration along with the overwhelming amount of HTML tags and attributes, CSS properties, JavaScript methods, etc, it becomes clear very quickly that trying to memorize everything is not the way to go. Here's how I recommend you approach what you should and shouldn't memorize:

• Is the knowledge a high-level concept that's integral to how a particular technology works (such as the CSS box model or the event loop in Node.js) or specific information you need to know to pass a test (such as S3 storage tiers and their costs for those taking AWS certification tests)? If so, you should put in an active effort to memorize that thing.
• Is the information a side-detail (such as what attributes you can add to an input tag in HTML) or a syntactical detail (like the syntax of an arrow function in JavaScript)? This sort of thing is better to look up as needed or to memorize passively through repeated practice of implementing the thing.

Aim for the Minimum Effective Dose of Knowledge

The Pareto Principle states that "for many outcomes, roughly 80% of consequences come from 20% of the causes". What this looks like in the real world would be when 80% of a company's effectiveness is a result of 20% of the staff, or that 80% of a web framework comes from 20% of its API. You should get used to figuring out what corners of a specific technology you're learning provide the biggest bang for your buck, and concentrate on having solid knowledge of those.

Keep The Scope of What You're Currently Working On Manageable

By far, the specific type of overlearning that hurt me the most early on was dabbling in a lot of different programming languages (Java, PHP, C#, C, Elixir, etc) that I don't specialize in when I could have been using that time to focus on learning the languages that I want to work with (JavaScript, Ruby). While seeing a variety of programming paradigms did help me see some common patterns and help drill in some high-level rules, the time I spent wasn't worth it in the long run.

To be clear, I don't think you should only ever learn one thing at a time. If you're brand-new to JavaScript and you're having trouble wrapping your head around a new concept like Objects, it can be good to shift gears to something like learning BEM in CSS to give your brain a break.

In Conclusion

The good thing about overlearning is that it's fairly easy to avoid once you're aware of it and what it looks like. Next time, I'm going to discuss how much HTML you need to know to be job-ready!