The Practice is not the Performance: Why project-based learning fails

Most students are oversubscribed with four or five classes. There tends to always be some portion of a group which contributes trivially or simply doesn't. When you've got a group of five, one is typically unreachable, apathetic, or just exhausted. Pairs are a gamble, a bad partner being a massive workload. When you're the person who's carrying the group, you usually end up grokking everything in the project because you touched all of it. However, since you touched all of it, you're exhausted and likely pissed.

What I've found works is individual work sample projects, particularly those timeboxed to 'hopefully a lab period but you have a week'. The GPGPU course at my school has labs which are 'fill in the blanks' for cuda code. As the course goes on, those blanks get progressively more complex and make you flex your core understanding of the course. For more theory driven courses, the standard set of assignments works nicely.

As an aside, group projects seem to be partially motivated by the TAs and profs trying to deal with larger class sizes. Taking a senior level graphics class with 30 people lets you write 4 gnarly opengl projects which the TA marks in depth; a software engineering course with 200 people, a weekly deliverable, and 5 TAs? Dividing that by 5 is more realistic.

(For context I go to a school not known for their undergrad CS program; experiences may differ in other institutions)

This dude doesn't recognize the audience that most blog posts target.

Most people reading blog posts about learning code are NOT in college and ARE NOT employed by colleges.

So the challenge for learning is more about motivation and projects tend to help you stay motivated more easily that little learning lectures and components.

James already addresses this assertion in the very first sentence of the blog post. And the second sentence.

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.