There's a lot of psychology at work here which is not being given due credit.
People who are theorists at their core typically believe that the learning is interesting by itself, usually because they are focused on developing their own models for how things work. It's a subjective-creative process that's exciting: You get to play detective! They are getting creative outcomes _while_ learning about theory. They do not need to wait for a project outcome in order to feel accomplished. Their only other answer, like OP's, to learning things that aren't interesting by themselves but still need to be learned is rote learning, or drills. What other method could possibly educate the student and yet not introduce other rabbit holes that distract from the topic?
Project-motivated people find this approach boring, and they are ready to go down the various rabbit holes involved in the project, if necessary to achieve their envisioned outcome. They are focused on _applying existing theory_ to effect their concrete outcomes, which is an interest that straddles the theoretical and real-world-application zones. They get happy brain chemicals by e.g. watching people use a project they've built. These types use a referential thought process for higher leverage and shorter timelines. So rather than developing their own model from scratch (NIH, the theorist's pet method) which will take them a long time and might not be that effective, they borrow someone else's model ("hey, let's use Framework X, it has tons of features!") and make it serve their subjective outcome-vision. Seeing the vision brought to life is where their creative fulfillment is activated.
CS departments are stuffed full of the former case. Engineering departments are stuffed full of the latter case.
It can be absolutely maddening to be either one, and then find yourself being asked to accommodate the other's learning / executing style.
This is so true, and boy do I wish I had known this before choosing a CS program. I think there is much more education (or counseling) that could be done for high school students who are unfamiliar with CS and software engineering.
Plenty of “theorists at heart” still think it’s boring to do lots of rote drills. :-)
It’s not like doing drills really helps you develop new models/tools/concepts from first principles especially more than it helps you adapt existing models/tools/concepts to new situations.
* * *
I think the article under discussion here misses the point in a different way. He assumes that it’s impossible to get meaningful fast feedback about various particular aspects of your work (and focusing on those deliberately) while working on “projects”. But at least in computing (and probably most fields if you look around), that’s not necessarily true.
We have tons of quality feedback available in computing, starting with tools like a REPL or a debugger which interactively show you the results of small actions, and then compilers and static analyzers and profilers and ....
Then there’s IRC and mailing lists and open source ticket trackers etc., where expert strangers will spend tons of their time helping you out for free just to pass the time. If your project happens to be something that other people are interested in and you are working in the open, there’s feedback from customers, other programmers, etc. If working in a group of mixed ability, there are the other group members or possibly a skilled mentor/tutor, and if working in a company there are coworkers.
There is oodles of open source code, documentation, free textbooks, targeted videos of people demonstrating how to use particular development tools or their general method, or showing off particular tricks, much of which is reasonably searchable and can be called up from the internet on demand when a particular problem/roadblock is stuck. You can relatively easily try to implement parts of projects yourself, then go find an example project where someone else implemented the same thing, and compare the two. Typically you can find both toy examples and production code, with their entire version history, internal project discussions, bug tracker history, ....
Arguably you could learn a whole lot by coding up 30 different examples of data structures in C, one after another, getting expert feedback after each one. And then moving on to coding solutions to 20 different dynamic programming problems. And then 10 compilers for different little languages. And then 10 different CRUD apps for made up restaur. Or whatever....
But you could also get lots of good experience by building a whole project that you personally care about from bottom to top, using it for a while and watching where the bugs come up, seeing what parts are completely wrongly architected, etc., and then trying again several times (ideally with a bit of introspection and research in between) until you have a better idea what to do.
What I'm saying regarding rote drills is, when you tell a theorist that developing a model by yourself isn't interesting or helpful to you, their only other thought is, "you must be one of those weirdos who benefits from rote learning?"
Project-based learning simply doesn't come to their mind; it's completely off their radar because it is, as op implies, potentially full of little all-consuming rabbit holes that are unrelated to the CS principles in question. Look at the great theorist Feynman and his "computer disease" theory. He had a deep aversion to getting sucked into things like IT concerns, because theoretical model-detecting was his core motivator.
Feynman was complaining about something different. He was in the middle of working on large-scale projects and got annoyed that his coworkers got completely distracted by irrelevant (but amusing) tangents instead of doing their next task that everyone else was blocking on.
This is a problem of the coworker’s lack of executive planning / control / time management skills, not anything about learning via projects or theorizing. Arguably if the coworker had done a bit more project-based learning he would have better practiced those skills.
People who are theorists at their core typically believe that the learning is interesting by itself, usually because they are focused on developing their own models for how things work. It's a subjective-creative process that's exciting: You get to play detective! They are getting creative outcomes _while_ learning about theory. They do not need to wait for a project outcome in order to feel accomplished. Their only other answer, like OP's, to learning things that aren't interesting by themselves but still need to be learned is rote learning, or drills. What other method could possibly educate the student and yet not introduce other rabbit holes that distract from the topic?
Project-motivated people find this approach boring, and they are ready to go down the various rabbit holes involved in the project, if necessary to achieve their envisioned outcome. They are focused on _applying existing theory_ to effect their concrete outcomes, which is an interest that straddles the theoretical and real-world-application zones. They get happy brain chemicals by e.g. watching people use a project they've built. These types use a referential thought process for higher leverage and shorter timelines. So rather than developing their own model from scratch (NIH, the theorist's pet method) which will take them a long time and might not be that effective, they borrow someone else's model ("hey, let's use Framework X, it has tons of features!") and make it serve their subjective outcome-vision. Seeing the vision brought to life is where their creative fulfillment is activated.
CS departments are stuffed full of the former case. Engineering departments are stuffed full of the latter case.
It can be absolutely maddening to be either one, and then find yourself being asked to accommodate the other's learning / executing style.