Research Software Engineering

Dr Maeve Murphy Quinlan

Who am I?

  • I’m a Research Software Engineer in Research Computing, IT Services
  • I completed my PhD in 2024 in the Institute of Geophysics and Tectonics, School of Earth and Environment, University of Leeds
  • I have made almost every mistake imaginable when it comes to writing code, managing dependencies, tracking changes, submitting HPC jobs…

A “good enough” approach

  • Documentation, guidance, and courses often fall down by aiming for perfection
  • This can lead to people panicking, and not implementing any of the suggestions or tools
  • Everything in this course is incremental:
    • You will be able to implement some little bits without too much work
    • You can improve and add to this over time

PRIMM method

PRIMM is a pedagogical method specifically aimed at teaching text-based programming. While research into adult programming learners is very limited (especially in terms of demographics; many key studies that are cited have overwhelmingly homogenous test groups), the PRIMM method has a few key benefits:

  • It supports learners with different ability levels and who learn at different speeds;
  • It can be applied by learners even if the course materials are not specifically built with it in mind;
  • It can be applied to asynchronous learning materials (for example, if you are using these notes online on your own).

PRIMM method

The P in PRIMM stands for predict:

When you first see a command, script, or piece of code, before running it, predict what you think it will do. It’s ok to get this wrong: the important thing is to get into the habit of predicting! This helps to keep you actively engaged and focused, and begins to build an intuitive sense about the structure of commands.

  • What do you think the code is going to do generally?
  • What do you think the output in your terminal is going to look like?

The R in PRIMM stands for run:

  • Run the code or program;
  • How does the output/effect compare to your prediction?
    • What did you get right?
    • What did you misinterpret?
  • Do you understand what happened?

The I in PRIMM stands for investigate:

Let’s dig a little deeper into the structure of code you’ve used.

  • What options or arguments did you use, and what effect did they have?
  • Can you find some documentation on the command you used?
    • Does the description match how you would describe the code?
      • If no, why does your understanding of it diverge?
    • What other options or features are available?

The first M in PRIMM stands for modify:

  • Try running the code with different options:
    • Change only a small thing at a time;
    • Always predict what you think the output will be!
    • Compare the actual output with your prediction;
    • Compare your understanding to the available documentation.

This stage helps you to gradually increase the difficultly of the tasks you are doing!

The second M in PRIMM stands for make:

This stage is about making the code your own.

  • At this stage, you can try implementing snippets of code you’ve already learned, but to solve a new or different problem;
  • Again, use the previous stages when you are writing your code: predict what you think will happen, run the code and compare the output to your predictions, and investigate the structure of it, especially if it does not behave how you intended!

Learning computational skills

Read before you write - research has proven repeatedly the importance of reading and predicting the output of code as a method of learning, over just getting straight into it and writing code.

  • Novice programmers need to acquire accuracy in tracing code before they can program independently
  • Trying to write code first leads to frustration and confusion

Learn in a way that suits you - if that is copying and pasting commands from the slides instead of trying to keep up with typing, that’s ok!

This is an introductory workshop

  • If you’re already familiar with the concepts that we’re sharing, it’s likely the sessions discussing those topics will be too basic for you!
  • Please feel free to work on other stuff while you’re here - put headphones on, and jump back in when we’re discussing a topic that’s relevant to you.

How this workshop is formatted

  • This workshop is broken up into a series of mini seminars about different topics
  • These seminars will introduce different topics and give you background information that’s often hard to pick up if you’ve learned to use them on your own
  • Please interrupt, ask questions, and discuss!

How this workshop is formatted

But the main aim is to show you how to use all these different tools together…

  • This is often somethings that’s missing when we do an online tutorial on how to use git, or read about Python packaging
  • Many tutorials and workflows online are tailored towards non-research applications and are difficult to apply to our work

Day 1

  • Day 1 is very focused on these short seminars, introducing different topics, that we will tailor to your group
  • In the morning, we’ll discuss some topics from the following:
    • Dependencies
    • Repositories and version control
    • Testing
  • After lunch, we’ll discuss some more project-oriented topics like:
    • Two-directory structure for computational projects
    • Workflows for setting up new projects
    • Ways to salvage legacy code/old messy projects

Homework

Between the two sessions, you’ll have a few tasks:

  • Depending on your experience, you can brush up on some of the topics we covered
    • If you’re experienced, there are some extra exploratory things to try
  • Setting up a local dev environment:
    • You can install and get the tools we used up and running on your local machine
  • Setting up your mini-project for our second session

Day 2

Day 2 is very hands-on and practical. Over the course of the past week, you’ll have come up with a very simple and small project idea

  • In small groups, we will work to:
    • Write the foundational code
      • Create documentation
      • Create tests
      • Package it
    • Create a “project” directory and apply our Package
    • Look at how we can automate running our code with bash scripts

These notes

  • During the course, of course you can just ask me anything you want!

  • During the week and a half between sessions, you can also use the comments section on these notes to look for help.

  • Questions for clarification will also help your fellow cohort!