Writing good problems is hard

Tomorrow afternoon, I need to go in to my Intro to CS class armed with a pep talk.  The reason?  I’ve inadvertently slammed them with two assignments in a row that were more challenging than I intended, and I sense that morale is low.

This term I’m trying a new approach to teaching intro.  Rather than using the usual topics-based approach (loops, conditionals, etc), I’m using a case-study approach.  Each week we look at a different problem, such as cryptography, or image processing, or dealing with large datasets, and then learn the relevant CS concepts in the course of studying the case studies.  By and large this has worked really well—I’m seeing a much more nuanced understanding of the typical CS concepts on the part of the students, and the students have gotten quickly comfortable with even the most traditionally tricky concepts.  And, it allows me to assign really cool problems in class, in labs, and on homeworks.

Here’s the catch:  The students are still in the beginning stages of learning how to “think algorithmically”, not to mention think in a computer language—essentially, they are learning a new language.  Which means that they still need to be working on problems that are easy to grasp, and small-ish in scope, so that they don’t lose the forest for the trees.

So I find myself trying to find cool problems that are still small and accessible.  After teaching Intro as many times as I have, I should be pretty good at this, but it’s still a fundamental struggle, and I still, occasionally, get it wrong.

The last assignment was a great example.  It was a great premise:  the students had to write a program to determine if they could select 10 arbitrary stocks that, as a group, would outearn the Dow Jones over the last 5 years.  The writeups the students handed in were very well done, and it looks like they learned a lot from the assignment.  But, in hindsight, there was just too much there that they had to do, and many students got overwhelmed with the level of detail early, and panicked, and spent way longer than they should have on the assignment.*

It would have been much easier to give a toy problem (a small, straightforward calculation-type problem), and perhaps from a skills perspective the students would have gotten the concept more quickly that way.  But part of my role as Intro professor is to fire the students up about the possibilities of CS.  I can get the students to learn about manipulating items within a list by, say, having them write a program to find the maximum value in a list of numbers, or I could teach them the same thing by having them find the stock with the highest gains over a five-year period.  By taking the approach that I am, I’m betting that the latter assignment will stick with them longer and ultimately drive home the lesson much more effectively.  The risk, though, is that the lesson gets lost in the details of solving the problem, and the problem masks the concept.  When this happens, the students can get really (and understandably) frustrated, and blame themselves (“This was hard—I must not be any good at this.  Computers hate me!”).

So tomorrow I will go into class and talk about how faculty sometimes make mistakes in judgment, and remind them that what they are doing, and learning, in this class is stretching them in ways they’ve never (probably) stretched before, and that stretching can sometimes feel very uncomfortable.  And also, truthfully, remind them that they’re doing much, much better as a whole than any other Intro class I’ve taught, period, and that really says something about how far they’ve come.

I just hope they buy it.

* In a future post, I’ll talk about this particular mentality among Carleton students and why it’s particularly frustrating from the faculty perspective.

Advertisement