I spent the last three days at a Teachers Workshop in the Maine School District on a pedagogical tool, problem based learning (PBL).  Those of us in higher education (especially engineers) are familiar with the subject, although you probably call it something else. Briefly, the concept is: teach some material by presenting a “messy” problem to students. This provides motivation and you can build lessons and discussions around the subjects they “need to know”  to attack the problem.

This pedagogical tool is popular in engineering schools but often poorly implemented. The first course that comes to mind, for me, is a course on algorithms.  At the beginning of a semester, give the students a setting where the solution is an NP-Hard algorithm. Most of the students will probably struggle with the problem, until you cover basic complexity and approximation algorithms. Perhaps they could use a randomized algorithm to attack the problem. This may motivate them to pull up conference proceedings and read more about the problem and approximations.  You could pick a problem like the “School Timetable” problem or Multi-Commodity Flow.  With undergraduates, you want to help them avoid this problem with their future employer [ From the Garey Complexity Book ]

On a slightly unrelated topic – at the end of the workshop, one of the facilitators played a video clip I have seen at least 2 times before in class at Michigan’s School of Information.  You can watch the video below:

In the context of talking about problem based learning, I can understand why the video is interesting. If wepropose open-ended messy problems (like Ideo’s shopping cart problem) to students, we can motivate them to think abstractly and creatively about problem solving.

I do have a problem when people show this video to students, especially undergraduate and/or high school students to motivate them to become engineers, designers, and/or researchers.  My problem is this: with high probability they won’t be working at Ideo or a company that designs like Ideo.  If they go into engineering, they’ll be working for an {engineering/IT/manufacturing} firm, a start-up, or a University.  General Motors or Google probably won’t let you have an airplane wing above your cubicle or let you hang your bike from the ceiling.  The design process is more measured and your research/lit review/observations take far longer than a day.  But it may still be an interesting, demanding, and creative process. Then, when these students start working at these companies or work towards a degree, they’re going to be disappointed when it is not as sexy as we told them it was.

Let’s not lie to our potential future engineers, we’re just going to disappoint them. There are lots of really cool engineers and projects out there that are not as sexy as Ideo but require the same tools. How about one of the engineers that designed the Chevy Volt?  What about a Professor that works on a Cyclotron or the CERN project? Lets get students involved in engineering and design for the right reasons – not because it is sexy.

This quarter (they’re quarters, not semesters here at Northwestern), I was a TA for EECS310 – Discrete Mathematics. It is a 10 week course, divided into sections: proofs, binary relations, graph theory, counting, combinatorics, and probability. Today is their last quiz, so I’ve compiled a list of my thoughts about TAing and things I will do different next time:

• Be more prepared: I went into this course with not very much discrete math experience. I had encountered most of the material at one time or another through my academic career but I was very new to many of the concepts (especially the formality of writing good proofs). I wish I could have worked through some of the course material, ahead of time, so I could have done a better job answering student questions.
• Don’t be afraid to say “I don’t know”: I felt pressure to give students precise or exact answers to problems.  Mostly, in the classes that I’ve taken, if I’ve asked the TA a question they’ve been able to give me precise answers. So, I felt bad when I couldn’t help them as well as I’d liked to. There were a few times this quarter where I was asked a question and tried to figure it out on the spot but tanked. I learned that sometimes, you have to say “I don’t know” and get back to the student.  It’s okay to defer some questions to other TAs or the professor.
• Be fair when grading problem sets. Don’t be harsh with penalizing for mistakes but reward students who do particularly well.  If I take points off, I try to provide some reasoning to the student, i.e. “You didn’t do this well.”, “You are close but not quite there..”, and so on. If you’re too harsh, students complain and if you’re too easy, they don’t learn from their mistakes.
• Talk to the class about their problem sets. This is something that I didn’t do that I wish I had done, the best TAs that I’ve had have done this.  In the future, after I grade problem sets, I’m going to go in front of the class and talk about what they did: give suggestions for improvement, talk about general proof writing techniques, and make suggestions for future assignments.

That’s all the suggestions that come off of the top of my head.