Exercise list
Below is the list of all exercises in this material. They aren’t made to be done straight-through but inspiration for small-group practice and discussion. Obviously, everything should be adjusted to what ever fits the time and needs of those doing the exercises.
What is a RSE at ASC?
What-is-rse-1: General explanation
Goal: practice the general technical explanation of what we do.
You: roleplay answering your partner’s question. Explain why they, mostly non-computational, might someday be interested in RSE services.
Your partner: A researcher in ENG asks you what our team does. You focus is mainly on measuring the strengths of various materials in laboratories. (You can make up something else)
What-is-RSE-2: Pitch for a research day
Goal: refine our pitching of RSEs and see how others
In groups, everyone gives a 1-3 minute pitch looking for more RSE projects, like you might tell to someone who approaches us at a research day. Compare to others in your group and discuss what the different unique selling points are.
What-is-RSE-2: General audience explanation
Goal: practice interacting with people who have no idea of research or academics.
You: Roleplay answering the question below.
Your partner: roleplay a non-technical family member asking “What do you do for work?” and listen to the explanation. Ask some questions and give feedback.
Garage support
Garage-1: Roleplay a fairly normal support request
Goal: run through a fairly normal support request.
You: roleplay answering a fairly typical garage customer. Figure out who they are (department/position), what their topic is, decide that you can handle it, exact details of the problem, solving the problem, telling them next steps and you know they can do it.
Your partner: roleplay coming to garage and asking some normal-ish question.
Garage-2: Roleplay a support request where you don’t know the answer
Goal: practice telling a customer that you can’t help them right now and giving other options (for example, coming back the next day, waiting a bit for someone else to be free, sending email to arrange a specific meeting, directing them to some other team)
You: roleplay the above. The script should go like the previous exercise but you can’t answer it directly. (you can also pretend you can’t answer it even if you can)
Your partner: roleplay coming to garage and asking something.
Example cases:
Some highly advanced multi-node GPU work.
It’s about data storage in ENG and needs their admin support (not general usage that we could do)
Garage-3: Roleplay with an insistent customer
Goal: practice your confidence when dealing with customers who won’t let go of specific misconceptions they have.
You: roleplay responding to the request below. Try to talk them down and at least have them leave on good terms, since they never seem to give it up.
Your partner: You are a customer is in the garage insisting you know the best way to do something or what is wrong.
Example cases:
Arguing that they should be able to “sudo apt-get install” something and make it just work on Triton, continually arguing when you try to explain why it doesn’t work.
Or why can’t they simply run their Python code, saying that batch isn’t needed. They keep insisting “just help me do X” and acting like we are the problem.
Garage-4: Roleplay someone in over their head
Goal: practice a frustrating situation where it seems, no matter what you do, you won’t be able to help the customer. Find a way to leave them at least a little bit motivated and with an idea for what to do next. (Note: if this happens and it needs to be escalated to the supervisor, contact one of the team leaders.)
You: roleplay responding to the request below. Try to leave them feeling encouraged somehow and with something to do next. Try to understand their background to make the next recommendation.
Your partner: You are a customer in over their head.
Example cases:
The customer only know how to use AI to do things, but they need to know more now.
A customer (new summer research assistant for a ML group) comes to the garage and is clearly in over their head and asking you to do very basic things (ssh, opening a file, editing a file even through Jupyter/OOD), things that even a new summer intern should be able to do. Take, for example, making a Python program run via the command line (they have never seen a command line before and they can’t even begin). This has been happening for several days with the same customer now. You think there may be some deeper problem and their supervisor needs to get involved.
Garage-5: Roleplay answering some recurrent students
Goal: practice telling students (or someone) that they need to use someone else as their primary support channel. Discuss what we do vs what others should do.
You: roleplay responding to the situation below.
Your partner: You are one of a group of students who has been coming each day working on a project. You have just learned this is a project for a course. The students have permission to use Triton (since this is a project with research data with a research PI theoretically supervising), but they have begun asking us about the analysis of their data.
Example cases:
The project is analyzing some social media data and the questions have been about the concepts of network analysis and using a database for the data.
(Note: We can help students in these cases, especially about the mechanics of using Triton. But we can’t replace TAs who should be the first line of support, since courses can direct large numbers of students to us at once, and only the course staff can scale that large.)
Garage-6: Explain some topic in progressively more depth
Roleplay: you have a garage customer, and you are not sure how in-depth they understand some topic. Explain the topic progressively from the big overview, to more and more detailed. Each explanation should be ~30-60 seconds. Can you manage 3-5 explanations on the same topic? Make sure that the customer understands that you always need to start big, even if you are pretty sure you understand
You can choose the topic. The purpose is that when working with a customer, you may not know how knowledgeable they are, so you should start wide (acknowledging they may know this, but you need to be on the same page), and then go deeper.
Sample topics: data storage and transfer. Connecting to Triton. Slurm batch jobs.
Teaching
Teaching-1: Explain a game
Purpose: have some fun while practicing rigorously explaining new concepts to a group (and also practicing evaluating how well the explanations went and giving recommendations to a colleague). We use these lessons in our teaching.
Preparation: Watch or (read) the “Motivation to CodeRefinery instructor training” (teaching tech vs teaching games) material
The task:
Choose board games and divide into groups appropriate for the games. In each group, there should be ~1-2 people who knows the game, and it’s new to the rest (this is flexible)
The 1-2 teachers make a teaching plan in accordance with the lessons in the info. (you don’t have to teach the whole game, or do a complete play-through.) Treat it is our SciComp teaching: not the full picture, but enough to get someone interested and get started. (If there’s a schedule, it may give you an idea of how many minutes you have to teach.)
Teach others the game. The learners pay close attention to the way the game is being taught (perhaps taking notes; without interrupting the teaching too much). You can use this exercise sheet that lists the points from the material to assist in note-taking.
Special notes:
Manage time well and decide the proper level of detail. Don’t get stuck on small things.
When time is up, everyone discusses how the explanation went:
What went well and didn’t go well?
How would you improve it next time?
Also use the opportunity to practice constructive criticism - find a way to say what you think nicely but directly, even if it’s not comfortable.
Teaching-2: Practice a course intro
Take one of the lessons we teach (or something new) and a partner (for team teaching), and give a 3-5 minute intro of the lesson to your group. Pretend that you are livestream teaching to a broad audience.
Others: give feedback and discuss.
Project planner
Planner-1: Roleplay a straightforward project (concept meeting)
Goal: practice the first meeting with a potential customer and establish the basic principles of doing a project. Walk them through what to expect in the RSE project process.
You: roleplay answering the situation below. Ask the basics and establish if the concept of RSE is appropriate for the project, what will happen, etc. You don’t have to pretend to be the one to do the project, but you are getting enough info to take it to a weekly meeting to find the right person to go to the next stage.
Your partner: roleplay a customer requesting a fairly normal project.
Example cases:
LUMI porting
Optimizing some HPC software
Developing a web visualization for some data
Adding documentation, testing, packaging, etc. to some existing project.
Creating a data analysis pipeline.
(you can think of your own things, too)
Planner-2: Roleplay a planning meeting, continuing from above
Goal: practice a structured way to plan out the project, so that everyone leaves with a clear idea of what will happen. Practice with the template project planning doc or equivalent, and co-editing a doc to produce a plan.
Like the exercise above (maybe combined with above), but fill out all template doc and make a plan for what should actually happen (the “planning meeting”). Go through, extracting information about what needs to be done, discuss who does what, and write it down.
(For this exercise, you probably want to use an involved-enough project that both people understand enough and could possibly do)
Planner-3: Roleplay responding to a project request we can most likely not fulfill
Goal: practice directing the customer to other resources or otherwise finding their best way forward, even when we have to say “no”. (This would normally not happen in the concept meeting, but you would take it to the weekly meeting to present to others anyway. You can pretend you did that already, or just pretend you already know we can’t do it.)
Like the exercise above, but you need to tell the customer that it’s not within our capacity (either time or skills) right now. Give a special focus to making sure they have some other path forward.
Your partner: there are different reasons we might not be able to fulfill the project:
It takes too long (years of time, better to hire someone themselves)
It is too specialized (ENG researcher needs specialized laboratory instrument programming, ASIC programming, or something).
They need CPU design
Planner-4:: Roleplay digging to figure out the project
Goal: customers don’t always volunteer important information about the project easily. Practice your skills at digging in, so you won’t forget to do it later.
You: roleplay talking with the customer to figure out their project, and discuss if you can or cant’ do it.
Your partner: present your own previous work as an RSE project. Don’t be too specific (in fact act a bit shy and non-communicative) and force your partner to ask questions to dig deeper and happening.
Technical mentor
In roles/technical-mentor.rst:
Mentor-1: Discussing with another staff member about a sub-standard support session
Goal: you noticed a support session in garage that you thought could be improved. Respectfully bring it up and tell your team member that you think something could be improved.
You: roleplay telling a colleague that their support could have been a little bit better.
Your partner: Listen to the feedback.
Example cases:
Your colleague’s explanation was too technical for the apparent level of the customer.
Your colleague said “shouldn’t you have learned this in [course]”
Your colleague sent the customer away saying they need to learn more first, but didn’t make it clear how to start that.
Unit liaison
UnitLiaison-1: Give a ASC introduction
Roleplay giving a sample 3-5 minute pitch of ASC services to a department meeting. You get to pick the department.
UnitLiaison-2: Knock on someone’s door
Roleplay visiting an office of a group leader and talking about RSE services. (you can also imagine talking in a coffee room, to other group members, etc.)