Software Carpentry is a volunteer organization whose goal is to make scientists more productive, and their work more reliable, by teaching them basic computing skills. Founded in 1998, it runs short, intensive workshops that cover program design, version control, testing, and task automation. Software Carpentry has been a Mozilla Foundation project since January 2012, and part of the Mozilla Science Lab since June 2013.
Because computing is now an integral part of every aspect of science, but most scientists are never taught how to build, use, validate, and share software well. As a result, many spend hours or days doing things badly that could be done well in just a few minutes. Our goal is to change that so that scientists can spend less time wrestling with software and more time doing useful research.
Many people have helped Software Carpentry grow by creating lessons, teaching bootcamps, and building its web site—you can find a fuller description in this blog post.
The costs associated with particular bootcamps are covered by their hosts: our instructors are volunteers, so these costs usually amount to air fare and accommodation (if instructors are coming from out of town). Central costs, such as administration, instructor training, and website development, are covered by a grant from the Alfred P. Sloan Foundation and by donations from bootcamp hosts. More than twenty other organizations have also supported us since we ran our first class at Los Alamos National Laboratory in 1998.
Our core topics are:
Depending on the audience, bootcamps may also include an introduction to:
The name "Software Carpentry" and the Software Carpentry logo are both trademarked, and may only be used with our explicit prior permission. We normally grant this to any training course that covers our core topics; please contact us by email at admin@software-carpentry.org for more information.
We have documented our experiences in "Best Practices for Scientific Computing" and "Software Carpentry: Lessons Learned", and in a handful of popular blog posts. For more information, please see our web site at http://software-carpentry.org, or contact us by email at admin@software-carpentry.org.
Our instructors are scientists themselves—in fact, many are bootcamp alumni.
For many reasons:
We offer a free online training course for people who would like to teach Software Carpentry, and to learn more about teaching in general along the way. The course takes 2-4 hours a week for 12-14 weeks (depending on interruptions); most work is done on trainees' own time, and is posted to the course blog.
While we would like to help everyone learn how to teach programming, space in the course is limited. We therefore give preference to people who have taken part in a bootcamp themselves, are planning to host a bootcamp, or have relevant prior experience. For more information, please send us email.
A core contributor is someone who can commit changes directly to our shared repositories. The process for becoming one is taken directly from the Python project: when you have consistently contributed patches which meet quality standards without requiring extensive rewrites prior to being committed, you may qualify for commit privileges and become a core contributor of Software Carpentry. You must also work well with other core contributor (and people in general) as you become an ambassador for the project.
Typically a core contirbutor will offer you the chance to gain commit privileges. The person making the offer will become your mentor and watch your commits for a while to make sure you understand the development process. If other core contributor agree that you should gain commit privileges you are then extended an official offer.
You may request commit privileges yourself, but do not be surprised if your request is turned down. Do not take this personally! It simply means that other core contributors think you need more time contributing patches before you are able to commit them without supervision.
If you don't want to teach, there are many other ways you can help, such as writing new lessons, answering learners' questions online, and maintaining this web site: please see this page for details. We are also always looking for more sponsors: please mail us if you'd like to help with that.
We appreciate being mentioned in the acknowledgments sections of papers, theses, and proposals, as it helps us show current and potential funders what impact we're having. If you would like to do this, please use something like the following:
We were aided in this work by the training and other support offered by the Software Carpentry project [1].
[1] Software Carpentry: http://software-carpentry.org.
Software Carpentry has a close relationship with the Software Sustainability Institute, which manages bootcamps in the United Kingdom. We have worked with them since June 2012 to develop a "driver's license" for the DiRAC supercomputing consortium.
We are working with the IPython team to develop an IPython Notebook plugin that will synchronize a voice-over soundtrack with a step-by-step display of a notebook, thereby creating a screencast-style presentation in the browser. For more information, please see the Browsercast project on GitHub.
Here are a few places where our work has been mentioned:
All of our slides, notes, and example programs are in Git repository at https://github.com/swcarpentry/bc, and the source for our website (including our blog) at https://github.com/swcarpentry/site.
Shirts, mugs, stickers, and buttons are for sale in our CafePress store.
We spell "bootcamp" as one word.
A bootcamp is an intensive hands-on workshop, typically two days long, that covers the core skills needed to be productive in a small research team.
Not all of it—not even most of it—but enough to do your work more efficiently, and to start taking advantage of online resources like Stack Overflow that assume a certain level of background knowledge.
Our audience is as diverse as science itself, so we do our best to tailor our teaching to each group's needs. However, any bootcamp that wants to use our name and logo must cover a few core topics.
Data visualization, high-performance computing (HPC), Perl: the list of things we don't teach is much longer than the list of things we do. As with every curriculum, the question is not, "What would we like to add?" but, "What are we willing to take out in order to make room?" We believe our core topics are the absolute minimum scientists need to know in order to do computing well. We also believe that topics like HPC are covered well enough by other groups.
Some bootcamps charge $20-$40 for registration, primarily because it reduces the number of people who register but not attend from 20-25% to roughly 5%.
The only truly necessary skill is a desire to become more efficient. Each bootcamp is unique, and people with different skill levels will bring home different lessons, but everyone will learn something useful. That said, when we have enough space and instructors, we do try to stream people according to prior knowledge so that we can tailor training for them.
In most cases, yes: bootcamps are meant to be hands-on, which means your hands should be on a keyboard while you're learning. While some sites have training machines, we encourage people to bring their own laptops so that they leave the bootcamp with a working set of tools installed and operational.
We also ask people to install the software their bootcamp requires before showing up, so that we don't have three dozen people trying to download installers through the same wireless network at once. Each bootcamp's instructors will circulate a list of required software (and installation instructions) well in advance of the start.
Between 1998 and 2012, we taught this material in intensive week-long courses, as a regular university course, and online, with varying degrees of frustration. It turns out that researchers are busy people: improving their computing skills will make them more productive in the long run, but in the short run, they have to get a grant proposal in by Thursday, mark mid-terms by Monday, and meet a paper deadline next week. While two days may not sound like much, it's all many researchers can fit in.
Our learners are typically graduate students in science, engineering, medicine, and related research-intensive disciplines who have written a few lines of code (either on their own or for an "Intro to Computing" class as undergrads) but aren't familiar with computing's equivalent of good laboratory practices. These short bios are representative of their needs and how we can help.
Yes: two independent studies in 2012 found that people really were learning useful things, and these testimonials from past participants show just how much difference a couple of days of training can make. We are now using standardized pre- and post-assessment questionnaires and interviews to gain more insight.
Along with their immediate benefits, bootcamps are a great opportunity to network with like-minded researchers. These skills are also useful for people transitioning out of research into other careers in science, technology, engineering, and medicine.
Bootcamps usually run for two consecutive days, starting at 8:30 and running to 4:30 or 5:00 each day with breaks for coffee and lunch. A typical boot has 40 learners, 2 instructors, and 2-3 helpers wandering the room answering questions during practical sessions. (These helpers are often alumni of previous bootcamps who are hoping to become instructors themselves.)
Short tutorials alternate with hands-on practical exercises, and participants are encouraged both to help one another, and to apply what they are learning to their own research problems during, between, and after sessions. Participants usually use their own computers (typically laptops) so that they leave with a working environment set up, though we also provide a standard set of packages running in a virtual machine.
Dates and venues of upcoming bootcamps are on our calendar. They are also announced on our blog, on Twitter, and through our announcements list.
Absolutely. We have found in the past that if people attend in groups (e.g., if a whole lab's worth of students show up together), then everyone gets more out of the training. People who sign up together are more likely to have similar interests and backgrounds, and are usually less inhibited about asking questions, and asking one another for help, than total strangers. Plus, it's a great opportunity to wear that departmental t-shirt that's sitting in your drawer...
If you'd like us to teach a bootcamp for you, the first step is to get in touch. We'll find instructors in your geographic and/or academic area, and do advertising, registration, and software setup, while you'll take care of travel costs and administrative overheads, booking space, local publicity, finding helpers, and catering (if desired). If you want to know more about what is involved in running a bootcamp, please see our operations guide.
Anyone who wants to run a bootcamp can do so—all our teaching materials are freely available under the Creative Commons Attribution license, so you are free to re-use and re-mix them when and how you want so long as you cite us at the original source (e.g., by providing a link back to this site). If you want to know more about what is involved in running a bootcamp, please see our operations guide.
While anyone can run a bootcamp, the name "Software Carpentry" and our logo are both trademarked, and may not be used without our explicit prior permission. We're all in favor of teaching people iPhone game programming, multigrid methods using C++ and MPI, and scientific grant writing, but we've worked hard to establish an identity for Software Carpentry, and wish to protect it. We will usually give permission to any training that covers our core topics, but prefer that people take part in the instructor training discussed below.
Yes, but you may not call your course "Software Carpentry" or use our logo without first obtaining permission.