A boot camp is an intensive hands-on workshop in which participants learn software skills based on shorts tutorials and practical exercises. A typical boot camp runs over 2 days with 20-50 attendees, 2-3 instructors, and one helper for every 10 attendees: This page documents our best practices for organising and running a bootcamp. We have divided advice according to the major roles involved in putting on a bootcamp:
We also have some advice on what not to do, which you may find useful as well.
If you have any questions or would like help organising your boot camp, please email us at info@software-carpentry.org. We can:
and many other things as well—just ask. Please note, though, that as a condition of our support, we require boot camp organizers, instructors, and attendees to adhere to our code of conduct.
As an organizer of a boot camp you are responsible for coordinating the entire event.
The first thing you need to decide is your intended audience. Can anyone apply or is it restricted to a specific university or company? Do you want to target people in a particular discipline (or range of related disciplines), or will your boot camp be open to all? You need to decide this early and then stick to it, because the type of boot camp you host will drive other decisions, from the topics covered and the room used to what follow-up sessions you offer (if any).
A closed boot camp can be more easily tailored to a specific audience. In addition, the attendees are more likely to know one another, which in our experience means they're less inhibited about asking questions and more likely to help each other during practical sessions. On the other hand, it may be harder to find enough people to fill a boot camp if you restrict enrollment, and if your funding comes from the university or company level, it may be politically difficult to turn people away.
If you choose a closed boot camp, beware that you may have to resist people trying to open it up once enrollment begins. If you have good reasons to keep it closed or invite-only, keep it that way.
That said, please consider our reasons why you should allow externals to come to your boot camp, even if they attend as observers.
You also need to decide whether your boot camp is free or not. Boot camps traditionally have been free, but we are now frequently charging either a $20 deposit (refunded to everyone who attends both days), or a flat $20 fee, in order to reduce the no-show rate. We have found that both strategies reduce the number of no-shows from 20-25% to 5% or less, and in the case of a flat fee, the money can be used to cover coffee and snacks, local travel expenses, and so on. Be careful if you want to do this, though: as soon as you charge anything at all—even a refundable deposit—some venues will charge you for use of the space.
While team signup is more difficult to manage than individual signup, it also has many benefits, including a lower no-show rate and more in-class peer support. And while we don't yet have any solid data to report, we believe it increases the likelihood of people using what they've learned after the boot camp is over: it's a lot easier for people to put what they've learned into practice if everyone in their lab is doing so at the same time.
Finally, you should decide before the boot camp what kind of follow-up you're going to offer (if any). Some groups have run weekly lunch-and-learn sessions for a couple of months after a boot camp to help people put what they've learned into action. Other groups have set up mailing lists, and we've tried running online tutorials as well (though with disappointing results). Whatever you decide to do, figure it out in advance so that you can tell learners about it at least a couple of times.
Our instructors are volunteers, and do not need to be paid for their time, but boot camp hosts are expected to cover their travel and accommodation costs. (As far as possible, we try to match instructors to nearby sites in order to reduce these, but please see why you should pay instructors' expenses). Some possible sources of funding are:
You may also want to consider these ways to reduce the costs of running your boot camp.
It's much easier for us if instructors deal directly with host sites for reimbursement, but in complicated cases (e.g., several people traveling to do several boot camps, with costs shared between several sites), we can act as an intermediary.
Note: A couple of people have contacted us to ask about running Software Carpentry boot camps commercially. Our material is all Creative Commons licensed, so anyone who wants to use it for corporate training can do so without our permission. What does need our permission is using our name and logo, since they're trademarked. We're happy to give that permission if we've certified the instructor and have a chance to double-check the content (because we've already had one instance of people calling something "Software Carpentry" when it had nothing to do with what we usually teach. We've worked hard to create material that actually helps scientists, and to build some name recognition around it; we'd like to make sure our name continues to mean something.).
It would be great if starving grad students could help pay their bills by doing this, in the way that many programmers earn part or all of their living from open source software; if you'd like to give it a try, please get in touch.
You will need at least two instructors (and three works better):
It's critical that you recruit your instructors before you advertise your boot camp. Ideally, at least one should have co-taught with someone else before leading your boot camp, and the other instructors should have co-taught or been helpers.
Encourage instructors to do a dry-run before the boot camp to check that everything they plan to teach is working. This is especially important if they'll be coding live, which is our recommended teaching style, or if it is their first time teaching: everyone over-estimates how much they'll be able to cover the first time they present, and a dry run helps reduce this problem.
Offer your instructors help with travel and accommodation arrangements. If there is someone at your institution who regularly handles these kinds of things, connect them with instructors as soon as possible.
Many factors determine when to hold your boot camp. The first is obviously the availability of instructors: we often use Doodle to converge on dates that work for everyone, and are happy to set this up.
If you hold the boot camp at a university, keep in mind that the start of term works better the end of term (when people are tired, and busy with final assignments and exams), and that the start of the second (or subsequent) term works better for graduate students than the start of first term (the start of an academic year is busy anyway, and by their second term most students have a better idea of their research problem's programming needs). In our experience mid-term breaks and reading weeks have not worked well: boot camps held then usually have high no-show rates.
You could also schedule a boot camp immediately before or after a conference (or run it as a tutorial within a conference) to target people from a specific discipline. If you do this, involve the conference organizers early and often.
You'll need a room with:
The boot camp will run more smoothly if you have two projectors so that interactive demos can be shown alongside supporting slides, and also space for food and drink so that everyone can snack as they're working. Rooms usually aren't set up for the first, though, and there are often rules against the second.
Start by checking out previous boot camps for ideas on what to cover. Remember, our license lets you use and re-mix materials freely, provided you cite us as the original source. (We would also appreciate a chance to look at any improvements or additions you make so that we can update our own copies—please send us email or a pull request.)
For example, your schedule might look like this:
| Day 1 | |
| 8:30 - 9:00 | Setup Help |
| 9:00 - 10:30 | The Shell |
| 10:30 - 12:00 | Python Variables |
| 12:00 - 1:00 | Lunch |
| 1:00 - 2:00 | Python Data Structures |
| 2:00 - 3:00 | Python Control Flow |
| 3:00 - 4:30 | Python Functions and Modules |
| Day 2 | |
| 9:00 - 10:30 | Version Control (Local Operations) |
| 10:30 - 12:00 | Version Control (Collaborating) |
| 12:00 - 1:00 | Lunch |
| 1:00 - 2:30 | Debugging |
| 2:30 - 3:30 | Testing |
| 3:30 - 4:30 | Documentation |
In almost all cases, learners want to use their own laptops during boot camps so that they leave with a working environment set up. Even if you ask attendees to prepare beforehand, and give them detailed instructions, some will not and some won't be able to. You should therefore schedule time for checking the learners' machines at the beginning of the first day to save you from repeating the same thing individually to each attendee.
Decide when you'll start and end each day, what you'll cover, and when breaks and lunch will be. A later start on the first day (e.g., 09:30 instead of 09:00) gives people who don't live nearby a better chance of being there for the start. Similarly, an earlier end (e.g., 16:30 instead of 17:00) allows non-locals time to travel home. Some attendees may also have child-care needs; it's worth asking about this by email before the boot camp starts so that people can respond one-to-one if they want to.
Most of our helpers are scientists who have either gone through a previous boot camp, or learned most of what we teach on our own. You can usually recruit them locally from your own and nearby institutions, and should have at least one helper for every ten attendees. Most boot camps don't cover helpers' travel or accommodation expenses, but taking them out to dinner the day before the boot camp starts is a nice way to thank them (and gives them a chance to meet the instructors).
Find out if your institution or venue expects you to use their in-house registration system. If so, use it; if not, we recommend EventBrite, and we are happy to host registrations on our account. Either way, make sure you enable a waiting list, because boot camps are very popular.
Create a web page with information about the boot camp: what it is, when it will be held, a link to the registration page, local travel information, and anything else you think attendees might need to know. It's best to keep this web page separate from the registration page so you have more control over both style and content.
We can provide advice on how to advertise and are happy to publish your blog articles and tweets to our followers. We can also help to promote boot camps, either by advertising them or hosting your web page. If you are interested, please email us.
If you plan to photograph, record, or broadcast your boot camp then mention this on its web page. Your institution may require you to obtain a signed photo release from each person if pictures are being taken.
Tweet and blog about the event and send emails to departmental mailing lists, discipline-specific mailing lists, specific people (e.g., lab directors or principal investigators), and anyone else who you think will be interested. Remember to include links to the advertising web page and the registration page. A sample page is shown below.
When: May 14-15, 2013, 9.00 am to 5.00 pm.
Where: Room 99, Tesla Memorial Hall, Euphoric State University.
What: Our goal is to help scientists and engineers become more productive by teaching them basic computing skills like program design, version control, testing, and task automation. Our teaching emphasises how these skills can contribute to quality, usable, reproducible research. In this two-day boot camp, short tutorials will alternate with hands-on practical exercises. Attendees will be encouraged both to help one another, and to apply what they have learned to their own research problems during and between sessions. There will be online follow up sessions for six to eight weeks extending the material from the boot camp.
Who: The course is aimed at postgraduate students and other scientists who are familiar with basic programming concepts (like loops, conditionals, arrays, and functions) but need help to translate this knowledge into practical tools to help them work more productively.
Requirements: Attendees must bring a laptop with a few specific software packages installed. The list will be sent to attendees a week before the boot camp.
Content: The syllabus for this boot camp will include:
- Using the shell to do more in less time.
- Using version control to manage and share information.
- Basic Python programming.
- How (and how much) to test programs.
- Working with relational databases.
Registration: Please use the form below to register by April 6. We will allocate places to individuals and groups we believe will benefit, while aiming for a balance of subjects and geographical areas. We strongly encourage learners to attend with colleagues, so please create or join a team when you sign up. Ideally we would like teams of 3 to 6 members, and we will give preference to teams including one more knowledgeable member who is interested in organizing further training at their own institution.
We will notify all applicants as to whether they have a spot no later than April 13. Note that a $20 deposit is required to register. This will be refunded to everyone who attends both days of the workshop.
Contact: For further information please email us at software-carpentry@euphoric.edu.
If you can afford to provide coffee and snacks for attendees, do so: it cuts the time per coffee break to 10-15 minutes from 20-25 minutes. If you cannot do this, make sure that there is somewhere nearby where attendees can purchase refreshments, and schedule time accordingly.
If you are providing snacks, try to allow for allergies and other dietary restrictions. Please also make sure attendees have been told whether they can bring drinks and snacks into the room being used for the class.
Set up a mailing list for organizers, lecturers, and helpers as soon as your boot camp is confirmed so that you can inform everyone about the latest news, organize who's teaching what, etc. You may also set up a mailing list for attendees, but we have found it's easier to use the registration system to broadcast information as needed.
Make sure to have people sign in on both days (particularly if you have required a refundable deposit), and forward this list to us if possible so that we can invite people to join our announcements list, contact them about follow-up interviews six months or a year later, etc.
Make your materials available to both the helpers and the attendees. publishing your slides, code, and scripts to the helpers in advance Having access to these materials allows learners to catch up in their own time if they fall behind, and lets helpers fill in gaps in their own understanding before the boot camp starts. The easiest way to do this is to clone our boot camp repository on GitHub.
Publish the list of software you expect attendees to have installed before they arrive. Our setup pages describe the software we usually use.
You should also provide installation instructions for any software specific to your boot camp. Make sure you test your instructions on standard operating systems on Linux, Windows, and Mac OS before you make them public.
Add a link from your advertising web page to your setup instructions. Be clear that attendees are expected to set up their computers before arriving at the boot camp, and that they should email you if they have problems. (And by "before", we mean over a week before, not the day before or the evening before—this will save time on the day.) If your attendees are all local then you may want to consider having a drop-in setup clinic a day or two before your boot camp.
If you are using something other than first-come/first-served registration, select the attendees you want to attend and let them know they have a seat. Ask them to tell you as soon as possible if they can't make the boot camp, so that you can offer their place to someone else.
Once registration is complete, email attendees to have them set up their computers as described above. Email people who didn't make it into your selection to let them know that they'll be held on a on a waiting list just in case an attendee drops out.
You may want to send out a questionnaire prior to the boot camp to assess the expertise and interest of the attendees, where they come from, what their research areas are, and what operating systems they'll be using. This allows you to customise what you present, and how you present it. We are currently (March 2013) preparing templates to use for both purposes; please email us for details.
Collect the equipment listed in the checklist at least a day before the start of the boot camp.
Please track your preparations against the checklists below, and let us know if we should add anything to help future organizers.
Send one last email to:
then send us a blog post about how it all went, and take the rest of the day off—you've earned it.
Your job is to give lectures and lead practical exercises. You should also mingle with the attendees during practical sessions, but remember to give your voice a rest as well: your helpers are there to help.
It isn't necessary for every instructor to know all of the material, but it helps, particularly if someone can't make it at the last minute.
Finally, remember that no lesson plan survives contact with the audience. We try to keep boot camps small so that instructors can respond to learners' questions puzzled looks, and/or signs of impatience.
Note:
Etherpad is a real-time collaborative text editor.
We have found it helpful for taking notes and sharing code snippets during lessons.
If you choose to use it,
stick to a sensible naming convention
(e.g., bootcampname-date-lesson)
so we can track down Etherpads later.
Alternatively,
create an account on
etherpad.mozilla.org
to automatically track the pads you create.
As a helper, your job is to help the attendees during practical sessions. Your secondary responsibility is to learn the material well enough to teach it yourself in future if you choose to do so.
No discussion of how to teach a boot camp would be complete without some discussion of what not to do. To that end, here are a few common mistakes.
Your audience will never care more about what you're teaching than you appear to, so if they get the feeling you're not interested in it, they won't be either. This does not mean you have to shout, crack three jokes a minute, or harangue them about how this stuff is really, really important, but you do owe it to your audience to show up mentally as well as physically.
You're not there to reproduce one of our online videos in person: you're there to interact with people so that they get a better learning experience. You shouldn't ever go more than two or three minutes without asking a question (and listening to the answer), and if it has been 15 minutes since any of your learners asked one, odds are you've either lost them or are boring them.
Done right, Software Carpentry boot camps are a great networking opportunity for our learners (and for us, too). If you don't know half your learners by name at the end of two days, you're doing it wrong; if they haven't each made at least half a dozen new contacts, that's your fault too. Have them work in pairs, and require them to mix up the pairs at least a couple of times. Equally, encourage them to chat to one another at coffee breaks and lunch, and to get a pizza or some curry together for dinner on the first day.
The more time folks spend with their hands on the keyboards doing exercises, the more time they're actually paying attention. The students have their computers in front of them: if you talk for more than five minutes without asking them to use their computers, they'll do so anyway—on Facebook.
Typing too fast, using shortcuts or commands they haven't seen yet—basically, any time you say, "Don't worry about this just now," or they say, "Wait, how did you do that?" or, "Can you please slow down, I can't keep up," you're no longer actually helping them.
You can't optimize without feedback, so:
And remember: feedback is pointless if you don't pay attention to it (or worse, if you explain it away). There's no point collecting feedback after each boot camp if you don't change what and how you teach to reflect it.
It's OK to make mistakes and not know things—in fact, stumbling in front of your learners and then picking yourself up is a great teaching opportunity. But if they believe you don't have a solid grasp of the concepts underlying the material you're teaching, they will have less confidence in everything you say, even when you're right.
Most of our learners are graduate students in science and engineering, so they know what evidence looks like, and why working practices should be evidence-based. That doesn't mean you have to have the whole of empirical software engineering at your fingertips in order to teach, but please do read Facts and Fallacies of Software Engineering and sprinkle a few of the findings it quotes into your lessons.
The things we teach reinforce each other, so tie them together at every opportunity. Point out that connecting things with pipes in the shell is like chaining functions together, or that they can use a shell script to re-run a bunch of different tests before committing to version control, and so on. If possible, take 15 minutes or so each day to show them how you use these tools in your day-to-day work.
Something always fails to install for someone, or a bunch of learners are accidentally locked out of the building after lunch, or whoever was supposed to drop off power bars didn't. Roll with it, and remember to laugh (even if it's a bit hysterically).
Do you have enough power outlets? (Are you sure?) Do you have enough bandwidth to handle fifty people hitting your version control repository at the same time? (How do you know?) Can everyone actually log in? And while we're here, does campus security know you're using the room over the weekend?
There are four reasons why we expect hosts to pay for instructors' travel and accomodation costs:
There are a number of ways you might want to consider to reduce the cost of running a boot camp:
There are a number of reasons why you might want to consider allowing externals to come to your boot camp, whether they be researchers wishing to learn software development skills or potential hosts who want to see how one is run: