By Dr Eilis Hannon, University of Exeter, Software Sustainability Fellow.

On Friday 30th June, the first Coding Retreat was trialled at the University of Exeter.  The idea originated from a Writing Retreat I attended, where the focus was to clear all distractions and use the time not just to write but to produce high quality output. This parallels many of the challenges that researchers face when writing software and the idea that there is no time to consider making the code nice or think about how someone else would use it. So it struck me that a Coding Retreat could be a mechanism to provide the discipline to promote good practise. 

Based on the Writing Retreat I attended, the premise was to develop a similar event providing researchers with the time and space to focus and prioritise writing high quality, sustainable software. The workshop was designed to be inclusive; open to any programming language, any discipline and any project. The only requirement was that attendees had a project to work on, either improving or finishing ongoing work or starting something new.

The day started with refreshments and an overview of what the day would involve. The primary objective of the workshop is to use the time, cleared from the usual daily distractions, to produce high-quality code putting into practice all the principles acknowledged as gold standard but which often get omitted given time pressures and, in part, laziness. In order to get everyone in the right frame of mind, there was an initial discussion identifying some of the key concepts underlying programming. In particular, decomposition (breaking a more complex task done into more manageable components) and abstraction (removing the detail and focusing on the essential information) were highlighted as important processes required to write an efficient programme. These are processes that all programmers follow in order to produce a new piece of software, although these skills may be so natural that you don’t realise you do it. The key point was that programming is a two-step process: first, designing the algorithm and, second, implementing it in the programming language of choice. In general, as programming course often focus on teaching a particular language—rather than the underlying skills needed to write software, this is often underappreciated—with most of us doing both tasks simultaneous whilst sat in front of a computer.

Before the coding started, there was a warm-up activity designed to “loosen” everyone’s mind and fingers up. In an actual Writing Retreat, this would often involve free writing on a topic of your choice. Here, attendees were asked to spend 5 minutes either writing their README file to explain what the code they were going to write was going to do or to use comments to set up the structure of their programme. The idea is to start as you mean to go on and to give a bit of forethought to the code participants want to produce enacting the two-step process, rather than trying to design the programme as it is written. This approach should also give some structure and set up a framework to encourage continued good practice.

The rest of the day consisted of quiet coding sessions typically 50-90 minutes followed by an audit session (around 10 minutes). The audit sessions are designed as a chance to reflect on progress and plan ahead for the next coding session. In a coding retreat, this time can be used to review the code written so far and add comments that may be missing or think about what tests need to be added. Attendees were encouraged not to use their phones or check their e-mails during the coding sessions (although, I have to admit to feeling an urge to do so after 20 minutes) and resist all other distractions. The internet was not banned as it can be very useful to quickly check the name of a function or arguments, although reference books were available for those who fancied the old-fashioned way of looking something up. As most participants were producing R or Python scripts, there was the spontaneous opportunity to provide peer-to-peer support, and, in the future, I would try to introduce this more formally in the day’s itinerary.

Lunch was a great opportunity for people from different disciplines to interact away from their laptops and a number of conversations arose on related topics such as training courses, pair programming and opportunities to learn across university schools or departments. A by-product of the event was an opportunity to identify other researchers interested in engaging in a cross-university network of Research Software Engineers.

Despite being organised in less than a month, this was a very successful workshop with about 15 attendees. All participants said that they were more productive than a normal working day, and many expressed interest in attending another such workshop. There was also some good feedback re improvement particularly relating to facilities—although participants used their own laptop, there are some rooms with workstations to plug the laptop into a screen providing a more comfortable working position.

I am grateful to both Pam Lock and Rowena Murray, who provided materials from their Writing Retreats around which I planned the day. I would be delighted to share further thoughts with anyone interested in hosting a similar event at their own institutions.