I would have called myself a research software engineer from the mid-1980s to the late 1990s, and if I could send email back in time and tell my younger self what to learn, only some of it would be about programming. The rest would be about how to talk to clients and colleagues about what they wanted, how to keep a project on track (or tell if it’s gone off the rails), how to run a productive meeting, and how to manage my own time. I’d also tell me to learn how to teach, since it turns out RSEs spend a lot of their time explaining things and how to get people on side, and how to organize a community, since we also seem to spend a lot of time convincing people to work together.
Oh yeah, and how to clean up other people’s messy code. That would have been a big one.
So here’s my recommended reading list for that part of research software engineering:
- “Why Crunch Mode Doesn’t Work”
- Working Effectively with Legacy Code
- Scrum and XP from the Trenches
- GUI Bloopers
- Producing Open Source Software
- The Discussion Book
- The Checklist Manifesto
- Teaching What You Don’t Know
- How to Teach Adults
- Marketing for Scientists
- Building Successful Online Communities
- Building Powerful Community Organizations