In this episode, we talk with Mark Guzdial, Professor of Electrical Engineering and Computer Science, with a courtesy appointment in the School of Information at the University of Michigan.

You can find this episode’s transcription down below!

Listen to us on Apple Podcasts, Stitcher, Spotify, or wherever you get your podcasts.

You can also download the episode directly here.

Be sure to follow us on social media! You can find us on Twitter and FaceBook!

Summary

Our conversation focused on live coding, which is programming in front of the class as the students would program. Mark emphasized that the most essential part of live coding is modeling process. The second part is modeling how to manage mistakes. And the third is to create opportunities for students to make predictions.

For his “something awesome in computer science,” Mark talked about how he loved that computer science can be anything else. That computer science can look like and behave like any other discipline.

Mark’s Too Long; Didn’t Listen (TL; DL) broadened our original conversation by pointing out that, while live coding is useful, it’s one method among many and not necessarily the most important one. Other teaching methods he thought were also important included peer instruction, contextualized computing education, and generally, to start with a problem.

Transcript

Kristin: Hello, and welcome to the CS-Ed podcast, a podcast where we talk about teaching computer science with computer science educators, to learn how they teach and manage their classrooms. I am your host, Kristin Stephens-Martinez, an Assistant Professor of the practice at Duke University. And joining me today is Mark Guzdial, formerly of Georgia Tech, now University of Michigan. And–I actually don’t know–what is your title there? Is it just–are you just a full professor there?

 

Mark: Yeah. The word full doesn’t–doesn’t appear, just professor. 

 

Kristin: That’s okay.

 

Mark: But I have a cool one–so I’m a professor in computer science and engineering. But I have a courtesy appointment in the school of information–or my title is: Professor of Information, which I think is pretty funky. I like it. 

 

Kristin: That’s cool. So, professor of multiple things. And tell us a little bit about yourself. What do you teach? How many students do you have, Mark?

 

Mark: So, at Georgia Tech, every fall I teach a class for PhD students, and every spring-slash-winter at Georgia Tech we always said spring–Michigan would say the winter semester–I regularly taught the Introduction to Media Computation for–which is a required class–for liberal arts, architecture, and business students; 250 to 300 students, over 50 percent female. Here at the University of Michigan, I’ve only been here for two semesters. In the fall I taught User Interface Software Development, which was about front-end, web-stuff: JavaScript, React, Angular sorts of stuff, I had 120 students. And then I taught a special topics undergrad and graduate course in the winter semester on CS education research. This fall, I’ll be teaching Engineering 101, a required course for all engineering students. I’ll probably have about 220 of them, and half the class is in MATLAB, and the other half is in C++. 

 

Kristin: So, today with Mark we’re going to talk about live coding in the classroom. So, I do some live coding in my classroom, you do a lot of live coding in your classroom, I’m sure, you’re a huge proponent of it. So, how don’t we first start, though, with defining what is live coding?

 

Mark: So, live coding is programming in front of the class. In particular, it’s programming as the students would program. So, I’ve seen some folks prepare code and copy and paste it into an editor in front of the students. For me that’s not live coding, because the–the point of live coding is to model the process. We talk–most of computer science–we talk about programming, we talk about the programs, we talk about the product, but not necessarily: how do we get there? What do you do first? When do you pause to test? How do you test? So, live coding is about modeling process, and then the a really big part of it is to make mistakes. Nobody can program live in front of dozens of students and not make mistakes. And the making a mistake is the opportunity to puncture the belief that nobody–that nobody else is having mistakes. We know that there’s a bunch of students who think, “I’m the only one who’s getting problems like that.”

 

Kristin: Yeah. 

 

Mark: So, we want to show them, “No, everybody makes mistakes. The professor in the front of the room makes mistakes.” So, you want to make mistakes to model: how do you react to them? “Oh no. I got an error! What the heck could that be?” You know–you know, you want to talk–articulate the process of how you go about figuring out what the error is. So, the most important part is modeling process. The second part is modeling how to manage mistakes, which of course means to make mistakes. And then the third reason to live code, that–that I’ve been learning a lot about lately, is to create opportunities for making predictions. 

 

Kristin: Okay, what kind of predictions do you mean?

 

Mark: So, the work on predictions is inspired by research from Eric Mazur at Harvard, who’s a physics professor, is the inventor of peer instruction. And he’s been noting that–they’ve run a series of experiments over several semesters–where they compare not doing a demonstration–

 

Kristin: Yep.

 

Mark: –doing a demonstration. So, demonstration physics, weights or water, fire, and explosions, whatever they do in physics. Weight.

 

Kristin: Yep.

 

Mark: You know, things weren’t going down ramps–

 

Kristin: Their experiments are so much more awesome than computer science at times. 

 

Mark: I completely agree. So–so it’s no–no demo, just lecture, having a demo, making students predict before a demo, and then making students predict before a demo, doing the demo, and then having students discuss their predictions with each other afterward. 

 

Kristin: Okay.

 

Mark: And there doesn’t seem to be any statistically significant difference between predictions and predictions plus discussion. Predict–they both do the best of those groups–the worst is getting a demonstration without prediction. 

 

Kristin: Ah.

 

Mark: Because what happens is that students–nobody actually has a photographic memory–in reality, people remember things in terms of their model of the world. He would do these–these–the–the–do these comparisons of demonstration, or do a demonstration, and then two weeks later give people an exam and ask them to write down how confident they were of their answer and why. And students would say, “I’m completely confident of this wrong answer, as seen in demo in class.”

 

Kristin: [laughter]

 

Mark: They would misremember the demo. 

 

Kristin: Oh!

 

Mark: So, the point of a prediction is to get students to recognize when they don’t understand something. Roger Schank sometimes called it failure-based learning, that you learn only when you realize there’s something you didn’t understand. So, I argued that every time we execute a program live, in front of a class, we are doing a demonstration. And to us, as the teachers, it’s perfectly obvious what the result is going to be. 

 

Kristin: Yeah.

 

Mark: But my guess is the students–it’s not always obvious to them, or they may not realize when they’re not getting the point. So, by making them make predictions, I get them to think about what–what do they think the program’s supposed to do before it does it. Live coding is this great opportunity. I would, you know, take people from the audience saying, “Hey, what if you did this with the picture, Guzdial? What if you do that with the sound?” during media computation stuff. And I’d go ahead and implement it, and I said, “Before I hit run, before I press the play button, before I showed the picture, what are we going to see?” And then I would often do this as a peer instruction. 

 

Mark: I’ll take three or four answers, and then have people vote on which one of the–these three or four answers did they think was really going to be what happens. And then we run the program and talk about it. So now, everybody in the room had to make a prediction. Everybody had to commit to one of these choices that were suggested by somebody else. 

 

Kristin: I love that.

 

Mark: It’s about doing predictions as a way of testing your understanding of what the programs are doing. 

 

Kristin: So, for people who have not done a lot of live coding, how can they get started?

 

Mark: Sure. So, I guess a lot of it depends on the kind of programming environment that you’re using. 

 

Kristin: Okay.

 

Mark: So, I tend to prefer using a–an IDE (Integrated Development Environment) that gives me a REPL, Re-Evaluation Print Loop. So, I have a command line. 

 

Kristin: Ah, okay. That’s what you meant.

 

Mark: Yeah. So, I have this in Python, in–in JES, or in IDLE, both for those. So, the very first thing that I do at the beginning of class is work from the command line to do things, and then I write my first program by copy-pasting what already worked from the command line into the program. So, the program is basically a macro for the commands that I had just executed earlier–

 

Kristin: Ah, okay. 

 

Mark: So that the students saw what each line did, and now I’m putting it together in a function. And so, this allows me to make the mapping. 

 

Kristin: Got it.

 

Mark: So, it’s actually how I did it even when I taught Java. I used to–when we first started teaching Media Computation, which at Georgia Tech was always in Python–we taught a bridge class for students who got interested in computer science, and then wanted to get into the–the CS Major–and the CS Major–most of the classes were in Java. So, I taught a media computation class that was a bridge class between the intro and Python, and the major’s Java–intro Java course. And there I used DrJava, because it gave me a command line with Java, so that I could do the same thing. I could type commands at the command line, make sure the students understood what those were doing, and then copy-paste them into a method, or the main function of a class, in order to be able to explain what a method or main was doing. 

 

Kristin: Huh. I didn’t know Java could have an actual, like, interface where you’re running command line as Java. I’ve never heard of that. Cause–

 

Mark: Go ahead. 

 

Kristin: I’m teaching the Java class for the first time next spring; and so, I’m going through all of the Java class assignments right now, and I’m re-remembering all of my old Java, from like, 10 years ago. 

 

Mark: Yeah, yeah, yeah. 

 

Kristin: And I’m like, “Oh right. You have to compile. This is so strange.” 

 

Mark: Yeah. 

 

Kristin: I’m not used to that anymore from Python. 

 

Mark: Yeah. And BlueJ also has a command line option. You can open up a read-evaluate-print loop in BlueJ, and then I use DrJava because I really love it. 

 

Kristin: Your comment about having the REPL command line thing for the language tickled my brain a little bit, because–so–in my class, I guess I technically, you could almost say, do two kinds of live coding. One kind is in a file where I’m implementing a function. 

 

Mark: Yep. 

 

Kristin: And another kind is where I’m on the command line and I’m just demonstrating what different things are doing. So, usually it’s not an if statement that I’m dealing with, I’m more dealing with some kind of data structure; showing the students what happens when I create a string and call a function–a certain function on it, or I had–I make two sets, and I start manipulating these sets. Would you call those–is–is one–should you do both? Is one better than the other? Is there a benefit to them? Is it better to always do more your–kind of what it sounds like–your style of: implement some code that’s kind of your initial attempt at creating some function? Like, what are your thoughts on that?

 

Mark: Well, that’s a great question. Let me try to give it some thought. So, I’m obviously going to be talking and thinking at the same time, so stop me if this becomes incoherent, please. So, the–the work at the command line I think is really important. And part of the reason why it’s important–the demonstrations, the kinds of things that you were just describing–because, especially, intro students hate debuggers. You’re–right? Your–probably, you’ve seen this, that intro students, if you can get them to do print statements, and start print statements debugging, you can get them to do that. But to use a debugger is really hard with intro students. 

 

Kristin: Yeah, I don’t–

 

Mark: I think it’s an–

 

Kristin: I don’t even use a debugger for my intro students. 

 

Mark: Sure. But some people have, and it’s really hard to get them to do it. And I have some theories about the–the challenge of cognitive load, and the debugger is another system, and, “I’m just trying to understand this Java or Python thing,” adding the debugger in, is just too much load. But I think that when you’re demonstrating things at the command line, you are helping students think through: how do they understand the–the execution of their system? How did they debug at that print statement? Kind of level. So, I think that’s a really important thing. I think that the coding from the function, I think is also really important, if you iterate. And so, don’t just say, “Here’s my function. Isn’t this a nice function?”

 

Kristin: Yeah. 

 

Mark: “Here’s this function. This is how it works.” Now this part could be done differently. “Let me show you another way that it could be done. This way–new way that I’m doing it–is actually better than the old way. Let me explain why it’s better than it–or even better. Let me demonstrate why it’s better than the old way.” I think that the–the–the coding from the function level gives you the opportunity to–to explore a space, and to help students see the various options, and why you did what you did. And like I said, one of the main reasons why you do live code, is to model process. And model process should also include iterating on your code, refining your code, debugging your code figuring out, “Oh, that wasn’t the best way of doing that, there’s a better way of doing that. Let me try that.”

 

Kristin: Yeah, I think, as the teacher, in some ways it’s hard, because you have so much more experience, that you very quickly iterate through a bunch of things. 

 

Mark: Yep. Yep, completely agreed.

 

Kristin: And sometimes it’s so fast you can’t even capture the phases that your brain goes through. And so, even if you can capture it, forcing yourself to go through that in front of the students, is almost like an extra level of scripting that you have to do for your lecture to force yourself to do that. 

 

Mark: Yeah. And the–the technical term for that is expert blind spot. 

 

Kristin: Yeah.

 

Mark: Because you have such expertise, you have a great deal of implicit knowledge, and you bring that to bear, and you can’t–you’re not even aware of it, there’s no way you can be aware of it. It’s literally below your consciousness. 

 

Kristin: Yeah.

 

Mark: So, I think this is why it’s important to still do things like peer instruction and predictions, so that you purposefully stop yourself, so that you purposefully engage the students, and make their thinking process evident to you. I first started doing peer instruction in 2011, and actually know when it was, not just because Beth Simon beat on me for a long time to convince me to try peer instruction. But because I was already blogging then. I’ve been blogging for about a little over 10 years now, I think. And so, I have the initial blogs–where I think my title was–titles were terrible–were things like, “My students don’t know what I think they know.” A lot of the peer instruction was what I thought was the no-brainer, softball questions, and the students weren’t getting them right, and I realized I don’t really understand their mental model. So, same thing with a live coding. It’s easy just to say, “They get caught up in it. You’re an expert. You’ve coded before. Ooh! Got that error! Bam, slam, get out the way! Keep going!” But that’s where the students get lost, and so it’s important to put in those pauses with peer instruction, with making predictions, so that students think about what you’re doing and what they need to be doing. 

 

Kristin: Do you do anything with, say, some pre-code planning. So, something that I do–so here at Duke we have this thing called the Seven Steps and it’s not–

 

Mark: Not twelve steps.

 

Kristin: Not twelve, seven. 

 

Mark: Got it. OK. 

 

Kristin: It’s created by Drew Hilton over in the ECE (Electrical and Computer Engineering) department, and it’s not research backed yet. I am interested, actually, in starting to better understand and research what these steps mean. I think that the steps need some more refinement.

 

Mark: Okay.

 

Kristin: But the first four steps are all about outlining your code. It has nothing to do with writing code. It is actually just outlining: What are the steps that you need to do to be able to solve the problem?

 

Mark: Okay.

 

Kristin: And I literally tell the students, “These steps about outlining, just like you write an outline for an essay, you need to write an outline for your code.” And for my live coding–what I try and force myself to do is to have the students go through using a Think-Pair-Share, which is a different kind of peer instruction, and think through: what are those steps that you need your code to do? And I will have them share with me what, like, “Who has step one? Like, what do I do next? What do I do next?” And I write it out as comments in my code, or more like comments in the function, and then I start writing the code after we have all agreed that these are the things that we need to do in this function. Is–do you think that’s beneficial? Like, do you think–do you do something similar?

 

Mark: Do you–have you read How to Design Programs? MIT Press? Matthias Felleisen? Shriram Krishnamurthi? Gang of tons.

 

Kristin: I don’t think so. 

 

Mark: I highly recommend it. 

 

Kristin: Okay.

 

Mark: It’s their–they–they have a really interesting take on how to get students started thinking about both programming, and the process of programming. So, you can also– so, they’re the folk–folks who did Bootstrap. 

 

Kristin: Okay.

 

Mark: So that’s, Shriram Krishnamurthi, Kathi Fisler, and Emmanuel Schanzer, and it’s part of Bootstrap, too, and in their new stuff–the–both Bootstrap Algebra and the–now their new work with Bootstrap Python, and Bootstrap data science, where students are asked to write down examples, “What should the input and output of this code look like?” 

 

Kristin: Yep. 

 

Mark: “What do you expect to happen before you start writing the code?”

 

Kristin: Yep, that’s step one of the seven steps, actually, do an instance. 

 

Mark: Yeah, so it’s there. They make a distinction between writing examples and writing tests. And–and I agree with that–the distinction they’re making. Building a test is really grounded in software engineering and can be pretty complicated to think through what the right assertions should be. I mean, I think it’s a valuable skill, I’m all in favor of having students build unit tests, particularly computer science majors, having them build unit tests before they’re building their code. But at the very simplest level, to write down the example, and in some sense it’s–it’s activating a similar kind of knowledge as the predictions. “What did you think was going to happen here? Oh wait, it didn’t happen that way.” So, you write down the example of what you thought your code would do and now it does something different. And now you have to ask yourself, “Which is wrong? My example, or my code?” And it could be that your example was wrong, that you–you miscalculated what was supposed to happen, you hadn’t thought through the design well. So, I think that those sorts of processes are important. 

 

Kristin: Sorry, I lost my train of thought. 

 

Mark: No problem, we were talking about your seven steps. 

 

Kristin: Oh, yeah.

 

Mark: And getting students started. And what’s the role of the pre-coding activities?

 

Kristin: Okay.

 

Mark: I think it’s–this is actually for me a hot area of research, I have students who are exploring, right now–so, what does it mean for a student to understand their code? How do they build a mental model of what’s going on with their program executes? In computer science education research, we talk about a notional machine. 

 

Kristin: Yeah.

 

Mark: How do you teach kids the model of how to think about their program, even if that model is not one-to-one with how the program’s actually working? But it’s–it’s a way of thinking about it, it’s leading students towards a mental model. And I don’t think that people can really learn–develop a mental model of the system without actually engaging with the system. I think there’s only so much that you can do before you code–even more probably–before you see code execute, to really develop an understanding. So, this actually brings up a really interesting point that I’d like to make about both live coding and tracing. 

 

Kristin: Okay.

 

Mark: You don’t want to do it all the time because it incurs a huge cognitive load. 

 

Kristin: Oh, yeah, I agree there. 

 

Mark: I mean it’s a cognitive load, also, for both the teacher and the student. When I taught the class in the fall, the User Interface Software Development, I simply could not live code in front of the students. There are people who can, I’ve seen other faculty here at the University Michigan, Walter Lasecki and Mark Ackerman, who can do that live in front of the students. But when you think about front-end web design, and the HTML is here, and the CSS is here, and what was the name of that div anyway? 

 

Kristin: [laughter]

 

Mark: And what class did I declare in the CSS? And then I’m coding that all in the JavaScript.

 

Kristin: Yep. Yep.

 

Mark: I just can’t keep track of all of it. And for the students as well, I mean, the students don’t have your implicit knowledge. So, when you throw five variable names out at them, you know, working memory is seven plus or minus two. You filled up most of their working memory by throwing out five variables. And for you and I, oh, sure, I is always an index, I don’t even have to think about it. Well for them, they don’t know that yet.

 

Kristin: Yep.

 

Mark: So, they’re kind of, “Crap, there’s I, and there’s T, and there’s count, and there’s sum, and there’s A, and aah!”

 

Kristin: Yeah.

 

Mark: So, you have to be cautious with the live coding not to overwhelm them. And you know that tracing code is a huge cognitive load. “Where am I right now? What’s my program counter? What are the state of all the variables?” So–

 

Kristin: That’s why scratch paper is so important. 

 

Mark: I completely agree. But then, isn’t it interesting that the students don’t do what the teacher does?

 

Kristin: Yeah.

 

Mark: So, what I did in the fall when I was teaching this class–that I simply didn’t have the cognitive capacity to do the live coding for–I developed a technique I called Inverse Live Coding.

 

Kristin: Okay.

 

Mark: And I think it gets to some of your seven steps ideas. So, what I would do is I would write a program of the HTML-5, the CSS, the JavaScript on my own. 

 

Kristin: Okay. 

 

Mark: I’d come to class, I demonstrate the program, I’d explain the working of the program and what the critical pieces were, and then I’d have the students pair up–and I’d give them the code–and I’d give them a challenge of one of three things to change to the code. 

 

Kristin: Oh! Okay.

 

Mark: And I’d only give them about 10 minutes, so it was basically like a peer instruction question that I was dropping into the class. And I call it inverse live coding because it’s not me doing a lot of coding, it’s them. And one of things that I found, which was really surprising to me–like when I first did peer instruction–is the kinds of questions that came up, that I wouldn’t have even thought of answering, of putting in my live coding. So, like one student said, “Okay. So, I’ve modified the JavaScript to do the thing that I–that I need to do. How do I compile it now?”

 

Kristin: [laughter]

 

Mark: You don’t compile it. That’s not how JavaScript works. But you could imagine a student, working on their own on a homework assignment, and not knowing that bit, not knowing that small insight, and spending hours trying to figure this out. You could imagine! You’re trying to go hunting on the web for: how do I compile my JavaScript? Well, you don’t!

 

Kristin: I wonder what the internet would say if you Googled that?

 

Mark: I think that’s a great question. So, I think that Inverse Live Coding is another way of having students learn about process, make mistakes, and see how they get fixed; and to create opportunities for making predictions, because they are trying to solve it. But they’re doing it in a context where there’s me and my teaching assistants wandering the room to answer those sorts of questions, and they’re working in pairs–which we don’t always allow in the programming assignments–by working in pairs, they have somebody else to help with. 

 

Kristin: So, that sounds like at least half the students, if not more, have their computer open in front of them and they’re working on something. Are you–how–how do you control getting off task?

 

Mark: I have so many peer instruction questions that they don’t. 

 

Kristin: Okay. So, it’s literally just–

 

Mark: Actually–

 

Kristin: A barrage that they just can’t really get off task. 

 

Mark: Yeah, I mean, I don’t–I try not to lecture for more than 10 minutes before a peer instruction question, maybe 20 minutes, but in a 50-minute period I’ll have three to five questions. And my teaching assistants always hang out the back of the room, and they tell me, “No, there’s not that many people were wandering off during the lecture part,” because they know they’re going to get a peer instruction question pretty quick on whatever it is that I’m lecturing on. And it’s pretty hard for you to go off task when your partner is asking you to help in answering this question. So, the peer pressure helps too. So, yeah, I–I also set expectations in the beginning of the class that, you know, I’m–this isn’t about the time to do Facebook, Twitter, Slashdot, Reddit. And I don’t want them using their laptops for other than that. At the same time that I give the talk on defensive climate, that I don’t want students asking questions where they don’t really want the answer, instead they want to demonstrate that they know some technical bit that nobody else knows and that’s why they’re asking the question.

 

Kristin: Yep. 

 

Mark: I think live coding actually can fall into the defensive climate trap, easier than other kinds of teaching methods. “Yeah, so what if you did an arccosine there?” Or, you know, “Sure, you did the constructor there, but couldn’t you do a destructor and to achieve the same?” I mean–

 

Kristin: Yeah.

 

Mark: And it’s easy for you to say, “Oh, that’s interesting maybe we’ll try to code that.” No, don’t! Don’t go down that deep end of technical detail that the rest of the class doesn’t know about, or care about, and make some people feel like they don’t belong. 

 

Kristin: Yeah.

 

Mark: So, yeah. So, I–I set the expectations for how to use the laptop when I set the expectations for defensive climate, and then I’m cautious about defensive climate when I’m doing live coding. 

 

Kristin: So, for–for the peer instruction, do you have any techniques to kind of get the students to actually work together? Because I have–I have some techniques of my own to get students to want to talk to each other. But I’d love to hear what yours are.

 

Mark: So, I use the peer instruction protocol–and you can google peer instruction protocol–I don’t know who made the picture first, but I’ve seen Beth Simon and Leo Porter and Cynthia Lee show it, probably dozens of times, and I actually use their process. So, the first–you put up the question, and then everybody must vote individually. 

 

Kristin: Yep.

 

Mark: And that’s a critical part, because that’s essentially making a prediction that’s getting everybody to prime their–their prior knowledge, and to make a commitment to what they think the answer is. I then have people break up into groups of two or three, and I explicitly give them a prompt, like, convince the person next to you that you’re right and they’re wrong. 

 

Kristin: [laughter]

 

Mark: And then I ask that. And during that time, that’s when I’m floating around the room, the TA’s are floating around the room, we’re both answering questions; but also figuring out what are the–what are the things that people are getting wrong? Why are people getting seduced by the distractors? And so that–then when–when I take that, I take a second vote and I ask the groups to vote in consensus. That requires them to vote in consensus. I don’t require them, but I encourage them to. But I accept that there will be minor minority views. So, they vote the second time, and then I show the histogram of how people voted, and I explain the right answer, and get people to explain why they voted the answer they did. When I did this in my User Interface Software class, it was great, and then everybody was convinced they were right. And so we’d have great discussions about what the subtle differences were between the different options, which really led me–this was a, you know, 493, it’s an upper-level senior course–I on purpose started putting in peer instruction questions that were ambiguous, or there’s arguably more than one right answer; because the discussion was–was what I really wanted anyway. 

 

Kristin: Yeah.

 

Mark: And so, I think that really–that really worked. One of my favorite responses that I got in the teaching evaluations–this is sort of surprising–I got, you know, 120 people in the class–I think I got like 95, teaching evaluation, something along that, which is pretty good. 

 

Kristin: Yeah, it’s pretty good.

 

Mark: About a dozen people mentioned the peer instruction, and I didn’t prompt that. And one of the things that I got as comments was, I was more likely to ask my peers for help, because I had talked with them in class, which I’d never thought of before. That there is an impact on help-seeking behavior. So, I thought that was pretty cool. So–so–so, they’re talking to one another because I’m going to require a consensus vote, because I’ve challenged them to convince the person next to them that they’re wrong. I found that, at least here at Michigan, they’re pretty combative anyway. 

 

Kristin: [laughter]

 

Mark: “I’m right.” And it tended to get people to start talking about what they understood and didn’t understand with each other, which was a huge benefit. 

 

Kristin: I’ve never thought of–I do have, in their groups, some questions that they should be asking, discussing like, “Why is the right answer right? Why are the wrong answers wrong?” To try and get them to start talking, especially if the group already has consensus, and some, like, discussing why the wrong answers are wrong, just to kind of get you to keep talking. I had never thought of–

 

Mark: Yep. 

 

Kristin: The–the comment of just saying, “Convince your–your group that you’re right.”

 

Mark: Yeah. 

 

Kristin: I might–I think I’m going to steal that one. I think I’ll use that one. 

 

Mark: I am sure that I stole it from Beth, Leo, and Cynthia, so I highly encourage you to steal it. 

 

Kristin: So, I am curious of one thing, and then we’ll–we’ll go on to our next segment, which is: during that interaction, one-on-one, while you’re floating around and the student groups are discussing, and you’re trying to understand why the students are crowding toward gravitating towards a particular destructor, do you also steer them towards the right answer during that interaction? 

 

Mark: I might.

 

Kristin: Right, so–

 

Mark: I mean, I have certainly done that. 

 

Kristin: –not necessarily. 

 

Mark: Yeah, not necessarily, especially if it’s a–if it’s a code-based one. Because I might encourage them to actually try it, and to point out where the behavior of the code might be different than what they expect. So, I might not tell them the right answer, but I might say, “Have you thought about it like this?” 

 

Kristin: Ah, okay.

 

Mark: Or, “Think about what this code does.” I have to point out–I have to sort of fess up here–there is one more thing I do to get students to talk to one another. 

 

Kristin: Oh? 

 

Mark: Which my wife has pointed out–Barbara Ericson has pointed out–that I can get away with it because I’m an old, white dude. 

 

Kristin: [laughter]

 

Mark: But not everybody can. And so, I don’t recommend it to everybody, but–so, if I have a student who’s sort of a lone wolf sitting off by themselves–

 

Kristin: Yep.

 

Mark: –Because I tell them, beginning of the class, “Make sure you’re next to two or three people, because I’m going to be asking you to discuss in small groups.” 

 

Kristin: Yep, yep, yep.

 

Mark: If they’re sitting by themselves–this usually happens a couple of times the beginning of the semester–I will walk up to them and sing–

 

Kristin: [laughter]

 

Mark: –in a loud voice, “You’re all alone, there’s no one near.” 

 

Kristin: Oh, I love that!

 

Mark: They are embarrassed. I’m embarrassed. It’s cool. It’s all right. It doesn’t happen very often. Then, as soon as they see me walk toward them, they start sliding over and go talk to somebody. 

 

Kristin: Oh, yeah, that–you can only do that if you’re both a good singer and also ‘cause you’re an older white gentleman. So–so, my technique is: I will sit next to them.

 

Kristin: And go, “Hi!”

 

Mark: Uh huh.

 

Kristin: “What’s your name?”

 

Mark: Ha! That’s great!

 

Kristin: And then they tell me their name, and then I turn to the closest person and go. “Hi, what’s your name?”

 

Mark: Oh, I like this.

 

Kristin: “John? Well, I’d like you to meet Mary. Mary, meet John. How about you talk about the answer to the question?” And literally I do–I do it all only like, I’m the one being awkward and I’m perfectly fine with that, because I want you two to talk to each other. 

 

Mark: That’s really nice. I really like that, Kristin, I’m going to steal that. 

 

Kristin: Yeah, and it’s–it’s–it’s not as public. In some ways, I wish I could do something that public, because then it would be much easier, but I think the students after a while start figuring out that like, if I’ve sat next to them, it’s like I want you to do something. 

 

Mark: Yes, yes. Yeah, that’s great. I like it. 

 

Kristin: Alright, so, let’s get on to our next segment. Our guest is going to share whatever they think is something awesome in computer science, but maybe not necessarily as well known.

 

Mark: So, I think, that what is awesome about computer science is that it can be anything else. 

 

Kristin: Okay.

 

Mark: So, you saw The Imitation Game? The movie? That Alan Turing– 

 

Kristin: Alan Turing’s movie, yes, I have seen that. 

 

Mark: Yeah. So, you know that there’s–there’s the–the title Imitation Game is–is working at–at multiple levels. And at that really deep computer science-y level, we know that what’s going–that one of the things that’s going on is that a universal Turing Machine can be any other Turing Machine, that you can simulate anything else, any computer can imitate, simulate another computer. And this idea, that computer science can look like, and behave like any other discipline, is really something deep and important. So, I’m really swayed by this argument that Shriram Krishnamurthi and Matthias Felleisen have been making. I didn’t, at the time, when their paper came out–their title Why Computer Science Doesn’t Matter–really annoyed me.

 

Kristin: [laughter]

 

Mark: And then I realized, “Oh, they are so right.” You know, that in the end, you know, people don’t get into, or don’t get into college, because they didn’t take intro computer science. It is the case that kids who don’t pass Algebra 1 rarely get into college. If we can use computer science to make Algebra 1 work better, because computer science can become algebra, and then learning the computer science, learning the programming, learning that environment, is learning algebra. That’s more important than them learning computer science. And so, that’s–that’s really the focus of my research now at Michigan. I’ve really tried to make a turn in what I’m doing, which is a little scary to do at my age–see previous comment about being an old, white dude.

 

Kristin: [laughter]

 

Mark: But I’m–I’m really trying to focus on: where can I use programming to make learning something else better? So, I’m working with folks in pre-calculus. Pre-calculus, we know, is actually really critical for kids to succeed in calculus and a STEM major. And we don’t teach pre-calculus very well, it’s a very abstract concept. But, you know, things like vector and matrix manipulations, and sequences, and trigonometric functions? Hey, on a computer we can make those pretty darn concrete. 

 

Kristin: Yeah.

 

Mark: And then, I’m working with two different history professors, because history professors today–the one that I’m working with, Tammy Shreiner, is really interested in having kids understand data and data literacy. She found that in history textbooks, there are graphs and visualizations, very often, in both middle school and high school textbooks. And then she did these Think-aloud protocols and finds that students just basically skip them.

 

Kristin: Oh.

 

Mark: They just turn the page. And when she makes them look at them, they can pick out all the features of the graph, “Oh, there’s these axes, and there’s this slope, and there’s this intercept.” And then when she says, “Well, what does it mean? It’s in this history book. What–on that page, with these variables–what does it mean?” They really get lost.

 

Kristin: Oh.

 

Mark: And so, she realizes they need to engage with data in a different way. And we both agree that programming data visualizations is one way of having that happen, and it’s–it’s–it’s important. You know, it’s really important for kids to be able to understand the use of data, how visualizations are constructed, and how they can use visualizations for understanding things in the world. 

 

Kristin: Yeah.

 

Mark: I’m working with another history professor, Bob Bain, who’s really interested in having kids think about what evidence they bring to bear to make an account of a historical situation.

 

Kristin: Okay.

 

Mark: And that–that bear–that considering different kinds of evidence, and thinking about uncertainty, and thinking about where–how evidence chains together to make an argument, that looks a lot like a logic program to me, that looks a lot like Prolog. And so, we’re trying to think about: how do we support that kind of a process? So, these are both places where, you know, if we can get programming into a world history class, everybody takes world history. 

 

Kristin: Yeah.

 

Mark: And now computer science, some notion of programming, becomes evident to everybody. And maybe we can make students learn about history, about data, about pre-calculus in a new way–a better way than before. 

 

Kristin: Alright, let’s close out. And so, as we close with our last segment–it’s called TL;DL, Too Long, Didn’t Listen–what would you say is the most important thing you’d want our listeners to get out of our conversation?

 

Mark: Live coding is really useful, but it’s one method among the many, and it’s not even the most important one. It’s really important for demonstrating process, and for explaining mistakes and how you deal with mistakes, and in terms of creating opportunities for prediction. But if I were to list what’s in my big bag of CS teaching methods in declining order of importance the top one is peer instruction. The second one–I’d call it contextualized computing education, but in broader terms, start from a problem. If you ever start writing a program because, “I need to demonstrate int (integer) and float to you.” Eh!

 

Start out with a problem where you need int and float, and then you can write a program for that. But you’ve got to start out with the problem that the students engage with. I believe a lot–and using low cognitive load practice, like Parsons problems–pair programming is your friend, and then live coding. 

 

Kristin: Nice. Alright, well, thank you so much for joining us today, Mark. 

 

Mark:  It was a real pleasure. Thanks for inviting me, Kristin, this is a blast. 

 

Kristin: Alright, so, let’s close out. Thank you so much for joining us, Mark. And this was the CS-Ed podcast, hosted by me, Kristin Stephens-Martinez, at Duke University, edited by Susannah Roberson, and funded by a SIGSCE special project grant. And remember, teaching computer science is more than just knowing computer science, and I hope you found something useful for your teaching today.