Software Carpentry is a volunteer organisation whose members teach basic software skills to researchers in science, engineering, and medicine. It was founded in 1998, but really came to prominence in 2012 when it shifted to a teaching model centred around intensive two-day workshops (check out this map of where we've been since 2012 and this paper for a detailed history of the organisation).
Most researchers are self taught programmers (there is very little programming in undergraduate training). As a result, they spend hours doing things that should take minutes, reinvent a lot of wheels, and still don't know if their results are reliable. What's worse, this lack of formal training makes researchers embarassed about their coding skills, which means they suffer in silence rather than reaching out for help.
PhD comics captures this angst perfectly:
Our goal is to teach a handful of best practices in scientific computing, so that researchers can get more done in less time. Our goal is not to produce professional programmers. By way of analogy, we think every researcher should know about as much about computing as they do about statistics. Most researchers don't have a degree in statistics, but at some point they've learned what correlation means, what statistical significance is, and so on.
The syllabus covers three major domains:
- The command line
- Programming fundamentals (readability, defensive programming, testing, etc)
- Version control
The focus is very much on concepts, not specific tools. This means that a Matlab user can come to a bootcamp and get a lot out of it, even if the programming content is taught using Python. Once you understand the fundamental concepts underpinning effective scientific computing, you can teach yourself the tools that you need to use (the reverse isn't usually true).
Most qualified Software Carpentry instructors are research scientists and not professional software developers. This avoids a well-known teaching phenomenon called expert blind spot. In other words, Software Carpentry instructors can still remember what it's like to not understand this stuff, which makes them better teachers.
The syllabus is delivered via lecture/demonstration (via live coding most of the time) interspersed with regular challenges to be worked on in pairs. During the live coding participants usually sit back and watch, and then during the challenges they have an opportunty to try things out and ask questions (i.e. it is not expected that participants will follow along with the live coding on their own machine). There's no need to take notes, as copies of all the teaching materials are available on the Software Carpentry website (see here).
If you're having trouble at any point, put up a red post-it note and a helper will come to your aid. If things are going well, put a green one up. In fact, at any point during the bootcamp it's inevitable that some people will be finding the material too easy, while others will be struggling to keep up. In this case the former should help the latter - Software Carpentry is as much about fostering supportive computing communities as it is about actually teaching the nuts and bolts of programming.