You will never be dumber than you are right now. You will also never have more time than you do right now. Thus, you have a relative abundance of time and a relative dearth of knowledge. How do we strike a balance between these resources to optimally leverage them for learning?
These questions came up as I listened to two episodes of the Ruby Rogues podcast. In episode 70 David brings up just-in-time versus just-in-case learning. David’s ideas were prompted by Katrina Owen, who has a list of learning resources here. The other thought-provoking episode (responsible for the above paragraph) was number 87 in which the rogues discusses Sandi Metz’s new book, Practical Object-Oriented Design in Ruby. (I had the pleasure of meeting Sandi last night at a local Ruby meetup, after a draft of this post was written.) Here’s Chuck riffing off of a quote from the book:
“Practical design does not anticipate what will happen to your application. It merely accepts that something will and that in the present, you cannot know what. It doesn’t guess the future. It preserves your options for accommodating the future.” And so, what that says to me is you don’t always have enough information. You may never have enough information. You will never have less information than you have now. So make the design decisions that you feel like you have to and defer the rest, until you don’t have to anymore. And so it was basically, “Here are some rules. But use your best judgment because you’re going to get more information that’s going to inform you better later.” And so, that kind of opens things up. Here are the rules but if you have the information that says that you have to break them, then break them.
The just-in-time and just-in-case distinctions are useful in answering the question I posed at the beginning. But before I give concrete examples I think it is important to introduce another dimension to our learning classification: formal and informal. Being the good social scientists that we are, we can now formulate a two-by-two table.
Just-in-case learning is done well ahead of the time that it is needed for practical purposes. Children learn English (or whatever their native language) without thought for or anticipation of the letters, emails, and blog posts they will write in years to come. In a formal setting this can lead to the use of toy problems to make the skill seem practical. Students in an algebra class may have trouble seeing ‘the point’ of those skills until much later–and even then they may not fully recognize where that learning originated.
Just-in-time learning occurs at or very near the point of need. I could ask for travel directions to your house when we first meet, but that would be useless until you actually invite me (not to mention presumptuous). It is better to learn something like that when I can use it right away, since it has little value in the abstract. Programming–for me at least–has been much more of a just-in-time skill. I have taken one formal course in the topic and am currently enrolled in another. But the great benefit of these courses is that you get to put your skills to work immediately.
To answer the question we started with, I think that we need to place more value on just-in-time learning and less on just-in-case learning. As the quote from Sandi’s book points out, we live in a world of uncertainty. There are some skills that you simply cannot learn at a just-in-time pace (math being the main one that comes to mind). But for the plethora of other cases that our modern world and its tools make available, learning at the point of need is satisfactory and perhaps even superior. That is why we need to develop more avenues for just-in-time learning. Programmers have this in spades with sites like StackOverflow, but many other skill areas do not. Sites like Coursera also have a chance to provide a middle road between the categories in the table above. The ability to iterate quickly and pick up new skills on the fly will be increasingly valuable in the years to come.