software carpentry

Women in Computer Science Day

Last week I ran a small stall at the annual Women in Computer Science day run by the Department of Computer Science at the University of Oxford. Fortunately being neither a woman nor a computer scientist proved to be a problem. The event was aimed at female Year 10 students (and therefore would be choosing their A-levels next academic year). The UK over-hauled its computer science curriculum a few years ago, and it was great to see that more than half of the students had done some Python which is awesome. (I am teaching my eight year old Python). I was demonstrating the image processing software I’ve written (in Python) that detects growth of M. tuberculosis on a 96 well plate (see the photo above) and can also automatically cut up the photos into strips of single drugs that are then uploaded to BashTheBug, a Zooniverse citizen science project. An important, and really easy message, was therefore it is amazing what you can do with Python! No need to learn some esoteric programming language, like Ook!. And yes, there are often times when you do need the performance of a lower-level language, but often, you don’t. As my own career path shows, nor do you have to study Computer Science to do science with computers.

As a Software Carpentry instructor, the thought that first-year undergraduates (or at least UK ones) might be turning up at registration happy using Python is great – in a way Software Carpentry is one of those organisations whose ultimate goal should be to bring about its own irrelevance – and makes me think of how much more imaginatively we could teach. It could bring experimentation into theory; if you don’t believe that the Binomial distribution can be approximated by a Gaussian for big enough numbers, try it! Or, if you don’t believe that integrating under a simple quadratic is a cubic, try it using many, many small trapeziums (my maths class was set this and a group of us wrote BASIC programs that hummed overnight on our Ataris and Commodores as we tried to outdo each other on the number of trapeziums the interval was divided up into. Geeky, I know.).

If then couple that with a computing cloud, you can start to say things like: “Ok, let’s all now try assembling a human genome”. How much more inspiring is that?

Software Carpentry Workshop, Oxford, 9-10 January 2017

Earlier this week I instructed the first Software Carpentry workshop run by the Reproducible Research Oxford project. This is a one-year project supported by the IT Innovation Challenges Fund and the Social Sciences Division. It is led by Laura Fortunato and I’m a member of the project team. One of the main aims of the project is to embed Software and Data Carpentry within the University of Oxford. The workshop was held at The Oxford Research Centre for Humanities and we had around 25 learners from a wide range of backgrounds, ranging from clinical medicine to the Bodlean library.

There are only a handful of qualified instructors within the University – my co-instructor was Iain Emsley who you can see at the right in the photo above – and so one of the main objectives of the project is to train additional Software and Data Carpentry instructors to allow workshops like these to become self-sustaining. For me, one of the key defining characteristics of Software Carpentry is that “everyone was a learner once”, in other words, yesterday’s learner is today’s helper who is tomorrow’s instructor. So creating a core of instructors, along with running a series of workshops will, we hope, bootstrap the process within the University.

If you read the About page on the Software Carpentry website it says

Since 1998, Software Carpentry has been teaching researchers in science, engineering, medicine, and related disciplines the computing skills they need to get more done in less time and with less pain

I don’t agree with this; I think researchers in the Humanities and Social Sciences have just as much, if not more, to gain from learning some of the skills we teach. Reaching academics from these disciplines will give this project a unique “Oxford flavour” and I anticipate may move us to develop bespoke material, much as has been done by Data Carpentry.

Software Carpentry Workshop, Jülich, 12-13 October 2015

IMG_0944 (1)Last week, myself and David Dotson from
ASU, ran a 2 day Software Carpentry workshop to kick off the CECAM Macromolecular Simulation Software Workshop at the Forschnungzentrum, Jülich. The idea was to give participants who were less well versed in python and working collaboratively with e.g. git a crash course to bring them up to speed for the following five mini-workshops. As you can imagine, coffee and tea are essential for running an intensive bootcamp and we owe thanks to The Software Sustainability Institute for sponsoring our coffee breaks.

As we were a self-organised workshop, there was no centrally coordinated surveying of the participants to gauge their level of experience. So instead I sent out a questionnaire very similar to one I’d previously sent before the first workshop I organised back in 2012. As is often the case, the learners were more comfortable with bash and simple python, but hadn’t heard or used testing or version control. Interestingly, compared to this previous workshop a higher proportion of learners were experienced in bash and python. Both groups were drawn from the bimolecular simulation community so this may reflect an increasing level of expertise.

fig-pre-expertiseThe workshop itself was the smoothest I’ve been involved in; I think it helped that both myself and David have taught several now. Also, devoting three hours for each of bash and version control and then six hours for python (including coffee breaks) meant it wasn’t quite as rushed. The last workshop I taught was in January 2015 and the course materials have been overhauled and updated and separated from the workshop GitHub repository. The latest version of the materials seemed to work well.
It also meant I was unfamiliar with the evolution of ipython notebooks into jupyter notebooks which David used to teach. Interestingly, although there was only one helper, Charlie Laughton, we were never overwhelmed. At each workshop I have taught or organised the ratio of helpers to learners decreased, which may reflect improvements in installation and the course materials.
Finally, I was live coding on my Mac laptop and using the new Split View in Mac OS 10.11 worked really well.

That is what I thought: what about the learners? I had fifteen
responfig-post-understand-enoughses to the questionnaire which was about a two-thirds response rate. All of them agreed with the statements “I enjoyed the Software Carpentry workshop” and “I feel I learnt something useful that will help my research”, but as we know, enjoyment does not necessarily translate into learning! As before I asked two key questions. First “I now understand enough to try using the following tools/approaches.”. As you can see there is a big shift in attitude compared to before the workshop with the majority of people feeling that they understood the tools covered during the workshop.

fig-post-intend-usingBut will this translate into a change in behaviour? To try and test this I also asked
“I intend using the tools listed below to help my research”. The results are pretty similar but interestingly peoples intentions were stronger than their understanding, i.e. there was a slightly stronger response to the intention question than the understanding question. Compared to the workshop I ran in Oxford in January 2015, the shift in behaviour was more dramatic, although the two groups were drawn from different research areas so can’t be directly compared.

CECAM Macromolecular simulation software workshop

I’m co-organiser of this slightly-different CECAM workshop in October 2015 at the Forschungszentrum Jülich, Germany. Rather than following the traditional format of 3-4 day populated by talks with the odd poster session, this is an extended workshop made up of six mini-workshops. Since it is focussed on python-based tools for biomolecular simulations, of which there are an increasing number, the first mini-workshop will be a Software Carpentry bootcamp that I will be lead instructor on (helped by David Dotson from ASU). I’m also leading the next mini-workshop on analysing biomolecular simulation data.

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

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

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 Kwasi Kwakwa 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: Michael Morgan and Thomas Smith from CGAT and Jane Charlesworth from the MMM. Finally thanks to the SSI who not only helped with the admin, but also have supported myself and Jane through their fellowship programme this past year.







Software Carpentry Workshop in Oxford, Day 1

Today I’ve been instructing on a Software Carpentry workshop at the Wellcome Trust Centre for Human Genetics in Oxford; it’s the first time I’ve been lead instructor on a bootcamp. Today Kwasi Kwakwa 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 standard installation instructions 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 Software Carpentry Boot Camp at the University of Oxford. I’ve previously posted the feedback 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 MDAnalysis, 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).


fig-post-understand-2So, 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.

fig-post-intend-2To 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.”