How can we teach RSE skills to people who wish to pursue a career in research software engineering?
There is some work going on around this in the Nordic Countries at Code Refinery. We are hopeful that these kinds of lessons and interventions can become a part of some broader Carpentry learning pathways in the long-term. While not the full-scale curriculum needed, these are some great steps to begin the appeal toward technically talented researchers, setting them on a path toward RSE-type skills and best practices.
Hiring students for part time work, or full time summer internships, with an RSE-type group can be the next step after workshops, although working with the constraints of student schedules and funding situations can be a challenge. An unpaid version of this can also work, where students receive some training, possibly through a series of workshops, and then are mentored as they work in support of a research project. The workshops are essential, but the relevance of the skills seems to sink in more when they are struggling with a real project. Having guidance/mentorship/supervision available when they get to that stage makes a difference.
My answer is an answer to a different question: How do we train scientists in basic RSE skills?
My vision is to generate educational materials which can be integrated into the traditional STEM curriculum and to generate materials which can go “viral”. So, every workshop/tutorial we generate should be intended to be taught by a non-expert.
My answer to the question you actually asked we need to grow the role of RSE individuals and groups and encourage & facilitate their ability to mentor students. My answer builds a bit on what @cmaimone said. I think it should be bigger than internships, and instead be about changing the role of RSE in the academy to be “regular” scientists who take on summer students, PhD students, and postdocs and have access to programs and funds which support training.
We do this through our REU program (http://reu.ncsa.illinois.edu) and to a lesser extent, through our internal student research program, SPIN (http://spin.ncsa.illinois.edu). INCLUSION starts with a 2-day software carpentry workshop.
I would love to see more software-focused REU sites as well (REU sites support ~10 students who are generally not from the institution that hosts the site).
And anyone who has NSF funding can apply for an REU supplement to their project to support 1-2 undergraduates (these supplement requests are mostly awarded).
Greetings from Michigan’s Upper Peninsula.
In my graduate course (mostly first year graduate students; some senior undergraduates as well), UN5390: Scientific Computing , I have been formally implementing the following definitions of sustainability for the last 3-4 years. Dr. Robert Handler (firstname.lastname@example.org), the operations manager of our Sustainable Futures Institute at Michigan Tech, sets them up to understand what sustainability means in the general sense in week #1 or #2 of the semester.
Then, in in-class discussions and assignments and projects throughout the semester, I expect them to address #1-#4. I learn about #5 from students or their graduate advisors (or internship/co-op supervisors) sometime down the road.
Does the code/script sustain incorrect execution? Emphasis is on checking the necessary arguments/options and validating them thoroughly before proceeding with actual computation - to prevent misuse/abuse of computing resources or deletion of necessary files.
Does the code/script sustain my own lack of attention for a short/long period of time? Emphasis is on useful comments and other aspects of code hygiene.
Does the code/script sustain being passed on to someone else (say, the next graduate student in their group) and in turn, lend itself to be improved upon down the road? Emphasis is on including relevant hardware and software metrics as part of the comments and explaining logic in easily understandable fashion.
Does the code/script sustain stoppages (e.g., power outage, etc.) and continue from where it stopped? Emphasis is on periodic checkpointing the output. It’s also on keeping simulation parameters outside of the code when possible - preferably in a flat text file - so that the same executable can be run on different sets of input parameters.
Do the students sustain what they learned in the course after the semester ends and continue integrating them into their research projects? Emphasis on using revision control systems, incremental code development, testing, commenting, documenting, sharing, etc.
I hope this helps someone. I am looking forward to learning and sharing more via URSSI in the future.
this is off-topic for teaching, but since Gowtham’s message was also about definitions of sustainability, I wanted to point at something I presented Monday and just wrote up this morning: https://danielskatzblog.wordpress.com/2018/09/26/fundamentals-of-software-sustainability/