Ian Cosden
April 16, 2019
At Princeton University, our Research Software Engineering group is nearing its third birthday but many people still ask basic questions about us: What is a Research Software Engineer? What do you do? How do you work with researchers?
In an attempt to answer some of these questions I like to begin with an analogy.
Most adults know how to cook something. Maybe it’s ramen, tacos, or lasagna. Some are pretty terrible (me) and some are actually quite good cooks. If you want to learn how to cook there are lots of resources available: cookbooks, YouTube videos, there are even multiple television channels devoted to cooking. This is great, but all the reading and watching will not make you a professional chef. Instead, through a combination of training and experience chefs have developed a skill set and repertoire that allow them to cook at a level far above that of even very good home cooks. Perhaps more importantly, chefs view cooking as their profession.
When it comes to academic researchers, most know some programming. Maybe it’s Python, C++, or MPI. Some researchers are actually quite good programmers while others view programming as an evil they must endure in order to advance their science. If you want to learn how program there are lots of resources available: books, youtube videos, even full courses. This is great, but reading books and watching webinars doesn’t make someone a professional Research Software Engineer (RSE). Instead, through a combination of training and experience RSEs have developed a skill set and repertoire that allow them to write software at a level far above that of even very good researchers. Perhaps more importantly, RSEs view programming as their profession.
See where I’m going?
[As a quick but important aside, it should be noted that Research Software Engineers go by many titles, including those with the word “programmer” in it. I’m using the term RSE to refer to anyone, regardless of title, who approaches their work in this manner. I’ve seen RSEs who fit this mold with dozens of different titles ranging from Scientific Programmer, Postdoctoral Research Associate, and Programmer Analyst, to name a few. I’ve even seen a few graduate students who are essentially RSEs. Don’t get hung up on the terminology or names, rather, it’s how you approach the work that’s important.]
Now, to take the analogy even farther, imagine that you had never eaten at a restaurant. You’ve only ever eaten at home and have no idea what a professional chef is capable of preparing. Sure, you’re a great cook, but you’d be missing out! And the catch is, you wouldn’t even know it.
By combining software expertise and research experience, good RSEs have the capacity to transform research, sometimes in unforeseen ways. Domain expert researchers (grad students, postdocs, faculty) frequently prioritize research/science outputs and often come to view software as a byproduct. By contrast, an RSE’s job and priority is directly focused on the software. An experienced RSE has the tools, knowledge, and incentive to work collaboratively with domain researchers to ensure the performance, reliability, and sustainability of resulting software. RSEs promote long-term research goals by their sustained participation in research projects, collecting and curating ideas and contributions from short-term researchers, and realizing them in mature algorithms, products, and distributable packages. Additionally, through mentoring and collaborating with junior research software developers, RSEs serve to “raise the game” of all collaborators by exposing them to professional best practices and technologies.
But it can go even further.
Until you’ve had a chance to see it, you’ll have to take my word for it; a good RSE can do things that an average programmer simply can’t. RSEs are often capable of accomplishing tasks that were previously thought to be impossible or intractable, and sometimes even the inconceivable. When it comes to advancing science through software, this can be a game changer.