instructors.qmd

# Teaching in class 👩‍🏫

```{r}
#| include: false
# To trigger downlit.
```

## Tips for teaching

Here are some steps and guidelines when you are an **instructor**:

-   Start by *introducing a bit about yourself* and perhaps why you're
    interested in teaching R and data analysis.

-   Keep mindful of the time and try to *stay on time*. The lead
    organizer will be also be keeping track of time and wave to you to
    continue on or slow down.

-   Try to assume the participants *know as little as possible*. This is
    actually quite hard, but try as best you can. The lead organizer may
    take notes and provide feedback after your lesson or clarify
    concepts to the participants. Try to (briefly) explain as much
    aspects as possible of what you are doing, including how to open
    RStudio or how to run code (e.g. press `Shift-Enter` in RStudio).

-   **Check in with participants**: We distribute colored sticky notes
    to each participant so that they can flag problems with one color
    and success with another color. Use these indicators to check your
    pacing and where the class is at. See the section below for more
    details.

-   Throughout the exercises and code-along sessions, reinforce the use
    of troubleshooting techniques including finding help from other
    resources.

-   We teach the [tidyverse](https://tidyverse.org) way of using R,
    meaning we use packages like `{dplyr}`, `{tidyr}`, `{rmarkdown}`,
    `{ggplot2}`, `{purrr}`, and so on. This also means making use of the
    pipe `%>%` operator.

-   We follow the tidyverse [*way of writing and styling R
    code*](https://style.tidyverse.org/).

-   Be kind, and remember, your words *matter a lot*. Try to avoid words
    like "basically", "its just", "as simple as", and so on. This is
    difficult, but at least try.

## The live-coding technique

The majority of the lesson material is *participatory live-coding*, so
use of slides is minimal. The purpose of the course is to *type with the
participants*, to show by doing. Live-coding is a hands-on method of
teaching coding to a group in which the instructor shares their screen
with the group and types out and narrates all the commands in real-time
on their own computer while the group follows along. Live-coding is a
very effective teaching technique: it forces the instructor to go slowly
and ensures that participants get to try out every command being used.
It allows learners to experience common errors themselves, to see errors
occur when for the instructors (thus demystifying that everyone no
matter the skill level experiences errors) and debug them in a
supportive environment, to explore variations on material as they go,
and to immediately check their understanding by trying things hands-on.

Live-coding is a technique used by [Software
Carpentry](https://software-carpentry.org/about/). Software Carpentry
has lots of great resources explaining the why and how of live-coding:

-   [10 tips and tricks for instructing and teaching by means of live
    coding](https://software-carpentry.org/blog/2016/04/tips-tricks-live-coding.html).

-   The Software Carpentry [instructor training
    manual](https://carpentries.github.io/instructor-training/) includes
    many resources about programming education.

## Before your session

-   Have an RStudio theme that uses a white background with black text.
    This setting is easier to read on projectors.

-   In `Global Options -> Appearance`, put a higher zoom value and
    increase the font size (maybe around 14). Exact zoom and font size
    depends on the projector.

-   Put the Console and Script panes side by side rather than stacked.
    This can be changed in the `Global Options -> Pane Layout`

-   If you use Vim or Emacs keybindings in RStudio, change to the
    default that the learners use, so that 1) they see similar behaviour
    as what you are doing 2) doing fancy/quick stuff is *not* going to
    help them learn 3) it slows you down a lot more since your muscle
    memory for the default keybindings will probably be similar to the
    learners muscle memory.

-   If the instructor team is sharing a code-along repository (e.g. so
    there is continuity between session), make sure to pull the latest
    changes from the previous session.

## During your session

-   At the start of the session, except for the first one, quickly
    review what was covered in the previous sessions. Doing this can
    help remind the learners where they are at in the course and to
    reinforce what they learned previously.

-   At the beginning of the morning sessions and occasionally throughout
    the session, refer back to the big picture of why we are doing what
    we are doing.

-   For most of the sessions, there are sections that tell the
    participants to read on their own. Know beforehand where these
    sections are and get them to read over the section when you come to
    it. Preferably, you should briefly go over the content again, to
    reinforce what they read and to address any questions and, where
    relevant, emphasize the *why* of it. Don't spend too much time on
    it.

-   Try to keep the screen on your RStudio as much as possible and don't
    switch applications often, only when you need to go to the course
    material or to show an exercise. Otherwise people get lost, since
    they have to be looking up to the screen and then down to their own
    laptops, which takes a lot more time.

-   For code-along sessions, narrate what you are doing as you are
    typing by describing and explaining what the function or code does
    and what you want to achieve with it. Typing alone doesn't help
    explain the *why*, and learners need to understand the why to help
    them reinforce the concepts and code. This is particularly important
    for the wrangling sessions, where you should explain what each
    function does and examples of instances where you would use each
    function. (It's also something we often get feedback on.)

-   Try not to deviate too much or go on tangents during the code along.
    The code-along should have almost the exact same code as is on the
    website.

-   Be aware of how much space you have on the projector screen and
    don't let R code go too long. You have two options to take so that
    all code stays on the screen (use which ever you find most visually
    appealing):

    1.  Use soft-wrapping of R code. You can set this in RStudio by
        going to `Tools -> Global Options -> Code -> Editing tab` and
        then tick the "Soft-wrap R source files" option.

    2.  Or, adding more lines to the code then you normally would use.
        For instance, instead of:

        ``` r
        ggplot(NHANES, aes(x = BMI, y = Age, colour = Diabetes)) +
            geom_point()
        ```

        You could add new lines like:

        ``` r
        ggplot(NHANES, 
               aes(x = BMI, 
                   y = Age, 
                   colour = Diabetes)) +
            geom_point()
        ```

-   There are areas called "Details for instructors" that have notes or
    comments about something to focus on or reinforce for a concept.
    Make sure to know where these are and to use them to help you as you
    go through the material.

-   Be aware of the time as you go through your session. It can be easy
    to forget and let time pass, but its important to keep moving on,
    even if there are tangential questions that come up.

-   If a section doesn't mention for the student to read it, that means
    the instructor should mention and talk about it. But don't read it
    word for word, instead talk about it while doing the code along.
    It's strongly suggested that you try to use your own words rather
    than exactly what was written. This makes it easier for you and
    makes it more engaging for the learners.

-   Something that takes some practice as a teacher is getting used to
    being in an instructor role and essentially being in a position of
    "power" over the learners. People come to the course consenting and
    expecting to being in this instructor-learner hierarchy, trusting
    (or hoping) that the instructor helps guide them into learning
    something new and/or useful. They are willingly giving their time to
    sit in front of you and listen after all! This hierarchy comes with
    a lot of responsibility and "duties", several of which relate to
    making sure the learners know you are present. Taking up space in a
    non-aggressive and friendly way, moving around, looking out in the
    audience and making eye contact (lots of eye contact), are all key
    aspects to showing you are there for them and present.

-   Unless there is an explicit "reading task" or "read this text",
    assume that you as the instructor should verbally explain the text
    on the webpage.

-   When helpers are helping out, especially when there are two or more
    helping out, as the instructor wait until they are done or go check
    on them if you feel they are taking too long. Don't continue the
    lesson until helping has slowed down or stopped.

### During the exercises

-   For discussion exercises/activities, when participants answer a
    question/share something, the instructor should repeat the thing so
    everyone else can hear as well (since instructor usually has the
    microphone).

-   For the exercises, make sure to get the learners helping each other
    out in their groups.

-   Exercise solutions do not need to be covered by the instructor,
    given the solution is provided already. However, if there is time,
    it can be useful to the participants to have the instructor narrate
    about how the code works and why we used this code.

-   Try not to go over the time given for the exercises. If many
    learners are struggling to finish on time, make a note of it to fix
    or revise later and then go over it with everyone.

-   Exercise solutions do not need to be covered in too much detail by
    the instructor, given the solution is provided already.

    -   During the exercise, copy and paste the solutions from the site
        into your code-along R Project, so you can move to the next
        section quickly.

### Making use of the stickies

-   Check in with the learners to see where they are at by asking
    something like: "Do you see the same thing as is on the screen?" If
    yes, put the 'all good' sticky on your laptop. If no, use the 'need
    help' sticky."

-   For the reading activities, before starting, say: "Please read this
    section as instructed. When you are done, put the 'all good' sticky
    up."

-   For exercises, before starting, say: "Please complete the exercise.
    When you are done, please put the 'all good' sticky up. If you need
    help, put the 'need help' sticky up."

## Using the slides

The slides are generated from the
[xaringan](https://github.com/yihui/xaringan) R package, which uses
[remark.js](https://remarkjs.com/#1). In the slides, there are notes
that you can read either by going to the source `.Rmd` file or by
opening the slides and hitting the `p` key. To use the slides more
efficiently, check out the [remark.js keyword
shortcuts](https://github.com/gnab/remark/wiki/Keyboard-shortcuts).

## Resources

-   [Carpentries: Teaching the
    teacher](https://carpentries.github.io/instructor-training/)

-   [Carpentries: Tips for
    instructors](https://docs.carpentries.org/topic_folders/hosts_instructors/instructor_tips.html)