Lazy vs Eager Learning

March 13, 2024

There are a lot of opinions about the “best ways” to learn programming on the internet, but they’re usually some combination of the following:

  1. “Just write code” (“learn by doing”)
  2. Learn “the basics” (e.g. DSA)
  3. Learn certain technologies (e.g. React)
  4. Use resource x (e.g. books, websites, courses, video tutorials)
  5. Get a degree

By far, (1) seems to be the consensus. It’s also is also the most generic: (2)-(5) all refer to some specific resource or concept, while (1) is more of an abstract strategy.

When people recommend (1), usually usually mean the following:

The two are very tightly intertwined. Writing code almost always implies some degree of lazy learning; Lazy learning is much more general: it encompasses a lot of things, because the “necessary to know” clause can be imposed by anything1. The most useful way to use lazy learning is to purposefully make the target information “necessary to know” by beginning to write a program that requires it.

So, for the purposes of this post, we’ll use these domain-specific definitions:

Efficiency and Exclusivity

Lazy learning is incredibly efficient in most situations. It sets up a dichotomy between learning and failing: either you learn what’s necessary to write the program, or the program isn’t written. This is ideal, so long as you succeed. By its nature, lazy learning makes it easy to…

But all of this only happens if the learning succeeds: it’s possible (and sometimes likely) for this strategy to fall on its face. It’s only feasible to learn on-demand when that learning is relatively easy: if the knowledge-being-acquired is sufficiently novel or complex, the barrier to learning becomes so high that it can’t effectively be intertwined with coding. For instance, imagine a beginning programmer attempting to write an operating system from scratch: they wouldn’t know where to begin. The same idea holds for more experienced developers when attempting to learn concepts of similar novelty. Lazy learning can handle a finite amount of complexity before it cracks and eager learning is required.

Eager learning (e.g. reading books, watching tutorials, going to lectures) has its own set of benefits.

And drawbacks.

Both Are Necessary

If you want to become a proficient developer, you must have a wide range of knowledge and practical experience. To gain these, you must employ both eager and lazy learning.

If you avoid eager learning, you will2 be stuck working with the technologies and ideas you are familiar with, and you will be naive and bind to the world of possibilities within technologies unknown to you. You will have no mechanism for discovering new ideas, and you will be stubborn to change.

If you avoid lazy learning, you probably aren’t writing much code, which means the code you do write probably isn’t very refined. What you do learn is completely hypothetical and will likely soon be forgotten.

What’s the Right Balance?

Do whatever feels best for you, so long as you are avoiding the above pitfalls. Doing what you are excited about is the easiest way to make quick and effortless progress.

In general, lazy learning should occupy more time, because practical experience cannot be gained without writing code. This is likely the reason lazy learning is so highly recommended by internet programmers. Another reason might be the tendency for beginner programmers to find their way into into cycles of eager learning (“tutorial hell”), as lazy learning can be particularly difficult at first.

  1. By this definition, procrastinating studying for a test (or skipping lectures and letting lecture-videos-to-be-watched accumulate) is both lazy and eager learning. It’s lazy because learning is deferred until it’s necessary for the test, but it’s also eager because the act of learning it is proactive (since it’s a class, and it’s knowledge intended to be used in the future). ↩︎

  2. These statements are admittedly extreme, but I use them in attempt to make my point clear. Reality is more complex than this, but these are relatively true in generality. ↩︎