By Simon Hettrick, Deputy Director.

The first workshop for Research Software Engineers took place on 11 September 2013 and is described below. A second workshop will take place in mid-2014 and will be announced on this website.

Research software engineers are the people behind research software. They not only develop the software, they also understand the research that it makes possible. Software is a fundamental part of research, and research software engineers are fundamental to good software. Despite this, the role is not well understood in the research community, and this is something the Software Sustainability Institute is campaigning to change - starting with a workshop for research software engineers.

The first workshop for Research Software Engineers

The free workshop will bring research software engineers together to discuss their work, to network, and to work on ideas that will bring recognition and reward to their role. It will be held on 11 September 2013 directly after the Digital Research conference. It will be held at the Oxford eResearch Centre. You can register now on our Eventbrite site.

Feedback

After the workshop, please complete our very short survey.

Hashtag

If you want to tweet about the workshop, please use the hashtag #rse2013 (and follow us). 

More information

For more information, or if you have any questions, please contact us.

Information about what topic is taking place in which room can be found in the workshop's Google doc.

Agenda

• 09.00 - 09.30: Arrive and coffee
• 09.30 - 09.40: Introduction by Simon Hettrick
• 09.40 - 10.05: Keynote by Mark Hahnel, founder of Figshare
• 10.05 - 10.30: Keynote by Ian Gent The recomputation manifesto
• 10.30 - 11.00: Introduction to What's New? session
• 11.00 - 11.30: Coffee break
• 11.30 - 12.30: What's New? break outs
• 12.30 - 13.30: Lunch
• 13.30 - 13.45: Introduction to discussion groups
• 13.45 - 14.45: Discussion breakouts
• 14.45 - 15.00: Coffee
• 15.00 - 16.00: Reporting back session
• 16.00 - 16.30: Group discussion: Do we want a research software engineer community?
• 16.30: End

Topics for What's New? session

The What's New? session gives you the chance to talk to people about something that interests you. It could be a technology, an idea, a project or anything else that's interesting. It's your chance to interest people in your work, talk about new technology or get a problem solved.

The session starts in the lecture theatre. Anyone can propose something to discuss and provide a short introduction to it. The idea will be added to a list and, once everyone's had a chance to contribute something, we vote on the most popular topics. The six-to-eight most popular are assigned rooms, we break up and the people who voted for each topic get an hour to meet and discuss it.

What you do in the hour is up to you: evangelise, discuss, form new collaborations or argue. Before you start, make sure that someone is taking notes, so that they can send a summary to the Google Group.

The kind of topics we will be discussing are listed in the workshop's Google doc:

• Clusters, clouds or your laptop: How can you make effective use of heterogeneous computing resources to run scientific HPC codes?
• How do you share code (best practice, managing code, licensing, open source at university) and promote it?
• Using virtualisation and the cloud for reproducible research
• The GATE tool for text mining
• Legacy code: how do you transform 20 year old Fortran code into something useful?
• Tools such as Dryad and Figshare help make code available. Who uses them and how successful are they?
• Who’s using IRODS… and how are they finding it?
• Using Jenkins in research
• The UCL Research Software Development group: how we deal with project selection and organising collaborations
• Ways of keeping up to date with the science as well as the relevant technology - good conferences, blogs, Meetups, journals...

Topics for discussion groups

Unlike the What's New? session, discussion groups focus on issues rather than technology. The idea here is to get a better understanding of the research software engineer: careers, recognition, working in research, reward and other issues. The topics we will discuss listed in a Google spreadsheet and below.

We will vote for the most important topics to discuss at the workshop and break into groups to discuss them. Each group must assign a chair and a scribe, as described in the how to run a break out session page. Following the discussion group will be a reporting back session, where someone from each group (generally, the Chair or the Scribe) describes the groups findings.

You can suggest topics to discuss before, or at, the workshop. The current ideas are listed in the Google doc and below:

• How should the research community recognise the work of RSEs?
• Reasons to be dissatisfied: what's wrong with the RSE role and why do people leave for industry?
• Organised or completely random... does your institution have a centralised RSE group, or is it more chaotic?
• Routes into research software development - why did you choose to be an RSE?
• What's the best way to funding RSEs? What should we be telling the funding agencies?
• Do we need an RSE community and, if so, how should it work?
• 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?
• What should we be telling PIs, and the research community in general, about the benefits of working with an RSE? How do we promote the role?

Are you a research software engineer?

The research software engineer is a name for a role that currently lacks one. Many of the people who fulfil the role will not currently describe themselves as a research software engineer. You should attend the workshop if any of the following questions apply:

1. Are you employed to develop software for researchers?
2. Are you a researcher who now spends more time developing software than conducting research?
3. Are you employed as a postdoctoral researcher, even though you predominantly work on software development?
4. Are you the "person who does computers" in your research group?
5. Are you not named on research papers despite playing a fundamental part in developing the software used to create that research?
6. Do you lack the metrics needed to progress your career in research - like papers and conference presentations - despite having made a significant contribution with software?

For more information about the research software engineer, see these posts: If we value software, we need "a fundamental sea-change" in academia, the Craftsperson and the Scholar, and What is the Research Software Community and should you care?.

Digital Research

The workshop will take place directly after Digital Resarch 2013. We decided to co-locate with Digital Research because it is focussing on subjects that are of interest to research software engineers. This year the conference has two major themes: the Data Scientist Symposium, which will consider the role, training and career of Data Scientists, and the Digital Research Showcase which is an opportunity for researchers and research technologists to present their latest work. 

Why attend?

The workshop will be an excellent networking opportunity for a group that does not currently have a community.

By attending the workshop, you will also be helping to create a community of research software engineers. This will be a good opportunity to network and to share experiences with people who fulfil the same role as you in the research community. It is also the first step towards campaigning for recognition, because we need to understand the size of the community so that we help to represent it.

We need to hear about your experiences in research and your ideas on how things could be improved. By attending the workshop, you will directly contribute to a campaign that will help gain recognition and reward for your career.

Who's behind the workshop?

The workshop is being run by the Software Sustainability Institute with the valuable help of a group of research software engineers:

Chris Cannam is a software developer with 15 years commercial and extensive open-source development experience. He works for SoundSoftware and as a software consultant.

Dirk Gorissen is a computer scientist fascinated by engineering and interested in international development and education. After eight years in academia he recently made the switch to BAE Systems Research and works on topics related to (big) data analysis, autonomy, and computational engineering.

James Hetherington is leader of UCL’s new Research Software Development team. He works with researchers to produce maintainable, usable, well-tested scientific software that will have a lasting impact.

Cass Johnston is a bioinformatician and System Administrator NIHR BRC-MH Bioinformatics Core at King's College London.

Mark Woodbridge develops data management tools for systems biology and bioinformatics. He came to Imperial College in 2008 to build software for the management and integration of the data generated by the experimental biologists and computational modellers of CISBIC.

Recognition and reward

A rare blend of expertise in software development and research makes the research software engineer difficult to categorise, and this causes issues with recognition and reward in academia. This leads many research software engineers to take their valuable experience to industry. One of the workshop's themes will focus on how research software engineers should be recognised.

The reward system in research is out of date. The work of the research software engineer does not fit into any of the current job descriptions, so it is difficult for a research software engineer to progress their career. One we have a system for recognising the work of the research software engineer, we will have a metric against which career progression can be measured and rewarded.