Research Educators

Good heavens! For more than 40 years I have been speaking prose without knowing it.

— Moliere

I think I finally know what I’ve been trying to do for the last ten (fifteen, twenty-two…) years, but in order for it to make sense, you first need to know what a research software engineer is. An RSE is someone with a research background whose primary job is to write software; they’re like an astronomer who mostly builds telescopes rather than looking at the stars. The term originated in the UK in 1992; I don’t know when I first heard it, but when I did I realized that the best way to describe Software Carpentry’s mission was “teaching the basics of research software engineering”.

Since 2014, though, I have spent most of my time teaching people how to teach rather than how to program. Some of those people have been Python or JavaScript developers working in industry, but most have been researchers who teach in contexts ranging from weekend workshops to full-semester courses. They are end-user teachers, but I now think they’re a distinct enough subset to deserve their own label.

By analogy with research software engineers, I propose calling these people research educators (REs). An RE combines in-depth understanding of research with expertise in education and training. Just as RSEs primarily write software to support research, REs primarily create and deliver lessons for their fellow scholars. They almost certainly have a graduate degree in some research-intensive discipline; they might have a Certificate of Higher Education, but most REs are faculty who have somehow found themselves in teaching-intensive roles without being trained for it.

The Carpentries’ instructor training and offshoots like RStudio’s instructor training program are to research educators what the Carpentries’ workshops are to research software engineering. Call it the first step, or the bare minimum it’s reasonable to expect everyone to know—either way, they’re meant to be starting points rather than goalposts.

Updated: