Introduction

Researchers sometimes hesitate to share their code and may be embarrassed to show imperfect code, even though it is generally agreed (and sometimes mandated) that we should openly share the code we use to arrive at research conclusions. This may not be surprising given that many researchers are not trained beyond a beginner level in software engineering. Most research software is written by research domain experts not trained to produce quality code. How can we help beginner to intermediate research software engineers gain confidence and improve research and code quality in doing so?

Improving research software is not only beneficial to others who may want to inspect it, but also helps the author (“future you”) understand what they have done when they come back to a piece of code months or years later. While a wealth of resources is available to start writing research software, moving on to an intermediate level may seem a daunting prospect. This blog post aims to identify intermediate research software skills and discusses some experiences in acquiring them based on the discussions of a group of researchers and research software engineers (RSEs) that took place at the Collaborations Workshop 2023 in Manchester.

What are intermediate skills?

One way of thinking about intermediate software skills is to consider each of the different aspects of software development and the non-technical skills acquired as part of working with research software, then compare the abilities between groups who are beginning this kind of work and groups who have a few years of experience. We attempted to map out some of these beginner / intermediate differences in the table below, focussing on more general skills rather than domain-specific technical needs. 

We feel that there are several attributes of intermediate development that cut across these individual skills. Examples include: the ability to know where to look for help and information (e.g. understanding documentation, knowing how to filter relevant ideas, and not being overwhelmed by new material); the ability to break a problem down into subproblems (which may be familiar); and the ability to work on a range of different projects.

Bringing these ideas together is the concept of “conscious incompetence”. A novice, almost by definition, does not know that there are tools and ideas that they do not understand. On the other hand, on achieving mastery, the expert may not be aware of what they now know. Between these two end states is the intermediate developer, who has an idea of what they should learn and what tools they should be using, but who has not yet mastered the ideas or tools.

On reflection, many of us in this blog team identified the process of moving into this intermediate state with a time when we worked on a project with practical application and with somebody who was much better at software development. This was a key phase of our growth as developers. We expand on this idea below.

How did we reach intermediate?

So how did we develop these intermediate skills? In our group there are a number of developmental stories with some common themes. The need to work on some project with a practical application provides a key motivation to develop. But beyond this, we often found that it was important to work with others, either as part of a formal development plan, with a formally designated mentor, or by working informally with somebody. This process often led to the ability to break problems down, to identify gaps in our own skill set, and gave us the ability and confidence to develop further on our own. Some of us got to this point without the aid of a mentor but it is this ability that is key. Three ‘stories’ of our experience are outlined below.

One of us got started in industry and moved into an RSE role: “I learned much of my software development skills on the job, as a web designer turned developer in a small company. The environment was supportive and fairly fast-paced, so asking questions of more experienced developers was expected, and there was a common setup for tools, testing, QA and version control. Over time and with more confidence, I was coached to implement (later also specify) more complex features and to design elements for reuse across projects. I think that gradually building up context and knowledge was key - I can remember the first time I stared at a multi-level directory structure of code without a clue which file to open or edit, being guided to the right place to start, gaining familiarity with a way of structuring code, and developing opinions about how to do it differently. Changing contexts has continued to be a useful prompt to pick up skills, both reading around and seeing or hearing how people do things differently.”

Another benefited from a formal training scheme: “I was lucky to have a pretty formal transition from beginner software developer to an (arguably) intermediate level. My initial software development skills were completely self-taught, and when I reached the end of my self-teaching tether I applied to some software development apprenticeships. I was lucky enough to be accepted by Imperial College London into their apprenticeship scheme, along with 9 other eager coders. We underwent a 4-month long boot camp of full-time learning where we developed our skills from the ground up, taking care to learn the habits required for software development in a professional environment. Being able to work with a group of like-minded apprentices to learn collaboratively was an incredibly invaluable experience as we were able to help each other fill the gaps in our skill portfolios. Having a structured course and a mentoring coach also helped make sure we were getting all the development skills needed to reach that intermediate level that our departments would require.” 

And one of us got lucky in an academic environment: “I developed my intermediate skills as part of a research project funded via the eScience scheme in the mid-2000s. Working ‘between’ a group of research scientists and a group of software engineers I had a postdoctoral role to enable developments on both sides and do ‘something’ better than we were doing before. I ended up working closely with two members of the team, one with a formal background in software engineering and another who had returned to academia as a research scientist after a sojourn to the Met Office. I was introduced to a range of (then) advanced tools (e.g. git in the very early days, decorators in python, testing, writing scripts to deploy software) but more importantly, my research software was subjected to code review. Now, years later, I recognise that this process was mentorship in all but name and the two years I spent on that project changed the way I developed research software forever.”

Conclusion

There are many possible paths from beginner to intermediate, varying across domains. One common theme in research software is collaboration: making the step from being an individual coder who writes software that works for them, to an intermediate software engineer who works in a collaborative way on code that will be ready to be published, shared, or put into production. Another common theme is developing an awareness of gaps or room for improvement, as we gain familiarity with ways of writing software and a set of technical concepts, developing a map of relevant skills and knowledge along with the capability to fill in those gaps and keep learning. Being intermediate means having both the skills themselves, and the confidence to use and develop them further. Time and practice are essential, along with feedback and support along the way.

For further reading: a previous blog post by Aleksandra Nenadic has signposts to training resources; the Turing Way guide to reproducible research covers relevant topics; and at the SSI Collaborations Workshop 2023, one of the hack day projects started developing an RSE Competencies toolkit aiming to help RSEs to identify competencies (measure), find pathways to acquire skills or competencies (plan), and find training resources (learn) - to find out more, please take a look at the GitHub repository and the prototype webpage, or join the mailing list.

[1] As an aside, some of us would recommend Diátaxis, which is a pragmatic approach to designing technical documentation around the needs of the people who read it.

Authors

• Tom Russell, School of Geography, University of Oxford

• Andrew Walker, Department of Earth Sciences, University of Oxford

• Lieke de Boer, Netherlands eScience Center

• Callum West, Imperial College London

• Tony Greenberg, Bayesic Research

• Finn Bacall, University of Manchester

• Pamela Wochner, The Alan Turing Institute 

• Philippa Broadbent, University of Southampton

• Sean Marshallsay, Queen’s University Belfast

• Hannah Williams, UK Health Security Agency