How to Run a Boot Camp

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:

  • Organisers plan the logistics bootcamp (facilities, staff, transportation, food, etc).
  • Instructors give the lectures, lead the practicals, and help the attendees during practical sessions. Our license allows anyone who wants to use our materials to do so, but we maintain a list of badged instructors, and are happy to help match instructors with sites that want boot camps.
  • Helpers provide assistance during practical sessions. Helpers have often attended a boot camp themselves at some point, and are on the road to becoming instructors.

We also have some advice on what not to do, which you may find useful as well.

We're Here To Help

If you have any questions or would like help organising your boot camp, please email us at info@software-carpentry.org. We can:

  • recruit instructors,
  • advertise your bootcamp,
  • handle registration,
  • tell you what's worked (and hasn't) in the past,
  • help you customize material for particular audiences,
  • support requests for funding,

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.

For Organizers

As an organizer of a boot camp you are responsible for coordinating the entire event.

1. Decide what kind of boot camp you want

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.

2. Secure funding

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:

  • "Miscellaneous" funds (e.g., a couple of thousand dollars in a faculty member's grant). This is by far the most common case.
  • Training budgets at the lab, department, or institutional level.
  • Workshop budgets set aside as part of conferences.

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.

3. Recruit your instructors

You will need at least two instructors (and three works better):

  • It's too much to ask a single person to talk for eight hours a day for two days.
  • Attendees will be more engaged if they hear from more than one person.
  • Things can always go wrong at the last moment, so having two or three instructors reduces the risk of having to cancel because of illness, travel mishaps, etc.

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.

4. Choose your dates

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.

5. Book a room

You'll need a room with:

  • Front-facing tables so that attendees can watch an instructor and use their laptop at the same time. (Typing on a laptop for two days in theater-style seating can cause back strain.)
  • High-speed WiFi or network access that can withstand everyone using it at the same time.
  • Power outlets for all the computers. This often involves extension cords; if you're doing that, make sure they're taped down.
  • Space for mingling without squeezing between chairs and tripping over cables. This is essential: if helpers cannot reach learners who are having problems quickly and easily, those learners will fall further and further behind as the day goes on. Again, theater-style lecture rooms are not recommended as their banked floors and fixed seating makes it very difficult for helpers to mingle.
  • A microphone if the room is large or has poor acoustics, or if you are recording the lesson.
  • Disabled access. (Make sure the washrooms are accessible as well…)
  • Air-conditioning, because all those computers (and attendees) will generate a lot of heat.

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.

6. Create your timetable

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.

7. Recruit your helpers

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).

8. Set up registration

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.

9. Advertise

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.

10. Arrange catering

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.

11. Set up mailing lists

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.

12. Publish your materials

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.

13. Publish attendee setup information

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.

14. Select attendees

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.

15. Send out a pre-camp questionnaire

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.

16. Gather your gear

Collect the equipment listed in the checklist at least a day before the start of the boot camp.

Checklists

Please track your preparations against the checklists below, and let us know if we should add anything to help future organizers.

The week before

  • Request confirmation from attendees that they will be attending.
  • Let the people on the waiting list know if they can attend or not. (You may want to invite ten or so locals from the waiting list to turn up. If there are still empty seats at mid-morning on the first day, then they're welcome to stay. If not, they're welcome to come back for the next one, but make it clear before they arrive that their participation is not guaranteed.)
  • Remind attendees of the setup page, and make it clear that they are expected to set up their computer before they attend the boot camp and to email for help if they have a problem.
  • Send a pre-boot camp questionnaire if you are using one.
  • Ask your instructors to put their materials and practical exercises on your web pages so that attendees can refer to them during the boot camp. Data files or other useful information should also be made available for download.
  • Take your instructors and helpers to dinner the evening before the boot camp starts.
  • Contact your helpers to see if they have any questions and remind them to arrive 10-15 minutes early so they can be briefed.
  • Remind instructors and helpers to familiarise themselves with all the material (especially the instructors, in case one has to cover for another) and to set up the boot camp software on their laptops.
  • Identify a suitable venue nearby for socialising after the first day.

The day before

  • Is the building and the room going to be unlocked on the day of the event?
  • Is the room clearly signposted?
  • Do you know where the toilets are?
  • Is there any noisy construction/cleaning going on and, if so, can you do something about it?
  • Is the network/WiFi working?
  • Have you set up network/WiFi guest accounts?
  • Do you have a contact number for maintenance and technical support?
  • Have you double-checked with catering?
  • Have you emailed a reminder to everyone?
  • Have you set up all the accounts, web sites, and repositories you will need?
  • Do you have name badges for learners, helpers, and instructors?
  • Do you have somewhere to socialise in after the first day?

Equipment

  • A projector (and a spare if you can find one, or a spare bulb if you can't).
  • A Mac VGA adapter if anyone is presenting with a Mac.
  • Extension cords if necessary so that everyone has access to power.
  • Two different colors of Post-It notes for use as flags and for feedback.
  • Guest WiFi or network usernames and passwords for everyone.
  • If possible, a couple of spare machines with the required already installed software in case someone can't get access to the network, forgets their machine, has hardware problems, etc.
  • An attendance sheet to keep track of who actually attended.
  • Photo release forms (if required).
  • Name badges for instructors, helpers, and attendees.

Before welcoming people on the first day

  • Put up any signs to the room.
  • Give instructors and helpers their badges.
  • Remind helpers of their role: mingle, answer questions, and help attendees.
  • Ensure that helpers are seated around the room.
  • Give everyone a few minutes to plug-in, get on the network, and settle in.

First-day welcome

  • Tell the attendees who the instructors and helpers are, explain what they're there for, and get them all to wave.
  • Make network connection instructions available on a hand-out or projector.
  • Tell everyone what Twitter hash tag you're using.
  • Circulate the attendance sheet and photo release form.
  • Remind everyone of the code of conduct.
  • Give everyone sticky notes.
  • Quickly remind everyone of the schedule.

During the boot camp

  • Collect feedback before every break.

At the close of the last day

  • Ask attendees for more substantial feedback.
  • Collect the attendance sheet and photo release forms.
  • Remind attendees of any follow-up sessions you have planned.
  • Tell attendees that we are always looking for more helpers and instructors, and that we run a short online training class for people who are interested, then ask if they would like to join our team. If so, note down their contact details and forward them to us, or have them contact us at info@software-carpentry.org.

The day after

Send one last email to:

  • distribute a feedback questionnaire (if you have one);
  • remind attendees about follow-up sessions (if you have any); and
  • remind attendees to get in touch if they'd like to join our team,

then send us a blog post about how it all went, and take the rest of the day off—you've earned it.

For Instructors

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.

Before

  • Arrange travel to the boot camp site, accommodation, and transportation from wherever you're staying to wherever you're teaching. Save your receipts!
  • Prepare your materials:
    • data sets
    • cheat sheets
    • exercises
    • repositories
    • Etherpad.
  • Do a practice run of your tutorials and practicals, especially if you'll be coding live (our recommended teaching approach).
  • Ensure you have the same setup as the attendees by working through your own setup pages.
  • Post your practical exercises on web pages to allow students to refer to them during the boot camp. Data files or other useful information should also be added.
  • Familiarise yourself with the material your fellow instructors will be presenting, just in case one of them pulls out.

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.

On the day

  • If you are using multiple windows (e.g., a command window and an editor window) make sure they are both large enough to be visible by all attendees. Remember to pause when switching from one window to the other so that learners don't become confused. If possible, use different background colors for different text windows to make it easier for learners to tell them apart (but keep in mind red-green and blue-yellow color blindness).
  • As you type at the command line, read out what you're typing. Remember that most learners can only go half as fast as you, because they have to watch you type, then type it all in again themselves.
  • If possible, use Etherpad or something similar to share code snippets with learners. We can help you set this up if needed.
  • Back up the material with your own anecdotes, experiences and evidence—it makes you more credible, helps learners understand how to apply what you're teaching to their own problems, and prevents the lectures from becoming too dry.
  • Emphasise that good software development skills contribute to productive, reproducible, reusable research.
  • For every question with a binary answer (yes/no, have done/have not done, works/does not work), ask learners to hold up green (yes) or red (no) sticky notes so that you can gauge their level of understanding. This also keeps them more engaged.
  • When you ask attendees to do a practical exercise, have them post a red note on their laptop if they run into trouble and a green one when they have a solution. This lets you gauge how learners are progressing, and lets helpers see who needs their assistance.
  • Just before each break, have learners write down one good point on their green sticky and one bad one on their red sticky and hand them in. It only takes a couple of minutes to sort through these, and it quickly tells you whether you're going too fast or too slow, whether you need to review some material after the break, etc. If you can, put each batch of sticky notes into an envelope and send them to us so that we can look for patterns.
  • If people would rather not write on sticky notes, ask each person in the room to give you one good point or one bad one at the end of the final day (without repeating anything someone else has already said). Again, please send us this feedback so that we can look for patterns.

The day after

  • Tell us what worked and what didn't so that we can improve future boot camps.

For Helpers

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.

Before

  • Ensure you're familiar with or have read over the material that the instructors will cover in the sessions you're helping with.
  • If you have time, try and work through the setup information for the boot camp before you come along. Many of the questions you will get on the first day will be related to installation issues.
  • Read the blog posts by Katy Huff and Aleksandra Pawlik on how to be a helper.

On the day

  • Go round the room and look for attendees who need help. They may be holding up a red sticky note, but they may also just be sitting there looking despondent or peering intently at their laptop.
  • If you can't answer an attendee's question, tell them that and ask an instructor for help. Do not dive into a 20-minute debugging session on their laptop…

The day after

  • Tell the organisers what you think worked and what didn't so that we can improve future boot camps.
  • Let us know if you'd like to become an instructor yourself.

What Not To Do

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.

Bore them.

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.

Ignore them.

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.

Let them ignore each other.

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.

All talk, no action.

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.

Use magic.

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.

Don't close the loop.

You can't optimize without feedback, so:

  • Give them all red and green sticky notes so that they can put up a green one when they're finished an exercise, and a red one when they have a question or need setup help.
  • Have them write down good and bad points before each break so that you can tell right away what you're doing right and wrong.
  • Make sure to leave at least 20 minutes at the end of the final day for feedback (whether it's a verbal "one good/one bad" report, filling in an online survey, or whatever else you're using).

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.

Don't master the material yourself.

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.

Don't tell them "why".

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.

Show them the forest but not the trees.

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.

Underestimate setup time.

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).

Underestimate setup requirements.

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?

Why you should pay instructor travel and accomodation costs

There are four reasons why we expect hosts to pay for instructors' travel and accomodation costs:

  • As instructors give their time for free, it's only courteous to offer this.
  • It may be more difficult to get instructors to come to your boot camp if you don't, as you're making them pay to deliver a service to you.
  • "host pays costs" is part of Software Carpentry's sustainability model.
  • Paying only travel and accommodation expenses is still a lot cheaper than recruiting a private training organisation. And, unlike those, Software Carpentry is designed specifically to meet the needs of researchers.

Ways to reduce the costs of running your boot camp

There are a number of ways you might want to consider to reduce the cost of running a boot camp:

  • Use your professional network to see if there are others in your institution or community who are willing to help with instructor travel expenses, room bookings or other costs. They may be willing to share costs if their researchers can attend your boot camp…
  • …or just go all-out and agree to run one jointly.
  • Use local instructors and helpers (by local we mean from within your institution, region or country) who will have lower travel costs.
  • Co-locate with conferences or workshops being run by your institution or within your community.

Why allow externals to come to your 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:

  • Others can see how a boot camp is run and so decide whether they want to run one too, which contributes to the growth and sustainability of Software Carpentry.
  • Attendees are given the opportunity to network and build relationships with researchers from elsewhere within your institution or community or foster cross-disciplinary collaboration.
  • Your profile is raised within your institution or community as one experienced in hosting boot camps which means others may seek your advice when they come to run theirs.
comments powered by Disqus