Should software engineers learn new things “just in case” we need them in the future? Or should we learn the things we need “just in time”, when we realize we actually need them?
The Just-In-Case vs. Just-In-Time terminology actually stems from inventory management. If you stock the materials you might need in the future, then you’re ready when you need them and there’s less of a lead time. However, you end up incurring overhead of storing those materials (in different forms like storage, damage, opportunity cost of money tied up in inventory etc) and the risk that you might not actually never need those materials. Companies like Toyota pioneered Just-In-Time inventory management and manufacturing, which meant short lead times, low overhead, and lean manufacturing.
The analogy carries quite well to learning new things. Just-In-Case learning, at an extreme, is basically what you get in school and college. You learn a wide variety of things that you will probably not need to use anytime soon. The problems with that are:
- You may actually never need the things you are learning. They might not come up in your career/life (I’m looking at you, History of Western Literature), or they might become irrelevant.
- You will probably forget most of what you learn, unless you continuously refresh that knowledge, which is really inefficient.
- You actually learn better when there is a clear, immediate need that you care about because your mind is more engaged.
At the other extreme is Just-In-Time learning, which avoids most of these pitfalls. The obvious down-side is that sometimes that “lead time” means you don’t have the knowledge ready right when you need it, but that’s a small price to pay compared to “wasteful” Just-In-Case learning, right? A lot of credible people advocate only learning things when you need them (just Google around for Just-In-Case vs. Just-In-Time learning).
I think that overlooks some benefits of Just-In-Case learning, which I’ll list.
Meta-learning
With Just-In-Case learning, you still benefit from “meta-learning”. If you consider “learning new things” a skill, then the more you learn new things, the better you will be at it. So the next time you need to learn something just-in-time, you will be more effective at learning it.
Sometimes, this is because you’re learning something similar to something you’ve learned before and to things you might need to learn in the future. For instance, I’ve learned so many programming languages over the years that the task of learning a new programming language (at least superficially, to the point where I can write and review basic code in that language) has gotten pretty easy for me.
On the other hand, sometimes you learn something that’s pretty different than other things you know. That’s also useful, because it forces you to learn in different ways. For instance, learning a new programming language is very different than learning about AWS, and both will teach you different techniques about learning that might apply in future scenarios. When do you ask someone credible and how do you find credible people? When do you learn by doing? When do you read a book? Technical documentation? The code? The art of knowing how to learn is a muscle you can build.
Blind Spot Elimination
Sometimes, learning something you don’t need immediately is a good way to eliminate a “blind spot”. Blind spots are things you wouldn’t even recognize you would benefit from learning unless you learned them (or the basics). You might be unaware of the existence of a tool or a pattern if you’ve never really used or seen it before.
One piece of advice I’ve found really valuable is that when learning something new, always think about what problems could this help me solve now and in the future? That way, when you do see that problem in real life, a little flag goes up in your brain that says: “oh, I know what I can use to solve that problem.” One way to reframe that question is what problems was this tool/pattern developed to solve in the first place? If someone invested time in building a tool or thinking through a pattern, learning that tool or pattern without understanding the problem they were trying to solve is actually missing the forest for the trees. You’ll forget the trees anyway, but you’ll probably come across a lot of forests.
For instance, I have a little pattern-matcher in my brain that knows that when I see a problem that is embarassingly parallel (or can easily be parallelized), not real-time (or doesn’t need to be entirely real-time), and really large, it can be solved using a large, distributed data processing engine like Spark. Now, I learned Spark a while back and have forgotten most of the details of how to build (let alone optimize) a Spark job, but at least I made that connection. Otherwise, I could have never considered that tool and may have gone in a completely different (and costly) path.
Essentially, the more broad things you learn, the fewer blind spots you will have, even if you forget most of the details. You learn to recognize things as “another one of those”.
Finally, related to blind-spot elimination is exploration. Maybe you’ve always found something really cryptic or uninteresting. If you learn more about it, you might realize your assumptions were wrong. I’ve seen career paths altered (in really awesome ways) by those sorts of realizations.
Layers and Graphs
Our brains are constantly making micro-decisions around what pieces of information are useful, and what aren’t. The ones that aren’t will atrophy and be forgotten. There’s a lot of science around cognition that you can search for and read about. One obvious technique one is just repetition, and people have come up with techniques like Spaced Repetition, which is basically the ol’ “flash card” technique we probably all used in school, with some thought around when to revisit a “flash card”.
Repetition is a way to signal to your brain that something is important and should be retained. It works well for simple “memorization” tasks, but it’s obviously harder to use for retaining software engineering knowledge in Just-In-Case scenarios. But there are other ways to send your brain the signal that something is important.
When you took classes in school or college, did you ever feel like material that you learned earlier on in the semester was retained better than stuff later on in the curriculum? I used to think that was because the earlier stuff was just easier. But there’s actually something deeper going on. Later material builds on earlier material, and your brain can recognize these dependencies and use them to make decisions about what to retain.
You can think of this as layers of amber or sediment. The layers at the top are loose and can be easily dismantled, but they compress and solidify the layers below them. Another way to conceptualize this is to imagine your brain building its own directed graph of information dependency. When your brain deletes things (or, more correctly, decides not to “renew” or retain things), it’s more likely to start with things higher up in the graph that have fewer things dependent on them.
If you’re learning a lot of things, your brain can better make sense of that graph and its dependencies. It starts to understand that Geometry, Calculus, and many other skills depend on basic Algebra. Think of a little garbage collector running around in your brain, forgetting things that aren’t frequently used or depended on (or alternatively, a little cache rewarmer running around making sure important things don’t atrophy).
Actual brain garbage-collector
The Balance
So what’s the balance? You obviously shouldn’t go around learning random things that may never be useful. But I hope by outlining some of the benefits of Just-In-Case learning, I’ve convinced you that there’s some benefit in learning things that aren’t immediately and directly applicable to your work.
I think the best balance is having a strategy around things that you might use some time in the future, and balancing between things that are immediately beneficial to your career/life and things that might be beneficial if you learn more about them.