The Other Ninety Percent

This post originally appeared on the Software Carpentry website.

Ninety percent or more of learning a skill takes place outside formal lessons as people try things out for themselves and turn attention into habit. This works best if a mentor is on hand to answer questions and provide feedback, but our workshop format doesn't lend itself to that: in most cases, our instructors are back on a plane (or back in their own lab) as soon as they're done teaching, so our learners have to make sense of what they've just been shown on their own. Based on follow-up discussions and Jory Schossau's work, here are things they stumble over in order of increasing pain:

1. Straightforward technical issues, such as not being able to get software to install. This isn't usually a problem for the packages we use in the workshops themselves, but comes up frequently when they try to add domain-specific tools on their own.

2. Less straightforward political issues, such as getting permission to put things on a public software forge like GitHub, or getting the university to set something up internally. This appears to be less of a problem than it was five years ago, but that could be classification bias, i.e., I could mistakenly be putting people who don't use GitHub because they're not allowed in the same box as people who don't use Git because it's intrinsically confusing.

3. Not having somewhere to go for help after the workshop is over. Broadly speaking, our learners need help with things that are specific to their science like, "How do I interpret the output of this genome assembler?" and with generic software development issues like, "How do I recover an old file with Git?" We can't help with the first (though we hope we're creating a community of people who can and will). Sites like Stack Overflow only partly solve the second: many of our learners don't yet know enough to phrase their question correctly, and wouldn't recognize the right answer if they saw one. (SO can also be very unwelcoming: naive questions are likely to be answered with some variation on "RTFM, noob," and if being thick-skinned is a prerequisite for getting help somewhere, that "somewhere" isn't really helpful. Cf. Nick Coghlan's piece on abusing contributors, neatly summarized by Noah Slater.)

We've tried creating a place of our own for our learners to go after workshops, but:

• local meet-ups petered out quickly as people got busy with other commitments,

• our two attempts at a forum fizzled as well,

• online office hours were sparsely attended (we often had more people showing up to give help than to get it), and

• IRC simply isn't going to catch on among non-nerds (something we re-discovered during last summer's sprint).

These failures should be interpreted sceptically, though, because we were a lot smaller two years ago than we are today. People will participate in a group when other people participate; the more people there are, and the more likely each one is to show up, the more likely it is that the next person will get the help (or company) they're looking for. With 287 instructors instead of 50, and with 10,000 alumni instead of 2500, we may finally have the critical mass we need to sustain something.

We'd appreciate comments on other ways people stumble after workshops so that we can try to figure out what to try next. What did you find difficult after your first encounter with us (or with programming for science in general)? What have you seen learners struggle with, and what do you think would have helped them most?