This is a crosspost from VanessaSaurus, dinosaurs, programming, and parsnips. See the original post here.
I recently gave a talk, “The Research Software Engineer Movement” for the EasyBuild users meeting, 2022.
It seems like a fun story, but what you can’t see from watching the talk is that it took a lot of research. Specifically, I poured through endless posts like this one - a not so brief history of research software engineers along with talks on YouTube, academic papers, and even going back to some of my interviews on RSE Stories.
As I was learning more about the RSE movement, it hit me that all of the events that are happening with US-RSE, and more generally, our community history, lives only in our heads. This would be problematic, for example, in the future if someone (that did not live through the experience) wanted to understand how events unfolded. I pinged Dan Katz on Slack and brought this up to him, and suggested that we write a history post. I knew he was involved in the earliest steps of the community and would be a good person to ask. He championed the idea and we got to work! 🎉️
But it couldn’t just be me and Dan. In fact, over the years I’ve seen a few people publishing on US-RSE, and it rubbed me the wrong way that the community was not included, or even given the option. I decided this would be the first effort that would be different. And so I added to the new draft in the Google Document and wrote this at the top:
What is this?
This is a community blog post (not meant to be shared on the syndicated community blog at https://us-rse.org/blog but on the main site’s feed) that recounts the early history of US-RSE.
Why do we want to do this?
Taking after this post, we want to preserve the story of how US-RSE was founded, and how it originally grew. However, to both offer more perspectives and be true to our code of conduct about equality and inclusivity, we invite any community member that has a piece of the story to tell to participate, or to review the draft if you do not feel you were present in the early days.
What will the post include?
The post will be structured chronologically, and in sections based upon events or ideas. Anyone that has perspective on a time is welcome to contribute. The post will also include references to “historical documents,” or emails / correspondence / digital media that will also be added to a new section of the website for preservation.
How do I participate?
Jump in to edit or review the document (suggestion mode is suggested at first to discuss changes). If you have something you think might be considered a personal document, please mention in a comment / link and we will see where we can add it! We also want to make an effort to add references (events, papers, etc.) wherever possible.
What about my personal perspective?
You can see this document as a central root to a larger tree of stories. We encourage participants to write their own story into a personal blog or similar, and we can link there. Then we will have a main community story linked to many personal accounts, which will be great to have in the future. For example, if you worked on establishing an RSE group at your institution, it would be so lovely to have a record of what you did.
If you are worried about your post (or the place where you serve them) not surviving into the future (e.g., sites like Wordpress that require a database can sometimes be harder to maintain than a static, community site) we suggest that you create a special tag like “rse” for the community syndicated blog, and it will also be preserved there.
My thinking was that we could have a community document, and then individual community members could expand on it (as I am doing now) and posts would appear in the Community Syndicated Blog. It’s so important to me try to engage with the community to the largest extent possible. This means being open an welcoming to invite others to contribute, or share their part of the collective history. So other than sharing our post:
⭐️ A kind-of brief shared early history of US-RSE ⭐️
I want to contribute my own story here. And yes - the title was important to be a bit of a pun on the original post by the UK folks! Since I’m fairly concrete and a lot of my story is what I’ve done, this will include a lot of projects. But I also want to share my story because there is just so much (and I don’t want to forget it).
I entered graduate school in 2011, and I’ve probably written about this somewhere here, but I had finished up working for two years in the Laboratory of Neurogenetics at Duke University, and I had vision for what I wanted to build and absolutely lacked the skills. I applied to graduate school and ultimately went to Stanford, and over these 5 years there indeed was challenge and adversity, but when I finally found my graduating thesis lab Poldracklab and delved much deeper into working on software for neuroimaging, I found a love not just for this weird intersection between research and software, but also for containers, APIs, and standards.
A few months before graduation I wrote about my vision for a layer of “academic software developers” across an academic university, and worked closely with the head of research computing to create a new role to work exclusively on reproducible science, meaning containers and workflows for HPC. This is why we called it the “Reproducibility Research Engineer” which was an “Information Specialist” on the back end. I am still so grateful to Ruth (the CTO) for believing in me and taking me on, and giving me this first role that gave me freedom to engage with communities and work on things that I was passionate about. I love how the need for research software engineering, if you look back on a lot of our histories, is engrained in us. I knew this was an important thing long before I heard the term Research Software Engineer. I strangely had vision for RSEs at my institution many years before I had even heard the term.
Since this post is about US-RSE, we can skip over all the things I worked on in these five years, and jump straight to 2019. I don’t remember how I heard of US-RSE, but it was in May that I found the slack, and I remember giving a “Hello world!” and introducing myself. Unfortunately I can’t go far enough back in time in the slack to see this original post, but I can easily date it based on looking at my pull request history for the US-RSE site (N=110 at the writing of this post). If you want to skip the sections below, the takeaway is that I felt like I had found my people, and had immense enthusiasm and ideas for the community. In no particular order, some initiatives driven by my excitement were:
The community syndicated blog was ultimately a vision I had for a single place that an interested party could subscribe to read about the work of many research software engineers. On May 14, 2019 I added a link to the implementation that I came up with a day earlier. It’s been really nice for me (and I hope others) to have a single place to subscribe to posts, and it’s now almost 3 years old. You can read posts here. Ironically, given that this post has the rse tag, it will appear there! 🎉️
Most folks are familiar with our map at us-rse.org/usrse-map. You might be surprised to learn that the original map was actually a part of the main website, and I added it on May 18th, a few days after the community blog. My desire here was really to see the extent of our influence. For most of my years at Stanford I felt pretty alone in my role, and having a map to just see “the signal of research software engineering” was something I selfishly wanted. It would also be useful to see the growth of our community. The map, as you know, was eventually moved to be maintained on its own repository on February 22, 2020, and primarily because my design preference for different things that require automation or separation of responsibility is for modularity. The map continues to update itself monthly, with a little manual tweaking by myself and sometimes Dan Katz to fix spelling or the format of city locations (thank you Dan)! We are an RSE roster-updating team!
Along with the map and community blog, I wanted to create a self-updating graphic that would show our growth over time, which would be possible because the membership form fed into a Google Sheet where I could make a second sheet to count by month. With the power of JavaScript I was able to add the initial graphic to the site, and eventually add a button to download it, and then automate its update. And yes, the fact that it changes color on every load is definitely a Vanessa thing, lol. ⭐️
Along with adding the original contributing guide, I got really excited at some point about making a contributors graphic, and took two shots at this - first with a hairy workflow and ultimately with a library I developed called tributors, which was done to replace the original workflow that I didn’t think was reliable. You can see our contributors in the bottom of the README.
One of my personal projects, urlchecker, I thought would be useful to add to the site in March 2020. This would do basic sanity checks for our URLs included in the site, and I eventually added spell checking to go alongside it. And one thing that is harder to see is that on April 5, 2021 I pushed the first refactor of the current site to a non-existing branch, main, which would eventually be made the default branch. We had wanted to transition from master to main anyway, and this would be any easy way. The new design had 150 files changed, almost 32K additions and ~9k deletions. Yeah, wowza. But I did it in a weekend, for the most part. It’s just a website! But on that same thread, this is why it took the website working group a few months of tweaking it to get it right - it was far from perfect. But I suspect it was enough to get us started in the direction we wanted to go!
RSE Stories might be my biggest contribution to US-RSE and the overall RSE movement, because it’s enabled so many different kinds of people to tell their story, and inspired others to create podcasts as well. Why did it happen? I was frustrated with the state of the world. I saw a few people in positions of influence telling a very limited story about what it meant to be a research software engineer. So in July of 2019 I produced a video, the story of the Research Software Engineer:
and ultimately realized it wasn’t enough. I woke up in a morning in September with an idea to start a podcast and literally have people tell their stories, and this was the start of the Research Software Engineer Stories podcast, for which Ian Cosden offered to be the first interviewed. Along with the podcast I created the phenotype generator where someone could easily play with the tool to explore or visualize their phenotype. I asked guests on RSE stories to give this a shot, but most didn’t, so at some point I dropped it. I am definitely not cut to be a podcast host, but I’ve somehow pulled it off for almost three years now. Will it go on forever? If it’s just me, probably not, but I hope to tackle this as something to work on in the new outreach working group.
If I remember correctly, the original site had jobs hard coded into the page, and I knew this would be really hard to update or build any kind of automation around! So I refactored to read the jobs from file, which was a good move because we eventually had a script to count jobs over git history, an ability to remove expired jobs nightly, and eventually an action to update Twitter and Slack with new job posts. And at least as of the beginning of this year, our job board is exploding! At the time of writing this post we have over 30 jobs.
The RSEPedia was another small project that I started in early 2020 that has extended to include a criteria and taxonomy, a database of software that is updated automatically weekly, and the software itself. I presented it at SORSE: Research Software Directories, What, Why, and How on September 17, 2020, and also entered it as a fun video Twas the Night Before SC Lightning Talk in November 2020 and the Science Slam. The science slam won me $800, which I donated to US-RSE and became the funding to get our first logo (and probably some other things). You can read more about that here and (fingers crossed) a paper we submit at the end of 2020 might eventually be accepted! I’m hoping to do more work to organize this research software space - I have some promising analyses underway!
And in a smaller sense, you can browse the PRs of the US-RSE repository to see that I was also interested in site metadata, bug fixes, search, adding previews on CircleCI, the structure for events, contributing, documentation (always!), and organization. Outside of US-RSE, I created an opensource heart beat action, open source Halloween, and awesome-rseng, a list of research software engineering resources.
Some of my vision hasn’t taken off, such as the desire to have community documents or the community starter pack, the terms glossary, the needs-love community issue board, the RSE manifesto, and the community template. You’ll notice a lot of these are under the rseng organization, and I created this org after my creation of too-many-projects on the USRSE organization rubbed some people the wrong way. It was understandable, because USRSE isn’t an open source project space. But does it matter that many projects aren’t successful? Absolutely not - most projects will not be successful. Some of them will never be, and others might in the future, and it was just that the idea was too early. I never have regret having ideas and making them turn into reality.
A big part of my work in these last years has been speaking about research software engineering and how to get involved in the community. When I was at Stanford this included a talk at the Stanford Campus IT Plan Research Summit 2020 on February 18, 2020 and the talk Research Software Engineers: A New Career on January 6, 2020 at the UIT Unconference. My biggest honor was being invited to give at keynote at SeptembRSE in late 2020, and I created the Stories we Tell Ourselves website alongside it. Then my most recent talk (which I likely will give again) is the one that prompted this historical document and post, The Research Software Engineer Movement at the 2022 EasyBuild users meeting. I also am just very loud about research software engineering at my workplaces because we aren’t at a point yet where it’s really an embraced kind of role. I think we can get there!
Wow, so the listing above is just what I can remember from these last three years. There are details I’m forgetting like fun initiatives within initiatives like Open Source Halloween and publishing the fun stories as the Halloween Special Episodes, and I can’t measure or even have a sense of how/if I’ve impacted others in our US-RSE slack with ideas or things that I’ve shared. I suspect maybe so, because every once in a while I get a heart-felt message from someone that makes my day. It’s really these messages that give my spirit flight, and not publications or similar. I don’t think I’ve ever actually felt anything when publishing a paper. But when someone reaches out to me and says that I’ve changed how they think about something, possibly even themselves? That feels amazing. ❤️
Now this is the point where we talk about leadership. I’ve been asked why I’ve never applied or submit my name to be on any kind of steering committee or similar. The reason is because I think a community to be balanced needs bottom up leadership in addition to the top down leadership that a traditional governance structure provides. It’s important to me that everything I do for US-RSE is done because I want to do it, and I’m inspired to do it, over having or needing to do it because of some official role. I also hope to inspire others through these tiny efforts that I’ve done over the years. This kind of leadership, the one that grows organically and on equally footing as a community member, is where I see myself having greatest impact.