As someone who does a whole lot of pull-based learning, I’m going to chime in and say that using it as your main method of learning is probably not the best idea. tl;dr: Learning on the job is powerful, but it overfits by nature; while there’s probably more than a little confirmation bias from us ivory tower types, it’s almost certainly drowned out by “everything comes back to math and logic” and “the truth is all of a piece”.
There is a fairly natural divide, IMO, between “engineering fields” and “theoretical fields”—fields that are directly aimed at solving actual problems, and fields that are more about exploring what is possible and figuring out what is true in general. Pull-based learning is tempting in engineering fields for all the reasons you list—most of being able to solve a real world problem is precisely knowing about all the little fiddly bits of reality, and there is not yet a good way of predicting which fiddly bits you need to know while sitting in your armchair (metaphorically speaking.) In that regard you can get pretty damn far learning only what you “need to know”, to the point of finishing a number of fairly large projects...
… but your knowledge is fundamentally grounded in air, and it’s not always obvious how your experience generalizes. To generalize knowledge you need to build an abstract model, and the skill of building abstract models is very, very theoretical (almost by definition!). In particular, using pull-based learning as a primary tool reminds me of trying to learn physics without first learning math as a fundamental. Certainly, you can make use of what other people have done, and when they start pulling out integrals and Lagrangians and group symmetries you can go look that up and learn it then—but that won’t let you make your own generalizations, or (as Darmani says) contribute to pushing the boundaries on your own.
Personally, I find pull-based learning most useful as the first/last step in a loop. You do some project, and midway through you find there’s a whole bunch of stuff you wish you knew better and learn just enough to get it done. But then you go off and take a course in the dangling ends you discovered, and maybe explore a few branches off that tree too, before you come back to doing some new project challenging enough to force you to learn on the job again—and also enough to make you use your new skills, judge which of them are most important, and generally see them in a new light/in practice. To use the Pokemon metaphor, it’s like, after losing against the Elite Four, you boot up someone else’s save file right before the Elite Four in a totally different version, and try to pick up general “anti-Elite Four” tricks in general rather than “oh, this particular Elite Four has a Ghost specialist, Ice specialist, Fire specialist, and Steel/Psychic specialist, in that order”, which doesn’t generalize to other games.
As someone who does a whole lot of pull-based learning, I’m going to chime in and say that using it as your main method of learning is probably not the best idea. tl;dr: Learning on the job is powerful, but it overfits by nature; while there’s probably more than a little confirmation bias from us ivory tower types, it’s almost certainly drowned out by “everything comes back to math and logic” and “the truth is all of a piece”.
There is a fairly natural divide, IMO, between “engineering fields” and “theoretical fields”—fields that are directly aimed at solving actual problems, and fields that are more about exploring what is possible and figuring out what is true in general. Pull-based learning is tempting in engineering fields for all the reasons you list—most of being able to solve a real world problem is precisely knowing about all the little fiddly bits of reality, and there is not yet a good way of predicting which fiddly bits you need to know while sitting in your armchair (metaphorically speaking.) In that regard you can get pretty damn far learning only what you “need to know”, to the point of finishing a number of fairly large projects...
… but your knowledge is fundamentally grounded in air, and it’s not always obvious how your experience generalizes. To generalize knowledge you need to build an abstract model, and the skill of building abstract models is very, very theoretical (almost by definition!). In particular, using pull-based learning as a primary tool reminds me of trying to learn physics without first learning math as a fundamental. Certainly, you can make use of what other people have done, and when they start pulling out integrals and Lagrangians and group symmetries you can go look that up and learn it then—but that won’t let you make your own generalizations, or (as Darmani says) contribute to pushing the boundaries on your own.
Personally, I find pull-based learning most useful as the first/last step in a loop. You do some project, and midway through you find there’s a whole bunch of stuff you wish you knew better and learn just enough to get it done. But then you go off and take a course in the dangling ends you discovered, and maybe explore a few branches off that tree too, before you come back to doing some new project challenging enough to force you to learn on the job again—and also enough to make you use your new skills, judge which of them are most important, and generally see them in a new light/in practice. To use the Pokemon metaphor, it’s like, after losing against the Elite Four, you boot up someone else’s save file right before the Elite Four in a totally different version, and try to pick up general “anti-Elite Four” tricks in general rather than “oh, this particular Elite Four has a Ghost specialist, Ice specialist, Fire specialist, and Steel/Psychic specialist, in that order”, which doesn’t generalize to other games.