Years ago someone told me that he never learned algebra & has never had a need for it.
But I’ve learned algebra and used it constantly.
It’s a lucky thing I was the one who learned algebra since I ended up needing it.
But of course it’s not 'being lucky' per se, since I'd not have had any use for it either, had I not learned it :/
Broadly speaking there are two types of thinking processes;
The straight thinking & the lateral thinking. [more on it laterz inshAllah]
Just like that there are two types of learning behaviors we can spot in our daily lives out there;
First one, is the more traditional school based learning approach. We learn something with a hope that it'll be needed in future someday; this is to learn just_in_case.
The other one, is learning only when we need to learn; thats just_in_time learning.
Its a perfect dichotomy i dare say, & we all have our own experiences of both types of learnings..
In general, we learn things in school just...
In general, we learn things in school just_in_case we’ll need them later. Then once we get a job, we learn more things just_in_time when we need them.
Software developers, for instance, prefer just_in_time learning - they rightly should.
There’s so much out there that you simply ain’t going to need. You can’t learn every nifty detail of every operating system out there, every programming language, every library etc. before you do any real work. You can only remember so much arbitrary info without a specific need for it. Even if you could learn it all in the abstract, you’d be decades into your career without having produced anything.
On top of that, tech info has a pretty short shelf life, so it’s not worthwhile to learn too much that you’re not sure you have a need for.
{P.S; some software developers & programmers are an exception to this generalization though :p
They write a lot of code that is never used. There are numerous reasons for this. In Peter Seibel’s book 'Coders at Work', Peter Norvig gives his take on why this happens.
Sometimes software developers believe there’s a high probability that some unrequested feature will be needed in the future. In general, they over-estimate such probabilities. The acronym YAGNI — you aren’t gonna need it — is meant to remind developers of this tendency.SL: "Why is it so tempting to solve a problem we don’t really have?"
NG: "You want to be clever and you want closure; you want to complete something and move on to something else. I think people are built to only handle a certain amount of stuff and you want to say “This is completely done; I can put it out of my mind and then I can move on.”
Norvig rightfully points out the down-side of seeking closure. Maybe the last 2% is intellectually satisfying but horribly difficult and not worth the effort.
I’ve erred on both sides though.
Years ago I often erred on the side of developing functionality that was never used. Then reading Kent Beck convinced me that YAGNI is usually true. Since then I’ve erred on the side of wishing I’d done more while a project was fresh on my mind.}
Returning -
When you learn just_in_time, you’re highly motivated. There’s no need to imagine whether you might apply what you’re learning since the application came first. But you can’t learn everything just in time. You have to learn some things before you can imagine using them. You need to have certain patterns in your head before you can recognize them in the wild.
So far the pros of just_in_time learning are as follows;
~ motivation to solve prompts you to learn.
~ there is no abstraction associated with it, since the problem came first.
The cons being that;
~ we tend to learn just the bit required and move ahead, unable to grasp the learned content in full.
~ cannot be done without having a priori knowledge base [you need to know what’s available, even if you’re only going to learn the details just in time. You can’t say “I need to learn about version control system now” if you don’t even know what version control is.]
.. & here comes the importance of just_in_case learning.
Just_in_case is like training, while just_in_time is like trying..
You can’t run a marathon by trying hard. The first person who tried that, sadly died. You have to get yourself trained for it. You can’t just say that you’ll run 20 miles when you need to and do nothing until then.
Upshot;
In today's fast pace world just_in_time learning makes so much more sense, as the number of new softwares, programming languages, & tools are being updated and developed at an astonishing speed. And all can't be learned swiftly enough.
But value can be added by adding a bit of a just-in-case to your just-in-time efforts, i.e., learn a bit here and there to have that stronger *feel* of your acquired knowledge. The difference is perhaps only in minutes, but advantages for future might span upto months.
And lastly, to wit; you need to have a survey knowledge of technology just_in_case.
But you can learn APIs just_in_ time.
But therez a big gray area in between where it’s hard to know what is worthwhile to learn and when.
You can’t run a marathon by trying hard. The first person who tried that, sadly died. You have to get yourself trained for it. You can’t just say that you’ll run 20 miles when you need to and do nothing until then.
Upshot;
In today's fast pace world just_in_time learning makes so much more sense, as the number of new softwares, programming languages, & tools are being updated and developed at an astonishing speed. And all can't be learned swiftly enough.
But value can be added by adding a bit of a just-in-case to your just-in-time efforts, i.e., learn a bit here and there to have that stronger *feel* of your acquired knowledge. The difference is perhaps only in minutes, but advantages for future might span upto months.
And lastly, to wit; you need to have a survey knowledge of technology just_in_case.
But you can learn APIs just_in_ time.
But therez a big gray area in between where it’s hard to know what is worthwhile to learn and when.
~*~*~*~*~~*~*~*~*~