Software Carpentry is a volunteer organization 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 bootcamps (check out this map of where we've been since 2012 and this paper for a detailed history of the organisation).
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).
There's a serious answer:
- The volume of data available to researchers is growing exponentially, which means a simple Excel spreadsheet just doesn't cut it in today's world of big data.
- Most researchers are self taught programmers. 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.
- This rapid increase in data, coupled with the low computational competency of the community, has resulted in something of an irreproducibility crisis in published research. However, the world's most prominent journals are waking up to this problem, and are beginning to require that people submit their code along with their manuscript (a terrifying prospect for most researchers!).
... and also a more humorous take from PhD comics:
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.
For a more in depth discussion of the history, syllabus and benefits of Software Carpentry, check out these talks from the 2013 and 2014 PyCon Australia confernece.
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.