As mentioned a few times, Matt Davis and I taught the Python section of the Software Carpentry Boot Camp this past week.  Overall the experience was positive.  We had approximately 4 (stretched to 5) hours, and developed our own curriculum with a fairly strong narrative.  Almost every exercise focused on a task, taking a CSV data-file (eventually a large set of such files), loading it up, performing calculations on it, and outputting results.

The biggest single failure, IMO, is that our exercises were too involved.  Matt mentions in his blog post that he would have done more "filling in" for the exercises, so that students would just be able to focus on a few key lines.  I'm of the mind that having more exercises which are still "blank canvases" (though possibly with the *interfaces* defined in the files), but that build more slowly would have provided a better experience.  We could experiment with that.  At the least, a number of the exercises needed to be broken down into smaller, more easily explained tasks.  These were not take-home exercises, after all.  They were to be solved "live", so no exercise should have had more than one "goal".

Setup and system configuration was a major time sink.  In such a compressed time-frame, having an hour or so of your time disappear into "how to install Python" and "how to work around OSX Lion marking every file edited with TextMate quarantined (not executable)" issues is a rather huge loss.  Software Carpentry is looking at how to address those issues.  As Matt points out, Udacity's (or Crunchy's) model might work there, but it wouldn't leave the student's with a working dev environment at the end of the class.

Student level became something of an issue for a handful of students.  They were already familiar with loops, variables, data-types, etc, and were looking for a "I'm a MatLab user, show me how to use Numpy" type introduction.  Software Carpentry is more of a "I know how to use Office, Facebook and Google, how do I start programming" level course.

I would be tempted to compress one of the other topics (e.g. remove shell *scripting* and only cover basic shell operations, maybe adding ssh basics), and possibly defer one of the other topics entirely (SQL and image processing), which would give ~ 5 hours more to the programming course.  While shell scripting is useful, image processing is cool, and SQL is valuable, getting people up to speed with how to solve problems with code would mean an online tutorial/workshop could cover SQL, a special-interest workshop could cover image processing, and people who were interested could easily pick up shell scripting, having already learned how to program in one language.  Matt's suggestion that we do more "motivational" introductory material is interesting as well.

I'm hoping to teach some other introductory Python courses from the curriculum we developed, so I'll try to address some of these issues going forward.