tl;dr
I learnt a lot about how to teach live coding by becoming a Carpentries instructor.
Whittling down the complexity
I learnt a lot from the part of the workshop about live coding and wanted to share the experience.
The Carpentries use a specific workshop format with an emphasis on using participatory live coding. This means people follow along with the instructor who is sharing their code on a screen at the front of the room. There are no slideshows to sit through, so no ‘death by PowerPoint’.
There are some features of live coding that make it conducive to learning:
- it slows down the pace so all learners can keep up
- instructors must explain what they’re doing with every line, encouraging detailed explanation
- learners become familiarised with running code given the particulars of their machine and software
- it’s beneficial for learners to see the instructor make mistakes and correct them
I recommend looking at The Carpentries top ten tips for participatory live coding, which is a short but excellent resource to make sure people get the most out of your session.
Say what you saw
You can probably remember a workshop that you enjoyed and learnt a lot from. Maybe you can think of one that didn’t go so well. What was the difference? How can you, as an instructor, engage with participants and motivate learning?
In the ‘live coding is a skill’ lesson we watched two contrasting videos staged by Lex Nederbragt that show an instructor live-coding in front of a class.
These videos are linked in the sections below. Pay attention to whether they follow the top tips for live coding in particular.
Clamp down on negative behaviours
First, take a look at this video of an instructor who has room to improve.
What did you notice? What would make it difficult for you to engage?
For example, the instructor didn’t:
- check if everyone could see the small white-on-black text on the screen
- explain each line as it was executed
- turn off notifications on their computer and phone
- notice a participant’s sticky note (which signals that help is needed)
These are all behaviours that can be improved upon given feedback and reflection.
Make it plane
The second video demonstrated more positive behaviours.
For example, the instructor:
- explained each line as it was being typed
- re-sized the shell so people will always see the last-typed line
- physically pointed out things on the projector screen to reinforce what was happening in the code
- made an error, but talked it through
This time the instructor considered the needs of the audience and kept them engaged.
Hammer it home
We then did short, three-minute, live-coding demos of Carpentries materials in small groups. We provided feedback to help each other improve and engage better with learners.
We ran the demo twice each: the first time was relatively cold with little preparation, but for the second attempt we had a chance to react to the feedback and to think about the teaching demo assessment rubric.
Sanding the rough edges
I chose to do the ‘exploring data frames’ episode of the R for Reproducible Scientific Research lesson of Software Carpentry.
Positive feedback from my first attempt included that I:
- made sure everyone could see what was on my screen and it was at a sufficient zoom level (I had reset RStudio to its defaults because this is what beginners would see)
- gave the learning objectives and recap of the previous session to remind people what we were doing and what we had done already
- executed code line by line at an appropriate speed with clear instructions
Some points to improve upon where that I:
- didn’t say out loud the keyboard shortcut that I was using to execute the lines
- said that the
c() function was for ‘concatenating’ elements into vectors, which is a word that some people may not be familiar with
- used the word ‘simply’ when describing how to do something, a phrase that could undermine a learner’s progress if they aren’t able to complete that task (a case of an ‘expert blind spot’, as discussed in the ‘expertise and instruction’ lesson of the workshop)
Nailing it
I reacted to the feedback to help improve things for my second live-coding demo. For example, I:
- said out-loud every action I was doing, including physical key presses when necessary (e.g. “and run this line with the command and enter shortcut”)
- avoided phrases like ‘simply do this’ and ‘just do that’
- said that the ‘c’ in the
c() function means to ‘combine’ rather than to ‘concatenate’
I also did a couple of extra things:
- added three lines of comments at the top of the file to explain the objectives and goals
- pre-loaded an object into the environment (they learnt how to do this in the previous session) to avoid a slightly awkward explanation at the beginning
- expanded my RStudio window so more code be seen at once
The second attempt was well-received, thanks to feedback and a greater appreciation of the audience’s needs.
Environment
Session info
Last rendered: 2023-07-24 20:25:27 BST
R version 4.3.1 (2023-06-16)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.2.1
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib; LAPACK version 3.11.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
time zone: Europe/London
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] htmlwidgets_1.6.2 compiler_4.3.1 fastmap_1.1.1 cli_3.6.1
[5] tools_4.3.1 htmltools_0.5.5 rstudioapi_0.15.0 yaml_2.3.7
[9] rmarkdown_2.23 knitr_1.43.1 jsonlite_1.8.7 xfun_0.39
[13] digest_0.6.33 rlang_1.1.1 fontawesome_0.5.1 evaluate_0.21
