Exercise list

This is a list of all exercises and solutions in this lesson, mainly as a reference for helpers and instructors. This list is automatically generated from all of the other pages in the lesson. Any single teaching event will probably cover only a subset of these, depending on their interests.

Teaching online

In teaching-online.md:

Exercise

Using HackMD, brainstorm advantages and disadvantages of online and in-person teaching. For each disadvantage of each, think of ways to compensate.

Team teaching

In team-teaching.rst:

Exercise

Divide into groups of two or three. Choose one of the two models in the team-teaching page, and quickly (5 min) prepare a short topic (3-5 min) to team teach. You can quickly scan the “preparation” section at the bottom.

The challenge is not just to give the lesson, but to prepare the lesson quickly and rely on each other to give a good lesson anyway.

HackMD

In hackmd.rst:

Exercise

  • Actively use HackMD during this course.

  • Observe how the instructors integrate it during the course itself, and can immediately respond to the questions.

  • Observe how instructors occasionally mention and screenshare HackMD to validate to the audience that it is being watched.

  • Keep HackMD open. Can you balance it and watching. Does it increase or decrease engagement?

Teams

In teams.rst:

Teams

Consider these questions:

  • Should teams have similar or different people in them?

Livestreaming

In livestreaming.rst:

(advanced) Set up and install OBS as a livestreaming tool.

This exercise is open-ended.

Instructor tech setup

In instructor-tech-setup.md:

Evaluate screen captures

Evaluate screenshots within the instructor tech setup lesson. Use the collaborative document to make a list of the trade-offs of each one. Which one do you prefer? Which are useful in each situation?

In instructor-tech-setup.md:

Set up your own environment

Set up your screen to teach something. Get some feedback from another learner. We will discuss among the class.

Video editing

In video-editing.rst:

Editing-1: Get your sample video

Download a sample video:

In video-editing.rst:

Editing-2: Run Whisper to generate raw subtitles and test video.

First off, install Whisper and generate the base subtitles, based on the. Since this is probably too much to expect for a short lesson, they are provided for you (above), but if you want you can try using Whisper, or generating the subtitles some other way.

You can start generating subtitles now, while you do the next steps, so that they are ready by the time you are ready to apply the editlist. ffmpeg-editlist can also slice up the subtitles from the main video to make subtitles for each segment you cut out.

Whisper is left as an exercise to the reader.

In video-editing.rst:

Editing-3: Create the basic editlist.yaml file

Install ffmpeg-editlist and try to follow its instructions, to create an edit with these features:

  • The input definition.

  • Two output sections: the “Intro to the course”, and “From data storage to your science” talks (Remember it said the recording started at 11:35… look at the schedule for hints on when it might start!). This should have a start/end timestamp from the original video.

A basic example:

- input: day1-raw.mkv

# This is the output from one section.  Your result should have two of these sections.
- output: part1.mkv
  title: something
  description: >-
    some long
    description of the
    segment
  editlist:
    - start: 10:00    # start timestamp of the section, in *original* video
    - end: 20:00      # end timestamp of the section, in the *original* video

In video-editing.rst:

Editing-4: Run ffmpeg-editlist

Install ffmpeg-editlist: pip install ffmpeg-editlist[srt] (you may want to use a virtual environment, but these are very minimal dependencies).

The ffmpeg command line tool must be available in your PATH.

In video-editing.rst:

Editing-5: Add more features

  • Several chapter definitions.(re-run and you should see a .info.txt file also generated). Video chapter definitions are timestamps of the original video, that get translated to timestamps of the output video.

    - output: part1.mkv
  editlist:
  - start: 10:00
  - -: Introduction    #  <-- New, `-` means "at start time"
  - 10:45: Part 1      #  <-- New
  - 15:00: Part 2      #  <-- New
  - end: 20:00

    Look at the .info.txt files that come out now. What is new in it?

  • Add in “workshop title”, “workshop description”, and see the .info.txt files that come out now. This is ready for copy-pasting into a YouTube description (first line is the title, rest is the description).

    Look at the new .info.txt files. What is new?

In video-editing.rst:

Editing-6: Subtitles

Re-run ffmpeg-editlist with the --srt option (you have to install it with pip install ffmpeg-editlist[srt] to pull in the necessary dependency). Notice how .srt files come out now.

Use some subtitle editor to edit the original subtitle file, to fix up any transcription mistakes you may find. You could edit directly, use subtitle-editor on Linux, or find some other tool.

What do you learn from editing the subtitles?

In video-editing.rst:

Editing-6: Subtitles

Re-run ffmpeg-editlist with the --srt option (you have to install it with pip install ffmpeg-editlist[srt] to pull in the necessary dependency). Notice how .srt files come out now.

Use some subtitle editor to edit the original subtitle file, to fix up any transcription mistakes you may find. You could edit directly, use subtitle-editor on Linux, or find some other tool.

What do you learn from editing the subtitles?

In video-editing.rst:

Editing-7: Generate the final output file.

  • Run ffmpeg-editlist with the --reencode option: this re-encodes the video and makes sure that there is no black point at the start.

  • If you re-run with --check, it won’t output a new video file, but it will re-output the .info.txt and .srt files. This is useful when you adjust descriptions or chapters.

In video-editing.rst:

Use ffmpeg-editlist to edit this sample video

Prerequisites: ffmpeg must be installed on your computer outside of Python. Be able to install ffmpeg-editlist. This is simple in a Python virtual environment, but if not the only dependency is PyYAML.

In video-editing.rst:

Why teach together?

In why-teach-together.rst:

What similarities do we have?

Using HackMD, make two lists:

  • What courses do you think your local community would benefit from, which you don’t currently have? +1 other people’s items which are also relevant to you.

  • Which courses are you thinking of preparing for your local community? +1 other people’s items which you would be interested in helping out with.

Collaboration models

In collaboration-models.rst:

List successes and failures in collaborative teaching

Using HackMD, list some successes and failures in collaborative teaching that you have experienced.

In collaboration-models.rst:

Recommendations for co-teaching

If you have experience with co-teaching, what approach/technique/trick can you recommend a colleague who would like to try co-teaching for the first time?

Workshop roles

In workshop-roles.rst:

How many people teach in your workshops?

  • Using HackMD, make a histogram of how many (instructors + organizers) you typically have in your workshops.

  • List some of the common roles you have used.

Why are computers hard?

In why-are-computers-hard.rst:

Exercise

Think of a tool or technology that is easy to understand and use if you understand the underlying abstraction layers, but is almost impossible otherwise.

Diversity and inclusion

In diversity-and-inclusion.rst:

Reflect on how your job can be defined to promote diversity.

What are some (possibly surprising) ways that your job promote diversity and equality among people of different backgrounds?

Lesson development with version control

In lessons-with-version-control.md:

Contribute to a sample lesson

  • Open this very lesson in GitHub (it uses the same format as typical CodeRefinery lessons): https://github.com/coderefinery/community-teaching/

  • Browse the files and understand the general idea. Check out at least these and use HackMD to record their functions:

    • .github/workflows/sphinx.yml

    • content/conf.py

    • content/index.rst

    • content/lessons-with-version-control.rst

  • If you want, try to make a pull request to this lesson. It doesn’t have to have any significant content, it can be a pure test pull request.

In lessons-with-version-control.md:

(advanced) Create your own lesson

Use the sphinx-lesson-template to create a new lesson of your choice. Alternatively, use the current Carpentries system, or some other system of your choice.

Backwards lesson design

In backward-lesson-design.md:

Backwards-design a lesson/topic

Choose a simple lesson topic and apply backwards lesson design. You won’t get all the way through, but come up with a logical progression of exercises.

The section you pick should require screen sharing and be of some follow-along task (preferably using a shell).

Some suggestions:

  • Regular expressions

  • Making papers in LaTeX

  • Making figures in your favorite programming language

  • Linux shell basics

  • Something non-technical, such as painting a room

  • An instructor training for CodeRefinery

  • Some aspect from an already existing lesson

  • Introduction to high-performance computing (or an episode therein)

  • Unix shell in a HPC context (or an episode therein)

  • A lesson you always wanted to teach

CodeRefinery teaching philosophies

In 02-teaching-philosophies.md:

Ice-breaker in groups (20 minutes)

  • Share your approach to teaching and your teaching philosophy with your group.

  • Please share your tricks and solutions in the live document for others.

Additional ice-breaker questions:

  • What is your motivation for taking this training?

  • How structured or informal are your own teaching needs?

  • What difference do you notice between the teaching what we (also Carpentries) do and traditional academic teaching?

  • What other skills need to be taught, but academic teaching isn’t the right setting?

In 02-teaching-philosophies.md:

Anne Fouilloux

I regularly teach Carpentries workshops so I try to apply what I have learnt to CodeRefinery workshops. However, I know our target audience is very much different and that I need to adapt my teaching style. I am still trying to find what works best in which situations and this is why I like so much CodeRefinery workshops. We usually have a wider range of skills and very mixed backgrounds so we usually have to be more careful with the pace and time given for exercises.

Some considerations:

  • I spend quite a lot of time reading the CodeRefinery material and practising myself exercises. I particularly like to read the instructor notes just before teaching: they usually highlight important aspects both for preparing and teaching.

  • I usually do not show too much in advance the material as I think it prevents asking questions. If you have less competent practitioners in the classroom, they can easily copy-paste to avoid slowing down the entire classroom.

  • Ideally, I’d like to give several exercises so anyone can work at its own pace. I find it is important that everybody gets something different from the workshop.

  • I love breaks as it gives us an opportunity to discuss with attendees on their research topics. I am especially interested to understand what software they write and how they plan to use what they learn during our workshops.

In 02-teaching-philosophies.md:

Bjørn Lindi

My teaching style has changed a bit since I started with CodeRefinery. In the beginning I had this “BLOB” (Binary Large OBject) of knowledge and experience that I wanted to to convey to the participants. With experience and some help from the Carpentries Instructor training, I have realized I need to serialize the “BLOB”, to be able to share it with others.

In a similar fashion as you would do with a binary large object which you intend to send over the wire, you will need stop signals, check-sums and re-transmissions, when you give a lecture. I have come to appreciate the natural periods/breaks the lessons offers, the questions raised, the errors that appear during type-along and the re-transmission. Co-instructors are good to use for re-transmission or broadening a specific topic.

When I started with CodeRefinery my inclination was to give a lecture. Today I am trying to be a guide during a learning experience, a learning experience which includes me as well. That may sound a bit self-centric, but is in fact the opposite, as I have to be more sensitive to what is going on in the room. The more conscious I am of being a guide, the better lesson.

Tools that I find useful in preparing a lesson is concept maps and Learner Personas, though I have develop to few them.

In 02-teaching-philosophies.md:

Thor Wikfeldt

I never want to leave any learner behind and I really don’t like seeing confused, blank faces in the classroom. At the same time I sometimes worry about some participants getting bored if a lesson is progressing slowly. This is always a difficult compromise and something I struggle with!

I try to focus on making concepts intuitive, to “make sense” to the learners. Of course this is usually based on how I learned the topic myself and how it makes sense to me.

I try to establish connections between topics: “this thing here is similar to what we saw in the previous lesson where we learned about X…”.

Before mastering a lesson by teaching in many times I try to “follow the script”. After becoming very familiar with a lesson I start to improvise more and react more dynamically to questions, e.g. by taking a detour to explain a confusing topic more clearly.

What I think I do too often: copy-paste code/text from lesson material. This can leave learners behind - typing out the code and describing it is slower, but more learning takes place. More advanced learners will hopefully “be compensated” by interesting advanced exercises which follow.

In 02-teaching-philosophies.md:

Stefan Negru

A lesson is a conversation, it is useful if both the trainer and the trainee are engaged. For that reason I try to have, most of the time, a conversation with the classroom and after we finish parts of a lesson, step back and see how we might use what we learned.

That brings me to another point I follow throughout the lessons, answering questions like:

  • How can we apply in practice what we just learned?

  • Do you see yourself (the trainee) using that in practice, why or why not?

Most of the times those seem like open-ended questions to the trainees that just learned something new, so I try to find examples, most of the times from personal experience.

Last thing is that analogies are important when I teach, I try to find analogies in order to simplify a convoluted part of a lesson.

In 02-teaching-philosophies.md:

Radovan Bast

My teaching changed by 180 degrees after taking the Carpentries instructor training. Before that I used slides, 45 minute lecture blocks, and separate exercise sessions. After the Carpentries instructor training I embraced the interaction, exercises, demos, and typos.

My goal for a lesson is to spark curiosity to try things after the lesson, both for the novices (“This looks like a useful tool, I want to try using it after the workshop.”) and the more experienced participants (“Aha - I did not know you could do this. I wonder whether I can make it work with X.”). I like to start lessons with a question because this makes participants look up from their browsers.

Keeping both the novices and the experts engaged during a lesson can be difficult and offering additional exercises seems to be a good compromise.

For me it is a good sign if there are many questions. I like to encourage questions by asking questions to the participants. But I also try not to go into a rabbit hole when I get a question where only experts will appreciate the answer.

I try to avoid jargon and “war stories” from the professional developers’ perspective or the business world. Most researchers may not relate to them. For examples I always try to use the research context. Avoid “customer”, “production”, also a lot of Agile jargon is hard to relate to.

Less and clear is better than more and unclear. Simple examples are better than complicated examples. Almost never I have felt or got the feedback that something was too simple. I am repeating in my head to not use the words “simply”, “just”, “easy”. If participants take home one or two points from a lesson, that’s for me success.

I prepare for the lesson by reading the instructor guide and all issues and open pull requests. I might not be able to solve issues, but I don’t want to be surprised by known issues. I learn the material to a point where I know precisely what comes next and am never surprised by the next episode or slide. This allows me to skip and distill the essence and not read bullet point by bullet point.

I try to never deviate from the script and if I do, be very explicit about it.

A great exercise I can recommend is to watch a tutorial on a new programming language/tool you have never used. It can feel very overwhelming and fast to get all these new concepts and tools thrown at self. This can prepare me for how a participant might feel.

I find it very helpful if there is somebody else in the room who helps me detecting when I go too fast or become too confusing. I like when two instructors complement each other during a lesson but when doing that to others, I am often worried of interrupting their flow and timing too much.

A mistake I often do is to type too fast and in my mind I force myself to slow down.

In 02-teaching-philosophies.md:

Sabry Razick

My approach is to show it is fun to demystify concepts. Once a concept is not a mystery anymore, the learners will understand is what it means, where it is coming from, why it is in place and what it could it offer for their future. I try to relate concepts to real life with a twist of humour whenever possible if the outcome is certain not be offensive to any one. I use diagrams whenever possible, I have spent weeks creating diagrams that is sometime three or four sentences. That effort I consider worthwhile as my intention is not to teach, but to demystify. Once that is achieved, learners will learn the nitty gritty on their own easily and with confidence, when they have the use-case.

In 02-teaching-philosophies.md:

Juho Lehtonen

I’m gradually realising the different ways to get a hint whether the workshop participants are still following or perhaps bored. I assume it’s communicating with the class, with exercises and simply by asking now and then. I also try to remember to observe how people look like (puzzled, bored) while I teach, not so obvious for me.

I believe that learners communicating with each other, in addition to with instructors and helpers, really helps them to understand things faster. (At least it helps me). So I try to make sure that no one sits or works alone at the workshops.

In 02-teaching-philosophies.md:

Richard Darst

Like many people, I’ve often been teaching, but rarely a teacher. I tend to teach like I am doing an informal mentorship. I’ve realized long ago that my most important lessons weren’t learned in classes, but by a combination of seeing things done by friends and independent study after that. I’ve realized that teaching (the things I teach) is trying to correct these differences in backgrounds.

My main job is supporting computing infrastructure, so my teaching is very grounded in real-world problems. I’m often start at the very basics, because this is what I see missing most often.

When teaching, I like lots of audience questions and don’t mind going off-script a bit (even though I know it should be minimized). I find that sufficient audience interest allows any lesson to be a success - you don’t have to know everything perfectly, just show how you’d approach a problem.

In 02-teaching-philosophies.md:

João M. da Silva

I started giving technical trainings twenty years ago, and hence my perspective is perhaps more inclined towards the development of hands-on abilities and capability to solve problems, independently or in a team.

But the development of hands-on practical skills, requires some essential knowledge about the domain and some willingness to try different approaches in case one gets stuck. Some call this the “KSA approach” (“Knowledge-Skills-Attitude). Hence, I try to impart the essential knowledge (and where to find out more) at my trainings. And to encourage and challenge students in order to make them overcome their self-perceived limits (e.g. “I’m a Humanist, I can’t use Python virtualenv”).

I’ve been trying to study more about the Cognitive aspects of learning over the years, and I should find out the time to return to that. There’s very interesting research in Problem Solving, with Learning being a important component in that domain.

Storytelling: humans are neurologically made for paying attention to good stories, and that’s something that I try to put into account: to give a lesson like it would be a relevant narrative for the students, one that they could relate to and help them in their work

I like to draw and be creative with that, but have to pay attention to my handwriting during my trainings. I reckon that Architectural diagrams help students to understand the big picture, so I should invest more on those when development training material. I would also like to start looking into Concept Maps and Semantic Trees in training.

Interactive teaching style

In 03-teaching-style.md:

In 03-teaching-style.md:

Give feedback on teaching (optional, 10 mn)

This exercise aims at learning to give feedback. It is optional as we have similar exercises when practising teaching). As a group, we will watch this video of teaching and give feedback on two axes: positive vs. negative and content vs. presentation. Have each person in the class add one point to a 2x2 grid on a whiteboard or in the shared notes (hackMD, etherpad, google doc) without duplicating any points. For online instructor training event, use breakout room (4-5 persons per group) to facilitate discussion. Then each group reports to the shared notes. You can use a rubric (used during The Carpentries teaching demos) to help you take notes. What did other people see that you missed? What did they think that you strongly agree or disagree with?

In 03-teaching-style.md:

Exercise: How to identify learner profiles?

  1. How to identify leaner profiles from surveys and during the class

  2. Which types of learners should the leassons focus on

Teaching practice and feedback

In teaching-practice.md:

Exercise

  • We organize the breakout rooms to not only discuss one lesson/topic so that it is more interesting to listen and also probably we will all get more useful feedback.

  • Give each other constructive verbal feedback on the teaching demos, for example using this demo rubric.

  • Write down questions (in the collaborative document) that you would like to discuss in the main room or interesting conclusions which you would like to share with others.

In teaching-practice.md:

Exercise

  • In the second round we distribute the rooms differently so that you can present it to a new group of workshop participants and can receive new feedback.

  • Ask for feedback and one/few point(s) you want to improve.

  • In your second trial check whether you feel the demonstration improved.

  • Share your lessons learned in the collaborative document.

  • Give us also feedback on this exercise format. Was it useful? What can we improve?

In teaching-practice.md:

Exercise

Teaching by live coding is a performance art which requires practice. This exercise highlights some typical pitfalls that most instructors fall into sooner or later, and also shows how to avoid them. Watch closely since we will be giving feedback!

  • Watch these two videos: video 1 and video 2

  • What was better in video 1 and what was better in video 2?

  • Please give feedback in the shared workshop document.