A glossary of terms for research software engineering

Posted by g.law on 13 November 2019 - 9:50am

glossary%20image.jpgVanessa Villamia Sochat, an engineer for the Stanford Research Computing Center, has begun creating a glossary of terms just for research software engineering.

 

In software engineering or academia in general, there are many important details to focus on, and tasks to handle in a professional manner. For example, we write papers in what might be referred to as "academic speak" and learn to adapt our behaviour to what looks best for our profession or career. If our work is important and to be highly regarded, every interaction and initiative needs to reflect that.

While professionalism and details are important, they sometimes come at the cost of having fun. 

Small initiatives that are fun and help to grow our community are often neglected because they don't seem to directly further a cause or a reputation, or there simply isn't enough time. 

This is where the community can step up. It might be that others are too busy, or lacking resources, but if a small group or single person can decide that something is important and make the time, change can follow. This is the reason that I decided to put together the Research Software Engineer Glossary - it would help to grow community in a way that possibly isn't allocated for on paper. At maximum, it would be interesting and fun, and create greater awareness for RSEs. There are in fact subtle differences in the role of RSE as compared to a researcher or traditional software engineer, and a community driven set of definitions could capture that. I also hope that the community will contribute terms and definitions that are approachable and fun. At the minimum, it would put a small stress on GitHub servers to have another repository. When you think about it, it's mostly win-win, because the resource was also fun to make and share. 

This is a general sentiment that I hold across domains of work. A lot of small projects get overlooked because they don't fit within a well-established roadmap. We don't try things because we believe that we need to ask for permission first. We convince ourselves that we need some higher institutional support or funding to start our tiny ideas. For the most part, this isn't the case, and if you have vision for something, and see that it could be useful, you should just do it.

So what terms do you think should be added to the RSE Glossary? I hope you contribute your ideas at  https://us-rse.org/rse-glossary/.


Want to discuss this post with us? Send us an email or contact us on Twitter @SoftwareSaved.