We’ve spent a lot of time in class so far this semester discussing the role of testing in education and alternatives for assessment of students learning. Overall, I’m in favor of the use of real-world projects as a way to demonstrate knowledge. However, one thing has been nagging at the back of my mind every time I have said or written anything in support of this viewpoint. That is the fact that every single class project in my undergraduate was a pretty miserable experience, and definitely not the kind of thing I would want to put my own students through.
There are several things that I think repeatedly went wrong in these projects that hindered my learning:
1. There was no room for creativity. Projects were grounded firmly in realism. I can think of multiple occasions when I was part of a group that tried to think outside the box and proposed something unique, just to be told by an instructor that, “That’ll never work in the real world” or “No one would ever be willing to pay for that.”
2. There are too many rules. It felt to me like some of my engineering projects were as much about the formatting of the final project report as they were about the actual problem solving.
3. Group work is hard. Honing interpersonal skills can be a huge challenge that often takes away from the learning and problem solving on a project. Of course being able to work in a group is a valuable skill so I think we need to give some thought as to how to most effectively balance group work with individual learning.
On the other hand, when I think back to my undergraduate education and identify the most engaging experiences that I learned the most from, two experiences come to mind. The first is my undergraduate research project and the second was an out-of-class project I participated in and even captained my senior year: concrete canoe (that’s exactly what it sounds like. You build a canoe out of concrete and race it across a lake and hope it doesn’t sink… and it’s awesome!).
1. Real-world relevance. These projects had real-world applications and I got to carry out a plan in an iterative manner rather than spending an entire semester committing a single idea to paper with no opportunity to test my ideas, as can be the case in class projects.
2. Autonomy. There’s space to think through problems and make mistakes and learn from them.
3. I had an advisor to offer technical support and feedback rather than a list of rules and guidelines.
I’m not exactly sure what a project that avoids these pitfalls and captures the positive aspects looks like, especially in Engineering, but I think it is something to work towards. I really like the games mentioned in Mark Carnes’ commentary piece Setting Students’ Minds on Fire and would love to incorporate a similar approach into my own teaching.