Feedback from Edinburgh

This post originally appeared on the Software Carpentry website.

This week saw the first bootcamp to be held at The University of Edinburgh. The bootcamp was organised by the The Software Sustainability Institute and EPCC as part of the PRACE Advanced Training Centre. We had 36 researchers from geosciences, astronomy, biology, statistics, chemistry and mathematics and based at 8 institutions across the UK. Azalee and myself led the workshop and we had 7 helpers including Nancy Giang of the University of Dundee who we recruited after she attended the Newcastle bootcamp back in October, and David Jones of the Climate Code Foundation. We also had as helper/observers Mike Mineter of The University of Edinburgh and Norman Gray of The University of Glasgow also came along to help and to see what a bootcamp is like, with a view to running bootcamps for the physics and geosciences communities.

Feedback from the attendees was good though some felt we went too fast (on make, for example), or too slow (on bash). For once, it seemed like we weren't bogged down with installation woes. We'd e-mailed attendees many times to tell them to do it before they arrived (and that the weekend before is too late!) and provided a VMWare Ubuntu VM but it helped that a number of researchers came from the same department and their systems team had configured a VM for them to log into (a model to be promoted!).

From Azalee:

We had 6 helpers + 1 instructor free at all times on the first day to assist with installation (along with content) issues. At first I thought that this was way too many people, but it turned out to be the right number to address the issues of the class as they arose and give students the individual help they needed as they needed it rather than during the breaks. The diversity of experience and expertise of the helpers also contributed to the success of this workshop.

One deviation from previous workshops I've attended was a practical at the end. We asked students to write a script which read in a file of student names and grades and calculated the mean. They then wrote tests for the function, put it under version control, and created a make file for it. People worked in groups of 2-5 people from their table for about 1.5 hours. We asked students to get as far as they could in that time. The mean function had already been presented in an earlier exercise. A few groups completed the assignment while others only got as far as version control, but it was great to see the students working together, sorting through their misconceptions, creating working code, and asking questions in a very supportive environment. I think that this demonstrated the intended work flow as well as demonstrating how everything we taught them fit together. The down side of this was that it was that much less teaching time to cover new content.

We created a pre-workshop questionnaire asking students to rate their level as well as their interest in the planned curriculum. We also asked them which operating systems they would be using. This was very helpful in designing the material and supporting installations.

I'm still looking for the best way to get text files to students. We tried the download section of bit bucket (a great place for students to use wget and curl) but with long urls this was cumbersome. I'm leaning towards a pre-workshop repository with just the code you want students to start with and a post-workshop repository with all of the answers. I'd love to hear other people's suggestions/experiences.

I also struggled with balancing making the size of the text big enough to be read by the class with the commands scrolling off the screen before the slower students could type them. Again - suggestions welcome.

Here are the comments from the attendees, helpers and instructors, good and bad:

Other observations from Azalee and myself, and from our helpers (who were great at taking notes as to how things were going) included:

• For bash, the concept of a home directory should be introducted explicitly.
• "history | grep 'some command'" is a good example of a pipe in action and a very useful command!
• There should be an explicit introduction to an editor (open file, edit, save, exit) otherwise attendees may just copy the instructor which can cause problems when an instructor is zooming through his use of XEmacs (guilty!). This was especially and issue in the version control section when some people forgot to put a commit message in the command-line.
• Revision control commit messages should be provided via the editor and not at the command-line to reduce the risk of attendees reusing commit messages from previous commands in their shell history (or using messages like "Commit 1", "Commit 2" etc).
• .py files should be introduced as soon as there is a need to input code fragments that extend over 1 line e.g. conditional, loop or function. This is a place where the ipython notebook might be a happy medium although it is one more item to install.
• Any code fragments we present must be "exemplary" - fully commented and idiomatic - ie. exactly how we'd write it ourselves if doing it "for real" because, as has been commented, people learn by reading others' code!
• David Jones wrote a blog post on his experience with more useful information and suggestions.