Inverse Live Coding: A practice for learning web development

I finished my first semester teaching at the University of Michigan. I taught EECS 493 User Interface Development all on the Web. It was a tough class for me since I had never before this class used JavaScript, jQuery, or CSS. I learned a lot, but I also had to teach it.

As readers of this blog now, I am a fan of live coding (see blog post here) where a teacher writes code live in front of the class. The positive aspects of live coding include that the teacher will likely make mistakes, so students see that (a) mistakes are common and expected, (b) mistakes can be corrected, and (c) there is a process to recover from mistakes.

I could not live code in this class. I didn’t know the material well enough. It took me too long to code, and I couldn’t recover from mistakes in front of the class.

It was also so hard in the context of a Web-based user interface course. I had the advantage that I could watch videos of Mark Ackerman and Walter Lasecki teach the course before me. Both of them know JavaScript and Web technologies well enough that they could live code in front of the class. I couldn’t understand what they were doing. Part of it was the low-resolution of the video — I couldn’t read the screens well. But a bigger part of it was the cognitive load of remembering the HTML and the CSS while writing the jQuery code. I couldn’t figure out the code while also remembering the names of the divs and how they were nested, and what CSS formats were being applied to which divs and classes. Maybe the younger kids fare better than me in my mid-50’s.

So, I tried a different practice. Maybe call it Inverse Live Coding.

• I wrote programs (HTML, CSS, plus JavaScript with jQuery) before class.
• I demoed and lectured on those programs (briefly — maybe 10-15 minutes).
• Critical: I gave the students the code and all the associated files (HTML, CSS, and JavaScript).
• Then, live in-class, I had students pair up to make small changes to the code.

This is like in-class coding or a lab session, but short — like 8-10 minutes of coding. We can do three of these in a lecture period. It’s more like a Peer Instruction (PI) session than a traditional laboratory coding activity.  I typically put 2-3 of these in a 90 minute class, as part of a lecture. I have students use iClickers to “click in” when they’re successfully done with the change, so we’re using PI practices to make clear what kind of activity this is. That ritual (clicking in then re-joining the class session) helps with bringing people back to the whole-class context after the pair-programming activity.

Here’s an example: I wrote a small JavaScript/HTML/CSS project that had a balloon slowly float upward, and could be steered left or right with arrow keys. (Why yes, that is a Smalltalk balloon in the example.)

I explained the code, introducing ideas like closures and the ready() method in jQuery.

Then I gave them a challenge. In this case, make the balloon also drift to the left, or drift in different directions based on the time or a random variable.

Different kinds of questions: I was pleased by how well this worked. First, it didn’t take much time. 80% of the teams solved at least one of the challenges in less than 8 minutes. Second, the teaching assistants and I got tons of questions. Many of the questions were fundamental ones — things I never would have even thought to talk about in class if I was live-coding. These are (paraphrased) actual questions that I got during the inverse live-coding sessions.

• “Okay, I made the changes in the JavaScript. Now, how do I compile it?”
• “I made the changes using the debugger in Chrome. How do I make this work in the CSS, HTML, or JavaScript files?”
• “So, the jQuery is changing the HTML or the CSS, right? How come my file isn’t changing?”

These were pretty easy questions to handle in class, but one could imagine that those could stymie a student working alone. When I got one of these questions 1:1 or 2:1 during the pair-programming/live-coding, I made sure I answered the question for the whole class, too. These were questions about the fundamental nature of how Web technologies work (e.g., that the interpreter/compiler is the browser itself, and that jQuery says it’s changing CSS/HTML, but it’s really changing the DOM tree, etc.). It was much better to push the students to do the programming, and thus face these questions, than for the teacher to do the programming. The teacher would have an expert blind spot and may not even think to explain those parts that are invisible and confusing.

Miranda Parker suggested a variation of this practice. I could invite students to come up to the front of class to solve the problem, or to explain their solution after the session. That could be helpful in making sure that everyone sees something that works.

I would still use live coding in an intro course, when there aren’t invisible other files involved in the task and increasing cognitive load. In classes like Web Design, I will use inverse live coding more in the future.