Lighting beacons: research software engineers event and related topics

I've realised that it could be useful to share my reading at the intersection of research software engineers/cultural heritage technologist/digital humanities, so at the end I've posted some links to current discussions or useful reference points and work to provide pointers to interesting work.

But first;  notes from last week's workshop for research software engineers, an event for people who 'not only develop the software, they also understand the research that it makes possible'. The organisers did a great job with the structure (and provided clear instructions on running a breakout session) - each unconference-style session had to appoint a scribe and report back to a plenary session as well as posting their notes to the group's discussion list so there's an instant archive of the event.

Discussions included:

• How do you manage quality and standards in training - how do you make sure people are doing their work properly, and what are the core competencies and practices of an RSE?
• How should the research community recognise the work of RSEs?
• Sharing Research Software
• Routes into research software development - why did you choose to be an RSE?
• Do we need a RSE community?
• and the closing report from the Steering Committee and group discussion on what an RSE community might be or do.

I ended up in the 'How should the research community recognise the work of RSES?' session. I like the definition we came up with: 'research software engineers span the role of researchers and software engineers. They have the domain knowledge of researchers and the development skills to be able to represent this knowledge in code'. On the other hand, if you only work as directed, you're not an RSE. This isn't about whether you make stuff, it's about how much you're shaping what you're making. The discussion also teased out different definitions of 'recognition' and how they related to people's goals and personal interests; the impact of 'short-termism' and project funding on stable careers, software quality, training and knowledge sharing. Should people cite the software they use in their research in the methods section of any publications? How do you work out and acknowledge someone's contribution to on-going or collaborative projects - and how do you account for double-domain expertise when recognising contributions made in code?

I'd written about the event before I went (in Beyond code monkeys: recognising technologists' intellectual contributions, which relates it to digital humanities and cultural heritage work) but until I was there I hadn't realised the extra challenges RSEs in science face - unlike museum technologists, science RSEs are deeply embedded in a huge variety of disciplines and can't easily swap between them.

The event was a great chance to meet people facing similar issues in their work and careers, and showed how incredibly useful the right label can be for building a community. If you work with science+software in the UK and want to help work out what a research software engineer community might be, join in the RSE discussion.

If you're reading this post, you might also be interested in:

• Paul Walk's 2011 posts on The Strategic Developer: How Local Developers Can Make A Difference and The Value of Local Developers raised many of the issues discussed at the RSE event and the DevCSI ('Developer Community Supporting Innovation') initiative. There's also a Developer Contact Google Group.
• On Ant-Lions and Scholar-Programmers by Doug Reside - the emphasis is on scholars rather than programmers and it's also interesting for the differences between academia in the US and UK (though it doesn't directly address them)
• Alan Liu's "Why I'm In It" x 2 – Antiphonal Response to Stephan Ramsay on Digital Humanities and Cultural Criticism and Stephen Ramsey's 'Why I'm In It' - if you haven't been keeping up with the digital humanities, dive into the deep end here.
• Michael Widner's Towards a Front Page for the Digital Humanities #dhthis, because it's one of many posts discussing DHThis and because I forget that not everyone lives and breaths this: 'software is a form of writing/making with its own assumptions and affordances, we have a responsibility to critique the software'

In ye olden days, beacon fires were lit on hills to send signals between distant locations. These days we have blogs.