Ten reasons to be a research software engineer

TenReasonsToBeAnRSE.jpgBy Chris Cannam, Dirk Gorissen, James Hetherington, Cass Johnston, Simon Hettrick and Mark Woodbridge.

Anthony Finkelstein wrote a great post about the benefits of being a software engineer: you can call yourself an engineer without getting your hands dirty, and you can wear jeans and a T-shirt to work (if you feel like being smart). All good points, but it got us thinking, whilst it may be good to be a software engineer, it's even better to be a research software engineer. And here's why.

(And if you're interested in this post, you should attend our workshop for research software engineers on 11 September in Oxford.)

1. Right at the cutting edge of science

You can read books and watch documentaries about research, but that's old news. If you really want to know what's going on, you have to work with the researchers themselves.

Research software engineers work right at the frontiers of science: they are the people who researchers work with in order to turn theories into results. And unlike researchers, Research Software Engineers don't have to pay for this privilege by writing papers.

2. Travel the world

Fancy a trip to Singapore, Rio, Hawaii, LA, Hong Kong, or Shanghai? Become a research software engineer.

We're not saying that you'll be jet setting every other day, but in how many jobs do you get to fly around the world to visit collaborating universities, or present work at international conferences? Not many! By sitting on the line between software development and research, research software engineers benefit from similar travel as their researcher colleagues.

3. Use the tools and languages that are best suited to the job

There's a lot of freedom in research software development. And rightfully so, because restrictions tend to stifle creativity, and intelligent solutions are creative.

Researchers want results, so research software engineers are often given complete flexibility in their approach to a problem. Novelty and creativity are encouraged, which means there's rarely a restriction on the tools you can use.

4. Open to open source

The freedom in choosing tools extends to the use of open source. Research is completely amenable to the use of open-source software.

It's not just about the use of open-source software: it's also about the freedom to open source the code that you create. It benefits the whole community when researchers share their work, and this applies equally to software. Research software engineers are far more likely to be active members of the open-source community, and meet far fewer restrictions on being allowed to open source their own software.

5. Wall-to-wall bright people

Universities and research establishments in general are interesting places to work. They are populated by people who are fascinated by the world around them. Research software engineers - who share this passion - find a happy working environment in research institutions.

6. Flexibility

Some people get so engrossed in a solving a problem that working hours is not a term that applies to them. Many research software engineers find themselves coding way into the night in an attempt to get something completed, not because they are being pressurised to do so, but because they enjoy the reward of doing something that others have not been able to do.

Research software engineers get a lot of flexibility in their working environment. Again, it's about results. If you produce the software researchers need, you will receive a lot of flexibility over the hours you work.

7. Why work in only one discipline?

The unique combination of understanding research and software engineering makes research software engineers extremely useful in all disciplines. In fact, many work simultaneously on different projects in different disciplines. Working with such a broad range of subject areas and people is both stimulating and rewarding.

8. Important work

Software engineers might work as part of a large team working on a small part of a software package. Research software engineers will often be responsible for an entire software package - or a large part of it. Such responsibility can be daunting, especially when the results produced by your software could be the foundation of a new research field, but it is also incredible rewarding.

The knowledge that your work could have a big impact is one of the main attractions of being a research software engineer.

9. Collaboration

Of course there is competition within research, but if your hear about someone doing interesting work, you can usually start a conversation with them and often a collaboration. This gives you access to expertise to help improve your software (designers, usability experts, hardware engineers) as well as access to resources from supercomputers to datasets that just wouldn't be shared in industry.

10. Choose your own path

Research software engineers might not yet have a career path in research, but their importance is certainly recognised by the researchers who they work with. The combined benefits of using the tools you want, the ability to swap between interesting fields and being able to make a significant impact with your work means that research software engineers can carve out their own path through research.

Now all we need to do, is make sure that this important role is recognised and rewarded with proper contracts and adequate remuneration. 
 

I've been there. It is fun.

I've been there. It is fun. But good luck getting paid what you're worth. You'll be lucky if you get postdoc wages, let alone a 6-figure industry salary.

Not exactly the experience

Not exactly the experience that I had. No travel, they used open source but were REALLY restrictive on what I was allowed to release back (basically nothing), pay was also pretty poor, lots of political infighting that got annoying, etc. But for one of my first jobs it wasn't bad. I think it depends on where you are and the people involved as to how the job will end up being.

Finally, a title I can share

Finally, a title I can share with folks :-) I love programming in research labs, and you've listed some of the reasons. Cheers!

I couldn't agree more. Best

I couldn't agree more. Best job on the planet.

I worked a research lab for a

I worked a research lab for a couple years and while what is written here is true it's not entirely persuasive, particularly to engineers, because it does not list some of the cons in addition to all these pros. Some example cons: * The pay is not as good as it can be on the commercial side. * You have to be amenable to constant change. * If you aren't working in CS research then most commercial people won't understand your experience if you want to get out of the research environment. * You probably won't ever get to work at the scale of web startups. * You won't experience with commercial project management; agile process, bug tracking, product managers, etc. * You might be working in complete isolation from other software engineers. * Although you get some say in choice of tools, the decision is usually made on what's best for the science and not what is most interesting from a CS standpoint. All that being said, I still find that working in research was extremely beneficial to my career and my development as a software engineer. I learned how to be flexible, to solve problems quickly, to make smart use of tools. So I wouldn't trade that experience for anything.

"You won't experience with

"You won't experience with commercial project management; agile process, bug tracking, product managers, etc." It depends - if you work in a big collaboration (I work in ATLAS) then certainly you will have to experience bug tracking, sw release coordination, large scale daily testing if you work on the software side.

You can also experience this

You can also experience this in a smaller project, especially if you're given some freedom to decide how it's organised! I've been involved in Chaste since its inception, and we use agile processes, Trac, etc. I suspect this is still not the norm, but it's becoming more common, especially with the easy availability of tools like Github meaning that even single researchers can start to do this.

Post new comment

The content of this field is kept private and will not be shown publicly.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.