Two Faces of Project Based Learning
If one looks at my twitter feed they'll notice that in addition to CS Ed, another issue I'm passionate about is school reform or rather resistance to what is popularly known as and mislabeled as school reform. I'm anti vouchers, charter schools, high stakes testing and more. One of the heroes of this resistance is education historian Diane Ravitch. I'm a big fan of Diane's and she's one of the true great champions of public schools, kids, and teachers. She blogged today about how a superintendent on Long Island replaced test prep with project based learning. The post which talks about how this superintendent improved test results is worth a read. My only quibble was that we shouldn't read anything into the results for a variety of reasons including the fact that the group of students who did the project based learning (PBL) units instead of test prep were self selecting volunteers.
One of the comments caught my eye:
PBL is just another “student-centered” fad…
PBL operates on the myth of “transference” perpetuated by non-educators.
The comment continues on with a number of good points.
Why am I writing about it here? Because PBL is a big CS Ed buzzword and like most buzzwords there's both truth at the root of the hype and hype that distorts the truth.
When done right with the right group of kids, project based learning can be wonderful but it takes a lot of time and effort. You can't just set the kids loose to learn. You've got to train them to work together, set up the project, as the teacher, you've got to know the subject so as to know when to guide, when to tell, when to prod, and when to leave them alone. Doing it right, at least for most students, is certainly not giving them the instruction sheet and going off the check your email.
On the other hand, it's easy to do it wrong. If you've got high performing kids, they'll figure things out. If you've got a few high performing kids, they can mask the fact that the majority of a group isn't getting things. You might have an assignment where a kid figures out a formula from discovered data and might be able to then use it to make predictions but there's a good chance they won't understand why it works or it's root derivation. That's where we need the teacher.
One of the dangers of bad PBL is that it's sexy. Kids are engaged and it appears to work - particularly when the teacher doesn't know the subject area. This is my great fear whenever I hear things about teachers being "Lead Learners." Sure, when you're a converted something else teacher moving into CS you won't know the subject matter but that has to change over time. I've seen enough instances of cases where teachers never develop their chops and just throw projects at the kids augmented by scripted curricula or computer driver content. The kids get through the class or program but are not prepared for the next class or next level. I've seen this with the old Cisco curriculum, any number of after school and summer programs - some VERY highly regarded ones and I think we'll see more and more of this in states that are pushing CSforAll without developing the necessary pre and in service programs for their teachers.
Don't let my last two paragraphs leave you feeling that I'm anti PBL. I'm not. It's great when done right and if you have thee time and resources in your school and classes you should be using it when appropriate.
If you want some pointers on how to get going in the right direction with PBL in CS check out this book by my buddy Doug Bergman. It's a great getting started guide by a great teacher. He's basically Mr. PBL and he does it right. If you're new to CS you'll still need to learn content and if you're new to teaching, you'll be developing your chops for your entire career but it's a great resource to get you and then your kids started on the journey.