Greg Wilson's talk about the lessons learned from software carpentry would definitely be worth seeing if people haven't already seen it.
http://youtu.be/1e26rp6qPbA
It is delightfully forthcoming and blunt about both the challenges that have been faced, where failures happen, what the weak spots are, and what can be done better.
In particular the emphasis toward the end about modifying course materials with the intention of eventually merging them back together has had me thinking about whether that actually is a good approach to pedagogy. It literally seems to treat pedagogy as if it is merely an extension of programming, but without considering the importance of materials be adapted to the one doing the teaching as well as to the appropriateness for the materials being taught. It is analogous to a claim that one could run a program precompiled to run on a unix based OS just as easily on a windows based OS.
Many of the points he brings up are fascinating, solid approaches that resembles the kind of careful thinking I associate with Greg Wilson. His takes digs at himself, at IPython notebooks, at git, and at the programming community in general. That honesty is refreshing.
However, he seems to be swooning over data without recognizing (much) the problems that any data carries with it: the implicit choice of measurement and the fact that we can only measure the past.
He does acknowledge this, but then he sweeps those considerations aside when he says things like any school system that is trying to switch to give each student an iPad should stop immediately and reallocate their resources. This is problematic because of its failure to recognize that it could very well be that these touch devices (whatever their brand) are not being used effectively, which does not eliminate the possibility that they could be incredibly powerful tools if they were programmed effectively.
For example, what if there were a learning environment on the iPad that would train children to be able to understand the basic concepts of version control or even basic automation/programming techniques. It happens that these programs don't exist, but I can imagine them. The first could be something like a tree growing game in which you have to account for growth that occurs outside of your control requiring you to both trim branches (reversion), branch to account for different contingencies (branch), and rejoin branches when you're running out of room(merge). I'm sure that there have been attempts at the latter on a traditional computing device, but the possibility of direct clause manipulation available through touch technology should make it more obvious how structured code (especially modularity) can be useful.
On the other hand he lauds the developments of the flipped classroom given the current data, which I think is great. Why do I not worry about the data being suspect in this case? It comes back to a popper style doubt of negative effects. Also, my guess is that if those were treated as linear regressors without interaction coefficients (which it seemed like they were) I could easily imagine that there would be an interaction between the effects of a flipped classroom and a one-computational-device-per-child type program. In the off-chance that children grew up like me (for most of my young life having no computer and later having one to be shared with everyone else) a flipped classroom may only be possible in a situation where each child had a computational device(since otherwise there would not be enough time for each child to watch their own lessons).
The larger point is that Greg's talk is great and worth seeing despite the fault in his reasoning that I list above. And even those faults don't diminish the immense wisdom conveyed in the talk. So even if everyone has already thought through these things, it will be worthwhile to discuss how his claims will impact your pedagogical practices. Will you be giving pull requests to software carpentry's lessons any time soon?
Cheers, :€