Settings Our Sights a Little Bit Lower

This post originally appeared on the Software Carpentry website.

A couple of days ago, I posted replies to some of the comments that people had made on my posts about Software Carpentry's future. To recap, I want SC to:

1. offer learning materials so that people can work through them on their own;
2. be a repository where people can evolve those materials;
3. coordinate people who are organizing live workshops, offering technical support [1], etc.; and
4. coordinate a distributed research program to evaluate Software Carpentry's effectiveness.

It would be easier to achieve these four goals if we had merge-friendly formats for learning materials (both micro and macro), a large team of core content developers, and stable long-term financial support. Since we don't have any of those unicorns, what should we try to do in the next six months?

Offer learning materials for self-directed use. If I was grading our existing content, I'd give it a weak B. While only a few episodes are outright failures from a teaching point of view, quite a few could use an overhaul based on learner feedback. What would make more difference, though, would be supplementing them with partially-worked examples, self-tests, and errata-style lists of common misconceptions and their corrections. I think it would take one person-month each to do this for our core topics (the shell, version control, basic programming, testing, sets & dictionaries, and software engineering).

Be a repository for evolving those materials. Anyone who wants our stuff can get it from our Subversion repository, but the "evolving" part is harder. I know a lot of groups have used our content, usually after some extensive tweaking to meet their particular needs. What I don't know is how to get them to give their material back—there isn't a "make, share, and remix" culture in teaching as their is in open source coding [2]. Absent any brilliant insights, I'm going to set this one aside for now.

Coordinate workshops. The inimitable Katy Huff came up to Toronto in November to help us run a workshop, and there are a couple of others in the pipeline elsewhere. This is where I hope to make the biggest strides in the next six months: if all goes well, I will put out a call later this month for people to run workshops in their labs, schools, and workplaces this spring.

Evaluate Software Carpentry's effectiveness. This is easily the most important item in this post: without some reliable way to tell what's working and what isn't, improvement will be slow (and might not happen at all). I still don't understand why most software developers ignore most empirical studies in sofware engineering, but if we do organize a bunch of workshops this spring, I think we can also do some before-and-after questionnaires and interviews [3].

Of course, this would all be easier with your help—if you want to help out, please get in touch.

[1] "Technical support" could be Stack Overflow-style Q&A, but I think real-time desktop sharing with voiceover would be more helpful, since by definition, novices usually don't know what's important to describe and what isn't.

[2] Lots of people (including me) Google for other teachers' slides when they're making up lessons of their own; what they don't do is send their hacks back to the original authors. There are exceptions, of course; I'm particularly interested in LessonCast, a site where teachers can share video tips about lessons and other ideas.

[3] Perhaps modeled on the ones in this paper, but with more of an emphasis on human (development) time than computer (running) time..