Stanford University Research Computing
It's hard to not notice that training in computer science has been streamlined to primarily fill industry-level engineering jobs. In this respect, a degree from a top university in computer science is a lucrative choice for a young person to make. The path, and resulting enterprise tools that result from this pipeline are impressive - advances in machine learning, GPUs, and mobile technologies that are changing the world. However, in this overwhelming positivity, it's easy to look over the empty space, or specifically, to ask where those same graduates aren't going.
I started graduate school in 2011 in the Biomedical Informatics (now Biological Data Sciences) PhD program at my institution. During my tenure through early 2016, I experienced the unintended result of having a missing layer of software engineers in academia. Practicing reproducible science, which on the simplest level is conducting an analysis to answer a scientific question, and doing it again, was really challenging. It was ironic to me that I was sitting in the crux of technology and innovation in Silicon Valley, but that the actual practice of research involving programming and software was at least a decade behind. I also came to realize that standard, and elegant practices from software engineering, namely version control, testing, standards, and open source development, were all that were needed to solve many of these issues. I didn't see job security or even a clearly paved career path in front of me, but I decided that the need was dire enough, and inspiring for me that I wanted to pursue it. I abandoned a traditional academic route, and turned down those same industry roles, because I wanted to bring back a layer of missing software engineers from academia.
I worked with the head of our Research Computer Center to create a new role to tackle this problem directly - the first (officially named) Research Software Engineer at Stanford University. In retrospect we know that there were and continue to be many RSEs hidden across the university, however they were labeled as other things. A research software engineer, or "Research Associate" in a lab was not a path that offered much in terms of career advancement, salary, or personal growth. I wasn't sure if I could change that, but the need to work on container technology for reproducible research was too important to me to think about that. I decided that if I worked my hardest to solve general problems, I could slowly make change to prove the value of the role.
With this goal as the prime focus, over the last three years I have realized the power of open source development. While I am sometimes troubled by a changing open source landscape that is becoming more corporate controlled, I have not lost sight of what open source culture has done for researchers. It has been inspiring and powerful, but also served as a driver for a movement around open science. We were hit with the reproducibility crisis around 2015, and simple platforms like GitHub teaching researchers how to use version control, continuous integration, and to perform code review helped with the push for open data, and open code. Personally, open source helped me to grow as a developer. I realized that it was more so much more than opening a pull request on Github. It was dually thinking about the design of systems, and incentives of the users that flow through them. Through interaction with disparate communities, across industry and academia, I've developed awareness about the sometimes conflicting needs of industry and research, but also how the two (sometimes very different) beasts can work together.
I consider myself an open source generalist, because I most commonly try to think about how I want the world to be. I see problems that my users are having, and I want to fix them. I see a need in an academic community that isn't incentivized to be provided by industry, and I work on it. I try to work across industry and academic with hopes that we can help one another. I believe that research software engineers must go beyond the expected role of providing a service, and see the next step.
It's been three years in my current role, and I've (to my own amazement) managed to keep myself funded. I shouldn't take much credit, because it's also been because of the hard work of my fearless leader, who has given me a beautiful balance of support and freedom. My group has hired a second RSE, and he sits with a lab to work exclusively on software for that lab. While this does not involve me, I see it as tiny progress that a research software engineer can be a full fledged person at my institution.
I am creating this "starter-pack" as I embark on my own journey to unite the hidden RSEs at my institution into something that resembles a community. Writing this now, I don't know exactly how I'll do it - I'm not one to make a robust plan in advance, but rather someone that just dives in and starts. I want us to be known so that a researcher that needs help knows exactly where to find it. I want the role to be better supported and funded by the university, and for the same new CS graduates to be able to equally consider an opportunity as an RSE as they would a role in industry. I want my group, Research Computing, to be more than a service department, but also involved in the process of research, and allowed to write grants to secure funding for it. There must be a wider selection of hats to wear beyond solely a PI, researcher, or teacher. I want all these things but I am not a manager or a group leader. I can't do many things, and perhaps I'll never be the best at anything, but I believe that success smells a lot like hard work. So I'll do that.