MAT DTC Software Carpentry workshop at QMUL

The final project workshop was embedded in a Software Carpentry course given by Sound Software to students in the Media and Arts Technology (MAT) Doctoral Training Centre (DTC) at QMUL. The students consisted of new postgraduate Masters students and MAT DTC students in the first year of their PhD studies. The course aimed to give the students a toolbox of useful skills to allow them to perform their research effectively. The format and content was largely similar to the pre-DAFx Software Carpentry Bootcamp but with less of an audio focus (as not all MAT students are involved in audio research). The bootcamp was compressed into two days and had an additional section on research data management.

Our initial hope was to have a more hands-on session on data management than previously, covering relevant Unix tools and use of the data repository. However, the MAT DTC is not based solely in the C4DM but includes students from a wider range of research groups within QMUL – e.g. Multimedia and Vision and Human Computer Interaction. These groups do not necessarily have access to facilities available to researchers within C4DM (e.g. Sound Software is intended for audio researchers and the C4DM research data repository is solely intended to publish research data from C4DM). Although the main Software Carpentry sessions took place in a computer lab, it was necessary to provide some of the training in a different area without computers. Of the topics taught, RDM was most suited to this. As such, the training again focussed on presenting general skills, possible problems and ways for people to improve their RDM.

The RDM content was an extended version of the previous courses for researchers and should be useful to all attendees in the medium-term (i.e. during their PhDs) – if suitable facilities are available for them to make use of the lessons. As the workshop was aimed at people who currently might not have infrastructure available to support RDM, the focus was more on practical solutions. Removable media and cloud storage were discussed as possible backup solutions – with appropriate caveats regarding the issues – and publication options beyond an institutional/subject repository were discussed (e.g. supplementary materials with papers, figshare.com).

The standard evaluation method for Software Carpentry sessions is an immediate set of responses from the attendees. Each person in the room is asked to provide a response, alternate people returning one good or one bad thing about the course.

The curriculum came up in several responses, both positive and negative, with some attendees agreeing with the choice of tools and some preferring other options. One of the aims of Software Carpentry is to teach examples of how tools work rather than to advocate specific tools, so discussions of the most appropriate tools are, to some extent, expected. The content of the training on version control and the Unix shell was appreciated by participants as being “quite clear”, “helpful” and a “smooth start”. This training was intentionally basic, as it is targeted at people with little, or no, prior exposure to these tools e.g. the Unix shell session intentionally started with an assumption of no prior knowledge and rapidly progressed through all the basic knowledge to demystify online help which suggests that people should “go to the command-line and ...”. Given more time, a discussion of why the tools used were chosen, and other options which people may use would have been a good addition. In general, the exercises during the sessions were regarded as “good” - coding exercises during the training allowed people to think more on the concepts introduced and to try them for themselves. Without appropriate tools / facilities it was not possible to provide such sessions on RDM.

The use of three presenters during the session provided some variation in style and, hopefully, also provided a hook to help people remember the different areas covered – rather than having diverse topics covered in a single presentation style. In addition, the workshop is intended to be a cooperative exercise with the presenters, helpers and attendees working together to improve people's skills – to this end it was good that participants noted that answers to questions were explained clearly and patiently, that they felt they were comfortable asking “stupid” questions and that the course had a nice atmosphere.

During the workshop, red and yellow sticky notes were used to signal how people were doing – red stickies indicating that people needed the attention of a helper, yellow stickies being used to indicate when people had completed exercises. This meant that helpers could intervene as appropriate and the tutor could pace the session with a minimum amount of singling out participants as requiring assistance.

The course was held in a computer-lab at QMUL in which all attendees had a pre-configured iMac available for the course which meant that commands “just worked” for them rather than requiring the installation of software and libraries (attendees that used their own laptops required additional attention from helpers to get them started). This reduced the amount of time required at the start of the workshop before attendees could get started. The only criticism of the facilities was that the projector screen was difficult to see from the front of the room – however, as the room was full with ca. 20 students, this was, to some extent, outside our control. From a presenter's perspective, It was difficult to judge engagement of audience with the material during the Unix shell course as the computers were large-screen iMacs with attendees barely visible over their screens – however, the RDM training was a presentation in an informal open-plan area and people seemed comfortable with the approach. Questions were accepted during the talk and the usual mixed level of engagement was observed (some people showing obvious interest, some more interested in their laptops).

The main criticisms regarded pacing. Days were seen as involving too much teaching time, teaching was sometimes too fast and there was a feeling that the course should have been longer. The presenters agreed that the course should probably have been longer, but the course had to fit in with other timetabling. However, as the main aim of the course is to introduce basic concepts rather than to provide a complete course in programming, or to advocate specific tools, the depth in which topics should be covered in such a wide-ranging course is limited. Hopefully, participants will have identified weaknesses in their skills and will be able to find appropriate training (online or face-to-face) to overcome them.

In addition to the immediate feedback, we sent out a survey to judge the usefulness of various aspects of the workshop. Of the four responses we received (from twenty attendees), two judged the Data Management content to be “Very Useful”, one “Moderately Useful” and one “Slightly Useless” (ca. two 6s, one 5 and one 3 on a scale of 1-6). In addition, asking what people got out of the workshop one person responded “A basic understanding of Python and tools and necessity for information/data management” and another “I learnt a few new bash commands I wasn't aware of, and a few data management tips that were helpful”. All respondents would recommend the workshop to their fellow researchers, but felt it was for “slightly inexperienced” programmers. Overall, respondents found the course easy, but considered it slightly to moderately important for their research. An email with links for further information, including the SoDaMaT online materials, was sent to the attendees afterwards, and one attendee contacted us to say:

Thanks for these lovely comprehensive notes. These will be really useful in the short and long term.

And of course thanks for the workshop, I really appreciated the warm positive atmosphere, I think this is your USP [usually workshops with coding, especially for non-CS people like me, are presented as taking medicine, not tasty but good for you]