Building Teaching Skill: Live Coding
OverviewTeaching: 15 min
Exercises: 45 minQuestions
Why do we teach programming using live coding?Objectives
Explain the advantages and limitations of live coding.
Summarize the key dos and don’ts of live coding.
Demonstrate live coding.
One of the cornerstones of Software and Data Carpentry teaching is live coding: instructors don’t use slides, but work through the lesson material, typing in the code or instructions, with the workshop participants following along. This section explains how it works, why we use it, and gives general tips for an effective live coding presentation.
Why Live Coding?
We do not use slides in our lessons. Instead, instructors plug their laptop into the projector and work through the lesson, typing in the code, reformatting data, and talking as we go.
Up and Down
List some advantages and challenges of live coding from both a learner’s and an instructor’s point of view in the Etherpad.
This discussion should take about 10 minutes.
Some advantages are:
- Watching a program being written is more compelling than watching someone page through slides that present bits and pieces of the same code.
- It enables instructors to be more responsive to “what if?” questions. Where a slide deck is like a railway track, live coding allows instructors to go off-road and follow their learners’ interests.
- Lateral knowledge transfer: live coding facilitates the transfer of tacit knowledge – people learn more than we realized we were teaching by watching how instructors do things.
- It slows the instructor down: if she has to type in the program as she goes along, she can only go twice as fast as her learners, rather than ten-fold faster as she could with slides.
- Learners get to see instructors’ mistakes and how to diagnose and correct them. Novices are going to spend most of their time doing this, but it’s left out of most textbooks.
Some challenges are:
- It requires instructors to be able to improvise when things go wrong or when learners have questions not directly addressed in the text of the lesson.
- It can be hard for learners to listen and type at the same time, due to the
split-attention effect we discussed earlier. This is why it’s very important that instructors first explain what they’re going to do, then say what they are typing as they type it, and then explain what they did again afterwards.
- It may take a bit of practice for instructors to get used to thinking aloud while coding in front of an audience.
Live coding fits well into the practice-feedback model we’ve been discussing - by providing learners with continuous opportunities for practice (every time they type in a line of code) and continuous feedback (their code either works or fails with an error message). It’s important to keep in mind, however, that feedback isn’t helpful if you can’t understand it. Many error messages are obscure and not written with novices in mind. Continue to use the strategies for error framing that we learned earlier to make sure this feedback is useful to learners.
The Bad and the Good
Watch this video of live coding done poorly and this video of live coding done right as a group and then summarize your feedback on both in the Etherpad. Use the 2x2 rubric for feedback we discussed earlier.
In the videos, the bash shell
forloop is taught, and it is assumed learners are familiar with how to use a variable, the
headcommand and the content of the
Note: Sometime sounds in the room can be poor. Turning on closed captioning by pressing the cc button will improve the accessibility of these videos.
This exercise and discussion should take about 15 minutes.
The instructor will lead a discussion about the videos and your feedback on them, making sure that the following points have been made:
- Stand up and move around the room if possible. This makes the experience more interactive and less monotonous. Use a microphone if one is available to make it easier for people with hearing difficulties to hear you.
- Go slowly. For every command you type, every word of code you write, every menu item or website button you click, say out loud what you are doing while you do it. Then point to the command and its output on the screen and go through it a second time. This slows you down and allows learners to copy what you do, or to catch up.
- Mirror your learner’s environment. Try to create an environment that is as similar as possible to what your learners have to reduce cognitive load. Avoid using keyboard shortcuts.
- Use your screen wisely. Use a big font, and maximize the window. A black font on a white background works better than a light font on a dark background. When the bottom of the projector screen is at the same height, or below, the heads of the learners, people in the back won’t be able to see the lower parts. Draw up the bottom of your window(s) to compensate. Pay attention to the lighting (not too dark, no lights directly on/above the presenter’s screen) and if needed, re-position the tables so all learners can see the screen, and helpers can easily reach all learners.
- Use illustrations to help learners understand and organize the material. You can also generate the illustrations on the board as you progress through the material. This allows you to build up diagrams, making them increasingly complex in parallel with the material you are teaching. It helps learners understand the material, makes for a more lively workshop and gathers the learners’ attention to you as well.
- Turn off notifications on your laptop and phone.
- Stick to the lesson material. The core Software and Data Carpentry lessons are developed collaboratively by many instructors and tried and tested at many workshops. This means they are very streamlined - which is great when you start teaching them for the first time. It may be tempting to deviate from the material because you would like to show a neat trick, or demonstrate some alternative way of doing something. Don’t do this, since there is a fair chance you’ll run into something unexpected that you then have to explain. If you really want to use something outside of the material, try it out thoroughly before the workshop: run through the lesson as you would during the actual teaching and test the effect of your modification. Some instructors use printouts of the lesson material during teaching. Others use a second device (tablet or laptop) when teaching, on which they can view their notes and the Etherpad session. This seems to be more reliable than displaying one virtual desktop while flipping back and forth to another.
- Leave no learner behind. Use sticky notes to gauge learners’ progress and understanding.
- Embrace mistakes. No matter how well prepared you are, you will make mistakes. This is OK! Use these opportunities to do [error framing]( (/09-mindset/#errors-are-essential-to-learning) and to help your learners learn the art of troubleshooting.
- Have fun! It’s OK to use humor and improvisation to liven up the workshop. This becomes easier when you are more familiar with the material, and more relaxed. Start small, even just saying ‘that was fun’ after something worked well is a good start.
Give each learner two sticky notes of different colours, e.g., yellow and blue. If someone has completed an exercise, they put the blue sticky note on their laptop; if they run into a problem and need help, the put up the yellow one. This is better than having people raise their hands because:
- it’s more discreet (which means they’re more likely to actually do it),
- they can keep working while their flag is raised, and
- the instructor can quickly see from the front of the room what state the class is in.
Sometimes a yellow sticky involves a technical problem that takes a bit more time to solve. To prevent this issue slowing down the whole class too much, you could use the occasion to take the small break you had planned to take a bit later, giving the helper(s) time to fix the problem.
Remind learners frequently about using their sticky notes, or they (and you) will forget.
Teach 3 minutes of your chosen lesson episode using live coding to one or two fellow trainees, then swap and watch while the other person(s) live codes for you.
Explain in advance to your fellow trainee(s) what you will be teaching and what the learners you teach it to are expected to be familiar with.
Don’t record the live coding sessions. Give each other feedback using the 2x2 rubric we discussed previously and enter the feedback you recieved in the Etherpad.
To make this exercise as similar to the workshop experience as possible, ask your fellow trainees to code along with you, as if they were learners at your workshop.
This exercise should take about 20 minutes.
Live coding gives learners continuous practice and feedback.
Live coding forces the instructor to slow down.
Mistakes made during live coding are valuable learning opportunities.