software carpentry

Software Carpentry Workshop, Oxford, 13-14 January 2015

So how did the workshop go? I thought it went a bit better than the first day, but, hey, I’m a bit biased. To get a better idea I sent the participants a similar questionnaire to the one I sent to the Software Carpentry workshop I organised before. Nearly all the participants (95%) agreed with the statement “I enjoyed the Software Carpentry workshop” which is great, but I guess the aim is to help people change how they use computers to do research.

I now understand enough to try using the following tools/approaches

Asking “I now understand enough to try using the following tools/approaches” gives a more nuanced view (see the graph on the left). Everyone seemed to understand shell scripting, but we can’t take all the credit as quite a few people would have known bash before.  In fact, all the different elements of the syllabus were well understood, which shows the course and materials were going a good job.

I intend using the tools and methods listed below to help my research




How about: “I intend using the tools and methods listed below to help my research”. Now we start to see some differences. Most people intend using shell scripting and python, maybe fewer people will pick up testing and git with only about half the participants thinking they would use SQL. Still, a good result.

Back in October 2012 the first Software Carpentry workshop I organised here in Oxford was hugely popular. We had to turn people away. I wondered if the demand might have reduced in the intervening time as more and more workshops have been run. But 95% of people thought “more workshops like this should be run in Oxford”. So we are some way off saturated the demand.

From some of the comments at the end of day 1 I was a bit concerned about the speed at which we were moving through the material, so I asked whether “the instructors went too fast”? 24% agreed, 52% disagreed and the rest were indifferent. I read that as the speed was ok: any faster and we would have lost more people, any slower and it would have become too boring for the more advanced participants. It was pleasing to see that everyone agreed with the statement “I feel I learnt something useful from the workshop that will help my research.”!

Thanks to who volunteered to be the second instructor at short notice. A personal lesson for me is instructing is exhausting and it would be very difficult (and your teaching would suffer) to do one on your own. Also thanks to the helpers:  and from  and  from the . Finally thanks to the who not only helped with the admin, but also have supported myself and Jane through their  this past year.







Software Carpentry Workshop in Oxford, Day 1

Today I’ve been instructing on a workshop at the in Oxford; it’s the first time I’ve been lead instructor on a bootcamp. Today and myself covered the shell and basic python; more python, then git and SQL tomorrow. So what went well? I was very pleased to find we had no installation issues, even though everyone had brought their own laptop and so we had a mixture of Macs, Windows and the odd Linux machine! I had four USB sticks with the Anaconda etc installers and we didn’t use a single one so the must be working.

As is customary, just before they left we asked everyone to write on their post-it notes one good point and one thing that could be improved. Pleasing to see a good collection of positive comments:

Really enjoyed working through the ipython notebooks and being able to see and change the code and add notes in a visually pleasing way.

Well paced and explained from the bottom up, enjoyed it

But of course, it is the comments about things people didn’t like that are the key to making it better.

If I didn’t have some background in the subject I think it would have been too much for me

Can’t see the green brackets on the screen [in ipython]

I was completely lost in python. If you don’t have any previous background it is too much.

It will always be a challenge to cater for a wide range of backgrounds and experiences in these two day intensive courses. That is not to say that we should give up. I hope it will get better as the number of bootcamps increases. That way it will be easier to run bootcamps for the varying levels of experience.

Finally, don’t do what we did and use green and yellow post-it notes. I couldn’t tell them apart standing at the front. Still everyone drew a sad face or a cross on the yellow one which was fun. Also swap instructors more often than you might think: over an hour is too long. Oh, and bring a whiteboard pen!

The Oxford Software Carpentry Boot Camp … one year on.

In October 2012 I organised a at the University of Oxford. I’ve previously posted I gathered immediately before and after the boot camp, but thought it would be interesting to see if all that enthusiasm actually translated into deeds i.e. did the attendees actually change how they worked as result of the boot camp? So almost exactly a year after the boot camp I sent around a similar survey to the attendees. Inevitably some email addresses were now invalid so I only received responses from 13 of the attendees (as compared to 25 immediately after the workshop). To encourage responses, I only asked three questions and two of these followed on from questions I had previously asked. So what did I find out?

1. How would you describe your expertise in the following tools?


This was broadly encouraging: no tool was described as “never heard of it” and bash had a big shift compared to before the boot camp and now everyone either “used it regularly” or “used it but don’t understand it”. We had a big focus on python and the numpy and scipy modules, as well as , which is a python module specific to my field — people’s expertise in these does appear to have been improved by the workshop with some attendees “using [them] regularly” or now “expert”. Some tools, such as version control, make or unit testing only progressed from “never heard of it / used occasionally ” to “used occasionally / use it but don’t understand it”, illustrating how difficult it is to change behaviour.

2. I use the tools and methods listed below to help my research.


Immediately after the boot camp I asked “I intend using the tools to help my research” and most attendees appeared willing to give the tools a go. A year on a different picture emerges. People are using bash, python, num

py, scipy and MDAnalysis but are not making much use of version control, make or unit testing. This correlates with their perception, as tested by the first question, since after all if you don’t use something you won’t become proficient.


3. A year on, the workshop really encouraged me to change how I do my research.

Ten people agreed or strongly agreed whilst three people were indifferent. So, overall I think the boot camp was a success, but this feedback also illustrates the difficultly of changing behaviour, especially with short, intensive courses. One shot of Software Carpentry is not necessarily enough…

I’ll finish with the comments that three people were kind enough to leave.

“The workshop was really good but I think it covered only basic applications. Maybe in future workshops a part can cover more advanced applications for more advanced users.”

“Thanks for the really useful course! I have used the skills a lot in the past year, especially for small jobs, which helped me get things done quicker.”

“What about another Software Carpentry workshop? I’d be keen as long as we would expand on the material covered last year.”

Software Carpentry Feedback


As well as asking the attendees how they thought the workshop had gone, I sent them a questionnaire before the workshop. The idea was to see what their expectations were and if the workshop then met them. For example we asked “How would you describe your expertise in the following tools?” and the results are on the right. Overall most people didn’t feel they knew much about the tools we had identified as being potentially most useful. We also asked “What you would like the workshop to cover?” and the answers indicated these tools were relevant (results not shown).


So, how did the workshop do? Well, 92% of the attendees agreed or strongly agreed with the statement “I enjoyed the Software Carpentry Workshop” and 96% “[felt they] learnt something useful from the workshop that will help my research.”. Everyone who had come from an experimental lab thought that “other members of my lab would benefit from a workshop like this”. A good start, but did it improve their understanding? So we also asked “I understand enough to try using the the following tools” and most people agreed (see left)! Promising, but maybe it was the sugar from the donuts kicking in.

To try and resolve things we then asked “I intend using the tools to help my research” and lo, some of those agrees not unsurprisingly sneak to the left and join the disagrees (see the graph on the right). I’m happy and seeing as 92% agreed with “A workshop like this should be run annually in Biochemistry” maybe I’ll be running another one.

Few comments:

“The course was very informative and useful for my research! Thanks”

“I now see the value of a more ‘scientific’ approach to programming in science, in terms of version tracking, reproduciblity and validity. I try to be thorough in my approach to my research and that should extend to my programming. This workshop has been an excellent first step in that direction.”

“Excellent course, thanks for letting me take part.”

Running my first Software Carpentry workshop

“Can you email me that script you used to do your analysis?”

“Sure. It isn’t very well commented but you should be able to work out what it’s doing. I’ve tested it on a few things and it seems to work.”

Sound familiar? Of course, the story normally ends happily but….

Teaching some of the tools and methods of software engineering to scientists so that they write code that is easy to understand, tested and so can be shared more readily. This is the idea behind , a small but fast-growing movement.


I joined one of their online courses a few years ago and found it very useful, although inevitably I only managed to complete half the exercises before I had a bad week and fell off the back of the course.

So back in April 2012 when I was talking to Neil Chue-Hong at the in Oxford and he mentioned Software Carpentry my ears pricked up. Neil is the director of the who were running the workshop and he mentioned that they were helping Software Carpentry run two-day intensive courses in the UK. I thought it would be just the thing for our department and, well, we have just finished running the first ever two-day Software Carpentry workshop at the University of Oxford.

Interest in the workshop has been high; although the plan was to limit it to Biochemistry we ended up with helpers and observers from other university departments as well as one of companies on the science park and if we’d opened it up could have filled the room at least twice over. In the end we only had enough chairs and desks for the attendees and everyone else had to perch.

The first day covered shell scripting using bash and awk, version control, and automation courtesy of GNU make. I think most people had seen shell scripting but everyone sat up a bit straighter during version control… I always think a good course is like a good physics lecture; you sit there at the beginning nodding thinking “this is easy”, then the difficulty slowly ratchets up and at the end you realise you’ve learnt a lot. Yesterday it was the turn of python, including unit tests and some of the more relevant modules to us such as numpy, scipy and .

I’ll describe some of the feedback in a later post, but overall it appears to have been well-received. Just remains for me to say thank you to the instructors, all the helpers and, of course, the attendees.

Here’s to another one in 2013.