I have recently organised a bootcamp at the University of Southampton, as part of my Software Sustainability Institute fellowship. I hadn't actually attended a bootcamp before (I was meant to, but unfortunately had to cancel) so it was a little nerve-wracking doing all of the organising - it all worked out well in the end though.
The bootcamp was primarily for students at the Institute for Complex Systems Simulation, from which we got around 35 students, with 15 students from the university's Computational Modelling Group making up a grand total of 50 attendees. As the course was primarily designed for the ICSS, I did a very early pre-questionnaire asking what topics the ICSS students would like to cover - which was very much appreciated - and this early discussion got registrations off to a good start. In fact, we had around 20 people on the waiting list at one point, which allowed us to easily fill up places when people dropped out. In the end we had 48 people registered on the day, of whom 42 attended.
There were some changes in the team of instructors during the planning of the bootcamp, as one instructor dropped out part way through the planning process, but we still managed to keep going with the same topics we had planned, and were instructed by Nelle Varoquaux and James Morrison. The ICSS at Southampton kindly paid expenses for the instructors, and provided us with very tasty buffet lunches as well as coffee/cakes for the morning and afternoon breaks.
At the end of the final day we did the traditional good-point, bad-point questions around the room and got the useful comments below:
|Generally very useful
|Software issues and installation x 2
|Great to have formal training on self-taught skills
|More examples for makefiles were needed
|Need longer gaps between instruction and exercises - time to catch up x 2
|Ability to summon help at any time x 2
|Need more time on problems and more open-ended problems
|Very hands on x 2
|Very complex for those with less programming experience x 3
|Pre-selection, tailored to topics we want
|Exercises were rather 'bitty' and 'made up' - we could have one big problem used for the exercises and the bootcamp would then take us through the whole process
|Reproducible research + electronic lab notebooks
|Need examples on how I can apply these in day-to-day science NOT software engineering (and not assuming I release libraries etc)
|Etherpad was useful, but not necessary to be projected all the time
|Should have more on reproducible research including tools
|Got to do things we'd heard about but had never tried
|Rapid flipping from editor to terminal was confusing - use two screens?
|Should use a Dropbox shared folder (or equivalent) rather than copying and pasting from Etherpad
|Provide key 3rd party resources to go further, not just software carpentry online lessons
|Need clearer instructions for some of the exercises
|Need context for some exercises eg. didn't know that DNA was composed of CGAT, what are .pdb files etc?
From the post-event questionnaire, 100% of respondants found the boot camp enjoyable, useful and will apply some of the techniques in their work.
The room we managed to book for the bootcamp (85 / 2207 for anyone reading this in future before another bootcamp at Southampton) worked very well. It was large enough to fit all of the attendees in, was air conditioned, had plenty of space for helpers to move around, and had space outside for people to mill around during the lunch and coffee breaks. We deliberately re-arranged the room to have a large central aisle with tables either side, so that the helpers only had a maximum of four people to squeeze past to help someone, and this was very effective. The only improvement to the room would have been having two projectors - we did bring a spare projector and use it, but it was so dim that we decided we couldn't really use it for important things (hence putting the Etherpad on there).
As with all bootcamps, we struggled with a wide mix of students coming to the course - some of which had very little (if any) experience with Python. However, we managed to keep most people with us, and I don't think anyone didn't turn up for the second day. We had a lovely comment that "I am really pleased with myself that I stayed until 5pm and am coming back tomorrow - so that is good news, thanks!". In fact, that comment came through the brilliant red/green post-it note feedback mechanism. We used these post-it notes in the standard 'notification'-type way (where students stick a red post-it on their laptop when they have problems, and a green when they have done the exercise), but we also got students to write on the post-it notes before each break in a session, listing a good thing that they really understood on the green post-it, and something they were struggling with on the red post-it note. This was really useful for the instructors, and we were able to tailor the subsequent part of these sessions to answer the specific questions that were raised.
In terms of specific things that might help future bootcamp organisers and instructors:
There were significant problems with the setup and installation
procedures. Many people didn't do this before-hand, or tried to do it,
found it difficult and then gave up. This caused significant problems
in the first session, with some people managing to get going with the
shell session, and others still struggling with the setup. There are
various things that can be done about this:
- Ensure there is double the amount of time you think you'll need available at the start of the first day for setup issues.
- Email people the day before asking them to come early if they have had setup problems.
- Make sure you have a VM image on a pen-drive for students who have issues (I forgot to do this...).
- More generally: I think we need to significantly re-write the installation instructions on the Software Carpentry webpages. A number of students said that they tried to follow them but that they were very confusing and made very little sense. One student commented that we really need to do a 'Step by Step Installation for Dummies' guide which goes from nothing to everything, and shows how to check if things are installed. I agree, although this will be difficult to make applicable for every system.
- I felt a bit embarassed that we dropped James (who was instructing for the first time) into these setup problems on the first day, I think the first session should ideally be run by an experienced instructor who will be more familiar with dealing with these problems.
- Students were asked to clone the git branch for the bootcamp at the beginning of the first session - before they had been taught git! They found this very difficult, and many people didn't get it properly downloaded for a while. The other problem is that doing a standard 'git clone URL' will download all of the data for that repository (including all branches, all of the history etc) - which took a LONG time when 50 people were doing it at the same time. One student very reasonably asked why we don't provide the bootcamp material as a simple zip file.
- The red/green post-it system for feedback at the breaks in each session was wonderful, and should be used more widely.
- It is amazing how much a good food plus coffee and cakes can help...although it is very important to make sure dietary requirements are taken care of (even if the catering organisation said they would provide it ok, they didn't).
- We tried to make a more flexible final session by pointing students to the Software Carpentry resources, and the resources from the boot camp, and asking them to work on whatever they wanted and have lots of discussions about issues and general questions with the instructors. However, many students took this as a cue to leave (which I hadn't expected!) and so I had to hurridly give my final presentation.
- I think a number of students found the final presentation which brought it all together quite useful - but I altered the 'standard' Software Carpentry one quite a bit, to add in ways to combine all of what we'd learnt (eg. shell scripts as git hooks to run automated tests). This new presentation is in the 2013-06-southampton branch of the bootcamp's repository.
- Nelle's reproducible research session was very much appreciated by people, particularly the use of makefiles for reproducible research.
- A number of students found the testing session rather frustrating for a number of reasons including: too much Python coding, more time spent on it than they thought it needed, not understanding the point for people who don't write libraries etc.
- One major suggestion from a number of people was to make all of the examples inter-linked, and to present the bootcamp as one big story, showing how you'd use these various tools and techniques to do 'good reproducible computational science'. This is a lovely idea, but I can imagine it would be very difficult - however, I may blog about it in future.
I think the structure of the bootcamp worked very well, particularly as we had a lot of time allocated for each session, so we could go into more depth but also not worry too much about time. However, the real stars of the show were the instructors - and they deserve huge thanks. I think it is appropriate to finish with a comment from one of the students on one of their green post-it notes:
Thank you for selecting such knowledgable people to instruct this course!