By Eilis Hannon, University of Exeter.

On Tuesday, 26th September we held a two day Software Carpentry workshop at the University of Exeter. 37 staff and students attended including a number of PhD students in their first week. The course covered the Unix Shell, Python and Git, and gave Jeremy Metz and me the opportunity to teach our first Software Carpentry workshop, alongside Andrew Walker from University of Leeds who was there to steady the ship and provide experience. This was particularly helpful when it came to debugging and resolving common issues.

I was impressed by the sustained enthusiasm over the two days and how much of the content we got through. Many attendees commented that they appreciated the slightly shorter days (from 10am to 4pm) and regular breaks, as these enabled them to remain focused and digest the content delivered. They were also grateful for the additional support provided by the helpers David Richards, Paul O’Neill, Ben Evans and Jamie Harrison.

While the workshop was a huge success overall, with most attendees reporting that their skill level had improved and that they felt motivated to try to apply these skills to their area of work, I want to share some observations from the two days.

Over the course of the workshop I identified two barriers that were potentially holding some learners back from taking full advantage of the skills they were being taught.

Firstly, after being presented with a problem they found it difficult to break the task down in order to write code to complete it. They knew all the commands they needed, but hesitated when it came to knowing which order to put them in.

There is a big focus on computational thinking in the primary school computer science curriculum these days, to develop students’ ability to take a task and identify the relevant parts needed to complete it. I think this is missing from many graduate and postgraduate coding courses as it is assumed that attendees will already have these skills. For many of the exercises, in particular the coding of a for loop to evaluate a polynomial (in the Python Lesson Repeating Actions with Loops), I found myself explaining more often how we got to the solution than how we coded it. I have often thought that, for total novices, a session introducing why and how we programme before any functions or commands are taught may resolve some of the initial confusion.

The second barrier was that the initial content is so abstract (i.e. using Python as a calculator) that it is hard to see the benefits. To rectify this we rearranged the content on the second day to promote the lesson on Errors and Analysing Multiple Files. It is always a tricky balance, teaching enough basic commands so the students are self-sufficient versus teaching the more advanced yet useful programming structures.

This is not the first Software Carpentry workshop that the University of Exeter has held. In fact I attended the first when I started working here almost four years ago. That was the first time I encountered the organisation and I distinctly remember numerous lightbulb moments relating to the fundamentals of coding practice – although admittedly it took a few more years to convert me to Git! There has been much debate and discussion over the best way to introduce Git to beginners, who perhaps with little experience in programming, let alone in working on a collaborative project, struggle to recognise the benefits. However, many of the attendees had signed up to the workshop purely to learn Git and there was lots of enthusiasm as to how it could provide structure and feedback to existing working flows that are currently shared via email.

Although Exeter has an impressive range of programming workshops, facilitated by the Bioinformatics Hub, these are almost always oversubscribed. Moreover, these are annual events but the demand is continuous throughout the year. This workshop, which was also fully booked, demonstrates the interest in similar training events in the era of big data and reproducible science.

Currently these workshops rely on keen researchers giving their time, not only to lead the workshop but also to handle all of the organisational aspects. The positivity with which they are received, and the knowledge that teaching these skills well is an important contribution to research, often serves as the primary reward. However, part of the motivation for specifically holding a Software Carpentry workshop, as opposed to a generic Introduction to Programming, was to try to raise awareness of the organisation. In this way we have alerted some of the attendees to the contribution they too can make in passing on the skills they learned. Fingers crossed we should now have a cohort of inspired Software Carpentry graduates who will be well placed to help on the next workshop!