Last week I wrote about why I think live coding is a good way to teach coding in a class. This week I’m continuing with considerations about how to get set up to do this effectively. Next week I will write about the nuts and bolts of how I make it happen. I’ll then move on to other aspects of coding instruction in class: testing and assessment strategies, collaborative learning, and teaching coding and other material simultaneously.
Setup seems like a super boring thing to read about. But hang with me here. I think of my strategies for live coding as strategies to keep from giving students reasons to disengage. If a student already thinks they might be bad at coding, things like “I can’t read what the professor has on the screen anyway” or “Once you get behind at all it’s impossible to keep up” are great reasons for a student to phone it in. I wouldn’t blame them at all for it at all. If something is already challenging, additionally hurdles feel really stupid and frustrating.
Here are some of the things I consider when setting up a class.
Be sure students can easily read what you are doing on the screen
This one sounds pretty obvious, but it can be a little nuanced! First, of course, be sure that the code you are typing is in a big enough font that it can be easily read from the back of the room.
Character size is one thing, but consider colors too. What works well for you when you write code might not work well in a classroom. I strongly prefer to code in “dark mode”, where the background is dark and the code on the screen is light. It doesn’t hurt my eyes as much when I’m coding for a long time. Dark mode is harder to see on a projector screen. I always switch to light mode for teaching. Then if you are using a scheme in your code editor that colors functions, parentheses, numbers, etc differently to help with readability, be sure that that scheme is high contrast and that all the colors can be seen on a projector screen.
Finally: if you can, don’t just increase the font size, but zoom your whole environment/code editor. I use posit studio (rstudio) and there is an option to magnify the whole window. I use that and the font size to make everything big. The reason is that if the font size is big but the buttons, menus, etc are all small, students might get lost when you are doing stuff other than directly coding.
Record your lecture periods
Every day when I come into class, I log into a zoom session that is called “recording lectures”, a session with locked down privacy, whose link I’ve never shared with anyone. I share my screen and hit record to cloud. At the end of the session, when I end the zoom call, the recording uploads to my university's video system automatically. I go in and give it a meaningful title, make sure it worked, and share it on our LMS with the students. That system provides automatic captions that are quite good. It really is not much extra work at all.
But still, why? Well, if a student gets lost, and despite my best efforts, doesn’t want to ask for help: they can watch the videos. If students coded along but didn’t understand something: they can go back to the video. If a student was absent, they can watch the video to catch up. This is especially critical if your lessons span multiple class periods, where someone would be completely lost if they missed class for part 1 and then came to part 2.
Provide complete notes/code
I can see an argument against this if you are also recording lectures, but I give students a complete version of the code we will work through that day. I’m very clear that I ask students to take ownership over their own learning. I tell them, yes, if they wanted to, they could just scroll through that code, or copy/paste it into their window. But I also explain why that would make class way harder for them when it comes time for activities, labs, and tests. Moving about the room, I have seen no evidence of students using the completed code to bypass working through the code in class.
There are multiple benefits to having the completed code, which I also explain to the students. First, if they get behind in class, or really can’t get something to work, and don’t want to ask for help for whatever reason, they can open that code, copy/paste, and get up to speed. I think this is a good option for not losing people. They can also reference that code for studying, as it is often formatted much nicer than what they write in class (despite my best efforts). And if they lose their code for some reason, they can always go grab the completed code.
Consider ways that students can let you know you need to slow down or stop
As suggested by The Carpentries, when I teach special one or two day coding trainings I give students a red sticky note. I tell them if they get stuck to put the sticky note on their computer screen. This is low-key and let’s me know I need to shift to a mode where I can address their question. Typically I’ll give the class some sort of task, and then go visit them, or I’ll just ask what their error is.
I tried doing this in full semester classes but I found students’ willingness to use the stickies drops off quickly after the first few classes. I think at this point I have my pacing pretty dialed, so I’m not worried about it as a mechanism for students to tell me to slow down. And then for questions or snags, I tell students to raise their hands, but I also watch them pretty carefully. In most cases I feel like I can tell if someone needs me to come over or to ask what their error is. It’s tough to have a coding-frustration poker face! I also walk around the room when I give little coding challenges and I can see students’ screens and whether they are in the ballpark of where they should be.
I think those are my main strategies for keeping students engaged with my overall set up. Next week I’ll talk about nuts and bolts: how I host material, how to get around common computer issues, and how I run class when I live-code.