Software Carpentry: Feedback from Edinburgh

This week saw the first boot camp to be held at The University of Edinburgh. The boot camp 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 boot camp 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 boot camp is like, with a view to running boot camps 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:

Good

Good to see all the different techniques available even if they will not all be used
Learning more about Unix
Impressed by version control/Mercurial/BitBucket which will use more of (5)
Got to know about Mercurial before choosing SVN
Had some quite specific problems that people helped me with
Learning about makefiles (2)
Nice and experience helpers, relaxed atmosphere
Did not know a lot of the software, good to know more
Learnt a lot in two days
Problems with the computer, helpers helped out
Interaction with people on the course and helpers were useful
Fun
Good intro to Python for a complete beginner
Enjoyed being here and helping, and learning from helpers, also good to see how things work

Bad

Could not get the shared Mercurial to work
Learned a lot but not sure what I will use
Having to tell everyone a bad point
Queue for coffee (2)
Not enough on make, don't understand make
Some sections went a bit too quick because I was not so familiar with it (2)
Lot of things to learn
Some Python could give more context e.g. hypoteneuse which people may not be able to remember
Sometimes people fell behind and could not catch up (2)
Mixed dynamics, talk, helpers helping - cleaner structure between presentations and practical would be useful
Sometimes too easy, too difficult at other times
Went a bit slow for bash and zooming through other stuff later on
More on bash would have been good
Too much time on Python
Going a bit fast sometimes but there were enough helpers to help out

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.

Originally posted 2012-12-12 by Mike Jackson in University of Edinburgh.