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

I think this is missing the main point of Project Based Learning: you choose what you want to learn. You cannot treat motivation as a constant when comparing educational methods. Students get much more from their learning when it is intrinsic and specific to their interests, as is the case when doing a project.

For you, university was a means to the end of learning academic thinking. For me, it was a means to the end of attaining a decent job.

There are certainly arguments to be made that university is by definition, in original intent, and in theory solely a vehicle for teaching academic thought, but I think the pragmatic counter to them is a poll of "why are you here?"[1] , and should be considered valid.

The end result is that university is in practice not one or the other but both: it must teach some academic thought, and provide some job-readiness.

I wish to digress for a moment into why that is not just a failing of many students to understand school's true purpose: many people (hi) do not come from a background where lifetime economic security is a guarantee, and while programming is a rare example (at least in North America) where if you spend the time, you can probably do it, and if you can do it, you can probably be paid well for it, there are unfortunately still gatekeepers. HR departments frequently resort to very base credentialism to sort through candidate resumés, and those with schooling typically come first and get higher base offers of compensation. Not to speak of the network social effects of spending years with other entrants into the field, and the opportunities for extra-curricular pursuits which also are well regarded by those gatekeepers.

These among other things have forced many people with mere occupational goals to pursue university degrees. I wish it were not like this, because my professors universally did not feel that that was a good reason to be there, and occasionally avoided very useful practical topics on principle, but I (and many within my cohort) felt there was no better alternative for a successful outcome in life, and it has mostly worked out.

1 - I of course have not conducted this poll, but I do strongly believe that at least a plurality would respond with job-attainment as their primary goal, and would not be surprised by an even greater response.

On the flip side of this, many of the most capable and intelligent people I have worked with had no degree (or a non-CS one, e.g. fine art is particularly common), and when I try to think of times my algorithms, OS, networking, maths, or even data structures courses have been directly beneficial to my daily work, I have little to show.

Those all had knock-on effects and have indirectly made me more capable and confident in my analyses of performance or occasionally in troubleshooting, but it is very rare that I spend a day doing something deeply theoretical, and it is conversely very common to spend days hitting my head against walls with configuration, integration, or versioning of build/deploy/test components and dependencies. My CS theory is no good there, only methodical troubleshooting and asking for help in IRC are effective, and anyone can learn that by doing.

My own experience both as a learner and teacher is that project-based learning works great once you know the fundamentals and terribly otherwise.

Imagine you want to teach a cohort of incoming CS students to build simple web-server-with-database applications.

The "traditional" way to do this is to first teach them classes on web dev, OOP, and databases. Afterwards, you give them a software project.

I agree with "modernists" that if you just teach the three classes, but don't set a project at the end that integrates the knowledge, you end up with people who are really good at passing whatever style of exam you set them but can still be poor at actually building applications. That's one reason why recruiters care about your portfolio as well as your CV, I guess. It's also why universities, since time immemorial, have required individual projects and dissertations to get a degree - after teaching you the classes, for your "masterpiece" you work on a project.

The problem with making everything a project and assuming they'll learn or teach themselves the basics as and when they need them, is that without some understanding of what the building blocks are to build an application you end up bogged down in the details and developing by trial and error.

Real examples I've seen: spending the best part of a week on code to manually parse incoming HTTP headers (missing the fact that the server library already does that for you); writing custom code to serialise lists into a database field because you don't understand foreign keys (and of course breaking 1NF in the process); loading individual items for which you have an "id" by "SELECT *" on the whole table and then doing the filtering on the server, in O(N); and of course writing code that's vulnerable to both XSS and SQL injection left right and centre.

Even in a project unit where every student has a slightly different and very open-ended project, there's some common ground, e.g. "using prepared statements" for which there is such thing as a "one right way to do it" and my experience is that actually teaching this kind of thing in isolation is the only way that works.

It's hard for me to agree with much of anything the author states here. This snippet is why:

> I don’t teach network programming and haven’t tested these specific ideas. But, in my specialty of software design and code quality, I use exercises built on similar principles all the time.

In the real world, learners do not come packaged with all the tools and links and resources they need to hammer out their solutions. Classrooms are great when you can have a textbook and pre-defined problems and such, but that is not now it works outside of the classroom (or the virtual classroom, as the case may be).

"Software design" is not an isolated component from network programming. It is that bridge between big data always getting piped in to (app / product / website) from the network, and how to help ( user / customer / other developer) where most engineers are hired to create value.

It is a good idea to attempt to design software with "code quality"; conceptually that sounds like a fantastic idea. But it is impossible to do without also factoring in a predictive element of how it will be used or accessed or even discovered over networks, stores, whatever.