Feedback and Boundaries

This post originally appeared on the Software Carpentry website.

Thanks to the initiative of Dominique Vuvan (who took Software Carpentry last summer), we ran a semi-formal version of the course from last November through to this past week for grad students in Psychology, Linguistics, and a few other disciplines at the University of Toronto. Weekly tutorials were offered in both Python and MATLAB by graduate teaching assistants from Computer Science, covering roughly half of the existing material.

The two things students like least were the general disorganization of the course and the fact that a lot of the material felt like what we computer scientists though they ought to know, rather than what they could see as being immediately useful. The disorganization reflects the grassroots nature of this round of the course, and the fact that it was our first time teaching in MATLAB. Next time around, we'll use a more natural order for material in MATLAB, rather than sticking to the order that makes sense for Python, but forces students to grapple with some of the more obscure features of MATLAB early on.

The "eat your vegetables" tone of the material is going to be much harder to deal with. Software Carpentry is meant to be a second course in computing, not an introduction to programming in general: as the last of the user profiles says:

This course is probably too advanced for [a novice], as it assumes familiarity with basic programming concepts like loops, conditionals, arrays, and functions. [They] should probably audit a first-year introduction to programming or find an intensive two-week summer school course before tackling this one.

The problem is that if we'd actually applied that rule last November, we would have turned away more than half of the students, most of whom would never have acquired those basic concepts. So, do we:

1. ignore the problem and hope that these people will somehow pick up the basics on their own (despite the fact that most scientists never do), or
2. broaden the course's mission to include basic programming as well.

My phrasing makes my preference for the second option clear, but feature creep is the biggest risk this project faces. Teaching the basics of Python to people who already know a bit about programming takes 4-5 lectures out of the 25 budgeted; if they don't know how to program, that figure probably triples, leaving only 10 lecture hours to cover a much-reduced subset of the planned material. On the other hand, sticking to the plan means condemning the majority of potential students to wander lost and frustrated through a bewildering maze of seemingly inconsistent behavior, and to hour upon wasted hour of heartbreaking frustration. (That was a bit melodramatic, but not necessarily inaccurate.)

Another argument against option #2 is pacing. Software Carpentry has been run four times at the University of Toronto (twice as non-credit tutorials and twice as a regular for-credit course). Each time, wide variation in students' prior experience levels meant that no matter how material was paced, one third of the class would be bored or another third bewildered. On balance, therefore, I think Software Carpentry has to continue to assume a more advanced starting point than most of its potential audience currently has. If things go well, I hope we'll be able to backfill with more accessible introductory material in a year's time.