By Amy Beeston, University of Sheffield.

I attended the instructor training course in Manchester last week. During one of the coffee breaks, we were sharing stories of how we first met these teachings, and how as new learners we first tried to put our freshly-acquired Software Carpentry skills to use. Following that conversation, our instructor Aleksandra Nenadic invited me to write this blogpost to share my experiences.

I was introduced to the concept of Software Carpentry by Greg Wilson during the week-long Sound Software Autumn School in late 2010. Heavily pregnant, I sat on the back row during most of Greg’s classes — the row with the extra leg/body room — and listened to the very best of my ability to every single word he said.

As a group of learners, we came from varied disciplines but all shared the need to focus our programming skills on developing tools that accessed data in the audio domain. Many of us were self-taught programmers, and some of us had relatively little text-based coding experience as we were used to thinking and working in real-time signal processing environments such as Max and Pure Data.

The course had been advertised with the aim “to train PhD students and researchers in the software development skills required to build reliable research software quickly and with a minimum of effort, and so maximise the impact of their research.” I could definitely see the benefit of producing reliable software quickly and easily, but I must admit that I was completely unconcerned at that time about the impact of my research. I was growing enormously and looking forward to my maternity leave!

On the other hand, it was clear to me from the outset that I would learn another crucial skill during these sessions: how to collaborate successfully. There was a great deal of discussion about working openly and effectively with others, and about using code repositories and version control software to navigate the geographical terrains separating far-flung team members.

As the week went on, it dawned on me that these same techniques could traverse time as well as space: they would let me return to work and immediately pick up right from where I left off. So I, pregnancy-brained-Amy, started to think about the best way to collaborate with my future self, baby-brained-Amy.

While a thick blanket of snow settled all across Sheffield, I set to work. Concentrating first on version control, I created a repository and began checking-in my auditory modelling work. Rather wonderfully, this meant I could work from home on occasion (when the trip to the lab was too icy for my raised centre of gravity), while still being confident I had the latest version of any particular file. Next, I set about splitting some huge scripts from my collaborators into handy bite-sized chunks, tracking their provenance and scattering assertion statements liberally to make sure everything was working as expected.

Finally, to be sure, I re-submitted my work to the grid to make sure that my reconfigured code was able to reproduce all the experimental results I had so-far reported. And inspired by a lesson on test-driven development, I set about documenting my current self’s intentions for my future self’s return to the lab.

Fast-forward one all-too-short maternity leave… and that’s exactly where I picked up!