S1xE5: Massive Online Open Courses (MOOCs) with Armando Fox
In this episode, we talk with Armando Fox, Professor of Computer Science and Faculty Advisor to the MOOCLab at UC Berkeley. With David Patterson, he co-designed and co-taught Berkeley’s first Massive Open Online Course (MOOC) on “Engineering Software as a Service,” offered through edx.org. It is now a professional certificate in “Agile Development Using Ruby on Rails.
Our conversation touched many topics involving MOOCs. We discussed the history of MOOCs, how he got into it, creating Small Private Online Courses (SPOCs), how MOOCs call into question established teaching habits, some experiments he’s planning that break those habits, and how to get student buy-in when using a MOOC in the classroom.
When asked about something awesome in computer science, Armando talked about his love for the history of computing. One thing he observed is how much ideas get recycled in computer science. He even has a web page called “Master geek theater” of his recommended documentaries ranging from five minutes to three hours.
Armando’s Too Long; Didn’t Listen (TL; DL) focused on MOOCs’ long-term legacy. He does not think they will replace instructors. Instead, they will enable instructors to use their time more creatively because they have well-curated, interactive, battle-tested exercises available to them. Moreover, they will help us think about how to get the non-deep content experts involved in helping the students or their peers in learning the material.
You can also download this episode directly.
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 Armando Fox, from UC Berkeley.
Armando: Hi!
Kristin: Armando, tell us about yourself; and what do you teach? How many students do you have?
Armando: I have only a few active grad students right now, in part, I think, because I just returned from a sabbatical. But my research in the last few years has really pivoted towards computer science education, and in particular, whether there are interesting things we can do with technology to support what teachers are doing. And that’s something you’re going to hear me say a lot, I think, during the podcast: support teachers, not replace teachers.
Kristin: Definitely, I totally agree. What about classes? What kind of classes do you teach, and how many students are in your classes?
Armando: So, at Berkeley, my software engineering course, which is aimed at juniors and seniors–it’s almost a boutique class by our standards–last semester I only had 120 students. It has been as high as 240 students. But, by the standards of Berkeley’s computer science, that’s still barely medium-sized. A lot of our upper division classes are now routinely over 500 students. But, one of the things that I hope we get to talk about is a little bit about what scaling means, and sort of what we’ve learned about it from what’s happened in the last few years. I also teach a class that focuses on computer science pedagogy that’s aimed at graduate students–and some undergraduates–who are going to be what the rest of us would call teaching assistants. They’ll typically lead one or more sections of students in conjunction with a large lecture class–and that used to be a very small class, but the last couple of times I’ve taught it we’ve had 80 to 100 students–and that’s not even counting a secondary class we’ve added that is for student instructors who are not going to be leading sections, but have other instructional roles. For example, they might be lab teaching assistants, or office hours tutors, any number of things like that.
Kristin: So, our main topic was using MOOCs (Massive Open Online Course) in the classroom, and I feel like you’re probably one of the people that makes the most sense to talk about this because of your discussion of this, all the way from when MOOCs were first kind of–became the year of the MOOC, which was 2012. So, I’m–so, for a bit of context: I’m teaching Foundations of Data Science, and so I’m basically borrowing as much as possible from Data 8 at UC Berkeley, and my plan is to use–and I’ve already gotten copies of the MOOC edX courses from John DeNero and everyone at Data 8–and then I’m going to curate a little bit from my own class. And it’s gonna be a flipped classroom using the book, and so, I’d love to talk about the pros the cons the gotchas I should pay attention to–to make sure I can make this as smooth as possible.
Armando: Sure. So, I think–just a very brief sketch for the benefit of listeners who don’t know the whole story–but you’re right, pretty early on in the so-called Year of the MOOC. David Patterson is my sort of senior mentor and computer science hero. He and I were, at that time, co-teaching the software engineering course and demand for the course, like all of our CS courses, was continuing to go up; so we had already sort of been thinking about what we could do to bring technology to bear to serve more students in the course. And so, when MOOCs kind of happened, it seemed like a natural extension of an experiment that we were sort of already undertaking. We were also in the middle of writing a textbook because we–we thought the textbooks for this subject matter weren’t terribly impressive, and we thought, you know, “Here’s an opportunity to actually try this very different format, and see what we can learn about classroom teaching from trying to reach, you know, tens of thousands of students.” I think at this point we’ve reached over a hundred thousand or some number that I’ve just kind of lost count of. And, you know, at Berkeley–
Kristin: So, I just realized, real quick, sorry Armando, I realized we didn’t spell out what MOOC stands for, which is probably something useful, because there are still people who don’t know what that stands for. So, MOOC stands for Massive Open Online Course, and it’s meant to be a course that’s potentially freely available. Though it kind of depends on the model nowadays, compared to when it was first coming out in 2012.
Armando: Yeah, we could have a whole discussion on cynicism about the model of where – Where has free education for all actually got us after five or six years? But I think, if you think of the word open in Massive Open Online Course as referring not to the fact that it’s free of charge–which it may or may not be–but to the fact that anyone can enroll. There’s no admissions or filtering process, anybody–you can sign up for the course, which is obviously not the case on most campus courses, right? Most campus courses you either have to be an enrolled student to even have a chance to enroll in a course, the course may be restricted enrollment or limited enrollment. Not all campuses allow students who are not matriculated in–in a degree program to enroll in their courses. So, I think the real sort of qualitative change about MOOCs was openness in the sense that anybody at all could sign up.
And you know, that’s–that’s got pros and cons as well. But going back to, you know, how this experiment got started, what we–we learned from it. What we sort of realized early on is that, at the time, you know, the MOOC honeymoon had just begun; and you were hearing about courses that enrolled fifty thousand, one-hundred thousand students. We had no idea how many we were gonna get. But we wanted to be prepared. And it was very obvious early on that if you can build something that is robust when ten thousand students or fifty thousand students are using it, then it will work really, really well for a couple of hundred students in the classroom. So, you know, sort of one very basic, you know, MOOCs in the classroom 101 is that: you tend to end up with much higher quality materials, because they have been battle tested–not just in terms of the technical correctness of, you know, your programming assignments, or your automatic-graders–but is the language that you used confusing? Are there parts of the problem that are systematically, you know, screwing students up because you didn’t, maybe, cover the material in sufficient depth? So, things like that become obvious right away.
We put–I don’t know how many–thousands of engineering hours into our auto-graders–but you know, now it’s sort of a given that of course you should do that, because auto-graders never get tired of grading. And students can have multiple attempts–which, you know, we know that repeated practice and being able to get instant feedback and try again is generally a boon for students who are having a little more trouble with the material. So, those advantages, I think, those were the ones that we sort of saw coming. You know we–we worked hard to–to make sure the course would be robust. I think we did a reasonable job of that, and it was well received. And indeed, you know, we ended up with high quality courseware that was debugged, and it was, you know, serving our students really well.
I think the part we didn’t expect–which was a sort of happy bonus–was how interested other instructors were. A large number of students in our first cohort, when we offered the course on EdX. were actually, themselves, computer science teachers, usually at the college level, and a number of them reached out and said, “What could I do to use these materials in my classroom?” Which was great, and it’s not something that we expected to happen. Although, in retrospect, it should have been obvious, right? You have a well-debugged set of assignments and you have, you know, video lectures that were reasonably close to matching the material. So, that was kind of what led to this op-ed that Dave and I wrote, that I think if you Google “From MOOCs to SPOCs”–we invented this acronym SPOC for Small Private Online Course. And what that was intended to capture is: an instructor who takes advantage of a set of well-developed MOOC materials, but adapts them in various ways for use in their own classroom. And so, it’s really not a self-service course from the student’s point of view, it’s facilitated. And that’s really the model–that once we saw that, we realized that actually, the biggest positive legacy of MOOCs in the classroom might be that. That the instructors are now freed from having to develop their own materials. And, you know, since you mentioned you’re gonna be using a lot of the Data 8 materials, which have–you know–have been–have had thousands of engineer hours invested in them–Presumably, that’s going to leave you with that teaching time to do other things.
Kristin: That’s the hope, at least.
Armando: That’s the hope. But that’s actually how it’s worked for us. And you know, I think one of the tests of that is: if you believe that this model of facilitated SPOCs is a good model, it implies that the course materials are in some format that can be handed off to an instructor, so that an experienced instructor can sort of take it from there, right? As you’re planning to do, I think, with Foundations of Data Science. And indeed, during the last couple of years, there’s been two or three occasions where some instructor, other than me, has run the course largely off of our materials, and they’ve been very successful at it. Certainly, judging by the student evaluations. So, that’s a kind of a model of pedagogy that–that maybe we didn’t foresee, but we’re pretty excited about.
Kristin: So, what–are there any cons that you can think of for using a MOOC in your classroom?
Armando: I think so, and I think, to answer the question, I’m going to sort of reframe the question a little bit. Because I think one of the other things that MOOCs have sort of awoken us to is that: it’s caused us to question some habits that we’ve sort of always had. Things that we do because we’ve always done them that way. You know, you’re probably aware–or, I don’t know, maybe you’re aware–that the reason that a semester course is about 14 weeks long is that: that enables you to have two semesters, with a break over the winter holidays, and have the students out in time to harvest the fields.
I mean, that’s really where the tradition comes from, you know, it comes from Oxford and Cambridge, through Harvard. We have 14-week semesters because Harvard has them, and Harvard has them because Oxford had them. That’s really the reason. So, I think, besides helping us think about, well, you know, “Should I really be thinking of my 14-week course as three, four, or five-week courses? Are there really logical dividing points?” Because sometimes, you know, some of the students, especially the ones who are not obligated to a 14-week semester, might not be interested in all 14-weeks of material. The gaps that they want to fill might be shorter than that. This is one of the reasons that I still sort of roll my eyes when I hear people being concerned about the attrition rate of MOOCs, how few students actually finish them. There’s a lot embedded in the assumption that they should finish them. I’ve dabbled in dozens of MOOCs, but I’m not sure that I’ve ever finished one, because I don’t really have an incentive to do so. I’m not enrolled for a grade; I don’t get a reward. I just–I’m in it because I want to learn specific material.
So, I think in this category of, you know, breaking habits, I think if you try to sort of shoehorn a MOOC into a classroom setting, and do everything else the way you’ve always done it, one possible bad result is, you know, students stop coming to class; because they figure that if the materials are really all online, and they form the basis of a course that is otherwise self-service, maybe they’ll just cram. You know, that–you need to really give them a reason to come to class meetings, I think, especially if you’re doing a flipped classroom. We have talked about doing a flipped classroom at Berkeley, and the reason we didn’t is that we decided that the small sections led by a T.A. kind of serve some of the purpose of the flipping. It’s just that the flipping is from the students coming to lecture. And yeah, we have definitely seen some attrition in lecture attendance when we make the videos of the lecture available. I try to make the lectures engaging and, you know, I sprinkle them with anecdotes and computer history minutes, which is one of my sort of nerd topics that I like. But at the end of the day, you know, I do find myself wondering more and more whether there’s really a strong reason to continue to have live lectures at all. In fact–last semester, I think it was–last semester, for the first time, we ran our upper division databases course, which again, very high demand. You know, typically, enrollments are four to six-hundred students. Joe Hellerstein, who has owned that course for the last few years, spent a great deal of time doing very, very high-quality video segments to follow his syllabus. And we offered the course in a format that there was no live lecture, but everything else was the same. So, we still had scheduled weekly T.A. sections, there were still synchronous exams taken in a big room with pencil and paper, for better or worse. The only difference was no live lectures. And by all of the metrics that we used to measure how well the classes are going, it went about as well as when Joe was teaching it in person. He was still available for escalations. I think he–he had some sort of special office hours a couple of times during the semester. But I think we’re–we’re trying to get towards a model where: rather than doing everything we’ve done the same way, and then asking what happens if we add MOOC-like ingredients, we’re actually asking how the availability of the ingredients should make us think about just changing the format.
And, I think another example of that is once we realize that, you know, at Berkeley we’ve never had to consider what happens if you have more than sort of a few hundred students in a class. In the MOOC, we had thousands, and the good news is that the programming assignments and auto-graders and all the other stuff worked quite well, even at that scale. But, the classroom version of the course also has a team project, and those team projects are–every team project is different–it is instructor intensive, in terms of the amount of mentoring the instructors have to give the students, and clearly that aspect of the course is gonna be much more difficult–if it’s even possible–to scale it up to that level. And it’s certainly going to require a different approach to scaling, right? You can’t sort of auto-grade these projects that are one-offs. So, I think another thing that–that combining MOOCs with a classroom has made us think about is: how do we separate the scalable from the non-scalable, or less scalable, elements of a course? And maybe even consider offering them a separate course numbers. You know, the scalable part can be offered on an ongoing basis, it doesn’t necessarily need a live lecture every time it’s offered. It can accommodate as many students as want to take it. And then, there’s another section that is more difficult to scale. But that’s–you know, we sort of transfer the instructor effort, to be able to offer more sections of that. And in fact, we’re changing the format of my software engineering course starting this coming spring to do exactly that.
Kristin: Oh, really?
Armando: So, we’ll see how it goes. Yep, there’ll be a three-unit, non-project section that will have no enrollment cap; and there’ll be a project section which will require you to have demonstrated that you have mastered the material in the non-project section, and that will be taught, maybe, by more than one instructor. We’ll use our instructor capacity to do that instead of using it to lecture three hours a week. We’ll spend three hours a week mentoring student teams.
Kristin: So, are students–when they’re taking the non-lecture version, or non-lecture number of the class–do they have a discussion, or in-person meetings of any kind? Or is it like, if they wanted to, they could just binge through the class and then be able to take the group work one?
Armando: Well, our initial experiment–the class is still going to be synchronous. So, there will be weekly section meetings with TAs, there will be exams that are scheduled, at times that are well known in advance, there will be deadlines for homework assignments–although, the deadlines may be a little more fluid. So, we’re not talking about a course that is entirely asynchronous or self-paced. It will still take about a semester to go through the course, and the students will still have most of the ingredients that go with a synchronous offering, they just won’t have live lectures as one of those ingredients. Now, depending on how that works out, we can imagine going to a format that is even more asynchronous. For example, our colleagues at George Mason University have adopted a model for some of their CS courses that they call the Black Belt model.
Kristin: Ah, yes! Yes, I’ve heard of this.
Armando: Yeah. So, I mean, in a nutshell: the students are taking a course that is largely structured to be self-paced; but they’re in a lab environment where there are tutors around to help them. They’re required to attempt a certain minimum number of challenges in the course per week, and they–when you complete a challenge, it’s like getting a belt of the next higher color. You can advance to the next challenge, but nothing stops them from racing ahead and completing more challenges. And if they finish the course in fewer than the semester’s number of weeks, they get offered a paid position as a tutor to help other students finish the course. So, I think that’s an interesting intermediate model between fully asynchronous self-service and fully synchronous, which is the traditional format that most of us use now. So, I would like to get to the point where we can try that, too. You know, I think a lot of us are still kind of teaching courses the way we’ve always taught them, right?
And I think that the availability of what–what is possible to do with technology is very far ahead of what most of us are actually doing. And we can talk about the–the various reasons for that, but the good news is it means that there is a lot of room for growth and doing interesting experiments.
Kristin: Yeah, I think it’s definitely–we’re hitting a time when we’re like, “Oh right, I don’t have to just copy-paste what was done before,” and try new things instead. Though, as a new faculty, part of me is like, “Change can be good, and these ideas are great, but there’s only so much I can do without overwhelming myself.” And going to ICER , I was like, “Oh, I have all these good ideas now, to do–to change my CS1 class,” and at the same time I’m like, “No. I have–I’m teaching two classes–different classes, for the first time ever–I need to focus on the other class, the CS1 class, is just going to be a copy-paste because, I know how–I know that the quality for that is good enough, and I need to focus on the other one that’s brand new.”
Armando: Yeah, I think that’s a pretty standard pitfall, and I think the thing that is exacerbating it–when we’re talking about using all these exciting new MOOC-y technologies in the classroom–the first time you do a neat new thing in your classroom, it’s kind of a boutique experiment. You know, you build a cool auto-grader, you build–a nifty assignment, or you try a new exam format; but if it’s successful and you want to keep doing it–and your course keeps getting bigger–and you want to keep doing it repeatedly, at some point, it can’t be a boutique thing anymore, right? It has to go from being some TA’s brilliant research-y, janky code, to being something that has enterprise level support.
And, in fact, this is exactly a challenge, right? You know, we built all these homegrown auto-graders from my class and, you know, they’re great. They–they have repaid the effort we put into them. But at this point, maintaining them has become a burden, because the rest of the campus has started to standardize on solutions that have campus-level support for auto-grading; where there’s engineers who know how to use those APIs, who could build stuff, and our stuff doesn’t look that way. So, I think kind of one of the early adopter pitfalls is: you may find yourself innovating something really cool because nobody else has it, but once your idea starts to become more mainstream, you will be sort of stuck maintaining a bespoke system while the rest of the world has moved on. And, you know, it’s kind of like technical debt in your code. You have to just sort of suck that up and decide that you’re going to reinvest in your course and make it work the right way. But, you know, somebody is going to go out there with a pickaxe and try it first, blaze the trail.
Kristin: Yeah. It’s definitely, you know, it’s–it’s that first version. Version One, and then, like, eventually you’ve got to accept that you’ve got it scrap Version One and do it again or do a lot of revamping to make it make more sense. Maybe that could be considered, maybe, a con to when you first start out. It’s more of a–it’s not really a con in the sense that it’s a thing that’s bad, or very–or will always be bad, this something that is part of the cost of being someone that starts out doing something new.
Armando: Sure, if you’re doing it before it has reached widespread adoption, you are going to do some things that are going to be incompatible with the way it ultimately gets done later. And you know, at some point, you’re gonna have to decide what you’re gonna do with that. So. But, you know, I think anybody who tries new technologies, you know, people who started building web sites by hand, right, back in the day? I actually remember when, you know, people used text editors and they hand-coded HTML and then people started using these crazy tools that emitted awful, awful, awful code, and pretty soon, those web sites all became one-offs, right? And they did load slowly, and they’re not accessible. So, I think anytime you’re one of the early users of a new technology, this is a risk. And I think as educators we’re not accustomed to that, right? This is not usually a thing that intrudes on our sense of what the teaching mission is supposed to require us to do. But you know, I think if we embrace technology with the goal of improving our teaching in our classrooms, we’re also signing up to assume some of that risk.
Kristin: So, before we continue, like, move on from this topic there’s something that I did want to ask. So, I’m going to be using a MOOC in my class, it’s gonna be a flipped classroom, and there’s gonna be group work during the class. And remember how when I TA’ed your software engineering class, and you were doing this attempt–I think it was one of your first attempts at kind of–you weren’t flipping the class necessarily, but you were still having the students watch, well the intention was the students would watch the videos at home and then you’d come in, and you were doing these extra kinds of lectures. Do you remember?
Armando: I do.
Kristin: And then halfway through, I showed you the statistics of how very few students were actually watching any of the videos. And you polled the students asking them what do they actually wanna do in lecture. More than half said they wanted you to just say exactly what was in the videos in lecture instead.
Armando: Yep.
Kristin: And–
Armando: I remember that.
Kristin: I was wondering if you could talk more about what happened there, and like how to hopefully not let that happen in like, my classroom. Where the students, for some reason, decide that they don’t want to do group work in class, and they’d rather just have me lecture what the videos already say.
Armando: Yeah. I don’t know that I have sort of a pat answer for that. I think part of what was happening there is, just as we’ve always sort of run classes in a, you know– according to a pretty traditional format. I think students have also gone through their lower division here with the concept of what a lecture is. And you know, keeping in mind, also, for our listeners out there who haven’t experienced, you know, what I call Berkeley Extreme Scale: when you’re–when your lower division, entry classes have a thousand, or even two thousand students, most of those students cannot fit in the lecture hall, even if they wanted to attend live lecture. So, they’re already watching the lectures on video rather than watching them live. And the idea that the live lecture and the video are sort of interchangeable because they’re covering the same material, at least at Berkeley, that’s what they get used to. So, it–it may have been that it was hard to get the students accustomed to the idea that, yes, there are videos, and, yes, there is live lecture, but that they are not interchangeable. The whole point is to do something during the live lecture time that is not in the videos. I don’t think it’s impossible to get them to understand that. But I think I was possibly working against a set of established expectations. Now, I can imagine if you didn’t call the live lecture, “lecture,” if you called it something else like–suppose you called it “lab.”
Or–and suppose that you–you have a format that is very explicitly so un-lecture-like, that from Week 1, it is absolutely clear that coming to lab without having watched the videos is going to be a frustrating experience. I can imagine that that would work. But I think you really have to set it up so that there is nothing that happens during the lecture slot that feels remotely like a lecture. And then you avoid establishing the expectation of like, “Oh, okay. I could come to lecture, or I could watch the videos, but I don’t have to do both.”
Kristin: Yeah. So, I definitely–I’m trying to do that, where it’s very clear that in-class time is not the same as–as instruction-lecture kind of time; where I’m borrowing from team-based learning, where they show up and they have to do first an individual readiness assessments, so they do a very short quiz by themselves, and then they do it as a team, because it’s group–group-based learning as well. And my hope is that this will make it pretty clear that this is not a normal lecture kind of experience, and I was just kind of curious now that it’s been a couple of years since we had, I think–I think you wrote a blog post about that experience, with the students voting that they wanted to just have a lecture be the same as video; and if you had any new insights from that–from having that happen. Because you wrote a blog post soon after, if I recall, talking about what happened.
Armando: I did, and I can probably dig it up if it’s–I don’t know–if it’s Google-able or not. I think my–my evolving thinking on it has led me to where–like I said–we’re gonna split the class into sort of two pieces, you know, the non-project piece and the project piece. But we’re also submitting a petition that would allow us to offer the non-project piece in this modified format, where there is no live lecture, where there are lecture segments but they’re exclusively on video. And there’s sort of enough synchronous deadlines built into the course that students will sort of have to keep up, so that they won’t be able to cram and watch all the videos right before the midterm; because there will have been homework assignments and other intermediate milestones that contribute to their grade. And they would have had to, at some level, be keeping up with the recorded videos just to do that. And like I said, anecdotally, this is what we just tried with the database course and it seemed to work fine, so.
Kristin: Are you going to enable students to be able to kind of “run ahead” until kind of like, I guess, the next exam? So, if they want to get ahead because they knew that the two weeks before the exam, some crazy stuff is going to happen to them, so they need to get material done early. Are you going to let them do that?
Armando: I have no problem letting them do that, and I think what I’ve found is that that’s exceedingly rare. And the students who do it tend to be the ones who are going to do well in the class because they’re really intellectually invested in it, like they really want to learn this stuff.
And they will go out of their way to work harder. In fact, it was just a discussion about this on one of the teaching mailing lists here. Somebody was debating whether they should or should not make the webcasts of their courses available immediately after a lecture. And one of the teachers observed that, you know, it is true that if you do that, some people will think they can skip lecture and cram for the exam by watching all the lectures the night before. But the truth is: those are the students who are probably not going to do well in the class no matter what you do. You know, if you did live lectures all the time, they’d be the students who don’t show up; and you know, if a student is really just not invested in your course, there’s not a lot you can do to sort of, you know, flog them into being excited.
So, I have no problem letting students run ahead. Now, I think that the one thing that one does have to worry about–and this is again in the category of lessons we learned from trying to use MOOCs in the classroom–I think one of the reasons that MOOCs work in the wild is, you know, if you remember in the early days of MOOCs, certainly, a lot of the questions on the forums were being answered by other students in the class, not by the instructor or the official teachers.
And in some sense, I think that system can work well, if it’s carefully stewarded, because it means that in order to be a student instructor–and I’ve got to broadly use that term to mean anyone who is helping a student out, could be another student, right? If you are serving in an instructor-like capacity, you don’t have to be a deep content expert on all of the topics in the course. You just have to be better than most of the students at certain topics.
Maybe this a particular topic–that for whatever reason, that was the topic that was your jam–when you took the course, you aced all the questions about that topic; and maybe the only time that you pitch in and answer questions on the bulletin board is when they’re on that topic. But that’s still very useful.
So, I think having a structured curriculum with, you know, interactive exercises and stuff like that opens the possibility for specialization on the part of student instructors. And I think one of the challenges of running a completely asynchronous self-service course, including one where you let students run ahead of schedule, is that now the demand for which topics are going to be coming up as questions during which weeks of the course all of a sudden opens up. Right? If the course is fully synchronous, then most of the questions in week number two are going to be related to the homework that’s due in week number two.
If it’s self-service where people are running ahead, then you can get questions during week number two about anything; and that calls for a different way of organizing your teaching staff, than if they sort of know, predictably, what the lifecycle of different topic questions is going to be.
Kristin: Do you–do you know if those–the school that did the–the Black Belt, the various changing of belts over time–that did let students run ahead, if they had any issues with this? Or–
Armando: I don’t know. I don’t know, and in part, the number of students they were talking about was not enormous. So, scaling was not a–scaling was not a goal of doing that.
I think it’s a byproduct, but also, you know, given it–it’s a 14-week course, how far ahead can you run, you know? If you could finish the course in half the time, or a third of the time, but you’re not going to finish in a week.
Kristin: No.
Armando: So, it might just be that the size of the effect wasn’t large enough to matter that much. But I don’t know, as far as I know, they didn’t have any serious problems, at least, when they presented this year in their poster session, they made it sound like they had no serious problems. But, yeah, I don’t know for sure.
Kristin: Yeah, I wonder if they’ve published anything since then, because it’s been a while, if I recall, since that poster.
Armando: Yeah, I don’t know.
Kristin: So, let’s move on to our next topic: which is something awesome about computer science, where our guests share something or someone from computer science they think is interesting, though maybe not necessarily as well known.
Armando: So, a cool thing about computer science that our listeners may or may not be aware of. For various reasons, I have become kind of an aficionado of the history of computing. And depending on how you measure, you could say the history of computing goes back to the abacus. But for practical purposes, I’m probably most interested in the history of what we think of as electronic, general-purpose, programmable computers and so on, which we could, you know, probably date to maybe the 1940s effectively. But, you know, in particular, I sort of got to live through the personal computer revolution, right? When I was in middle school, personal computers were just becoming a thing. So, I got to sort of ride that entire wave and see how it went, and see how, you know, microcomputers ate up minicomputers and they ate up specialized computers. And a thing that has really struck me is how many ideas get recycled in computer science? Maybe because, at the time, that the idea was first proposed, the technology was not really up to implementing it, or at least, not in a way that, you know, whatever, would sort of reach a mass market of end users.
Or maybe because the use cases were not as compelling, and all of a sudden, a use case, like let’s say, you know, putting up web servers that can serve millions of users on the Internet. That’s a pretty compelling use case, and it has caused people to start looking at all sorts of different architectures for how to do that. You know, one of my–my quote-unquote, “favorite” ones when I get asked about it by students is Node.js.
For those of you who are not familiar with Node.js, so, JavaScript is a language that has no concurrency. It has a single thread at all times, which means that if you’re writing a server using JavaScript, you have to write a non-blocking event loop, right? So, you can’t sit and wait for a connection. You have to allow other parts of the program to execute, and in JavaScript that has to be done explicitly, because there’s no implicit concurrency in the language.
So, what you end up doing is coming up with these server frameworks that require you to essentially do all of the work that a thread system does for you, if you are writing programs on a multithreaded OS. And the debates about event loops versus threads, and which is more efficient, and can you do things to make the less efficient ones more efficient? We’ve been having those debates for 30, 40 years in computer science. There’s a long and rich literature about them, and TL; DR–as technology moves around, the balance between those two things shifts right.
So, I’m not saying you should never use Node.js, but I’m saying if you believe the reason you’re using it is that it has this innovative model that is more efficient, you need to understand history. Otherwise, you’re gonna repeat the mistakes of the people who had these debates when multi-threaded OS’s were sort of in their heyday in the 80s and 90s. So, there’s a number of examples like that, but I think if you understand something about the way the field has developed, you will be a better engineer, a better programmer, a better software architect, a better user-experience designer; because you’ll be aware of what people have already thought of, and sometimes you can reuse those ideas. Other times, they’ll inspire you to try something different.
Virtual machines (VM) are not a new idea; the inspiration for doing virtual machines goes back to the 1960s. But when VMware figured out a way to do it that covered a compelling use case–now VMs are the way we do everything, right? Containers are how we deploy big server farms, and how we package software, and everything else. So, and that’s because the engineers who put together the software, VMware, knew the history, right? They knew which problems had been unsolvable, previously, with virtual machines, and they figured out how the technology of the moment could be used to advantage–to overcome those problems in a way that would not have been possible when VMs were–were invented sort of 20, 30 years before.
So, I’m a big fan of computing history, and I think you should read all you can about it. And there’s a lot of great documentaries, and I can probably even send you my–my web page that I called “Master Geek Theater”, which is my recommended documentaries ranging from five minutes to three hours in length.
Kristin: So, would that potentially mean that it might be soon time to either: make sure we always kind of have a history of this field section in a computer science class, or maybe have–start having a history of computer science class that’s like an upper division class to learn how things were done in the past?
Armando: Yes, we should do A or B. I don’t know if that means we do both A and B, or if one of them is strictly better than the other. But I do think that, besides the fact that students would be well served by getting some bits of history and context, I think a lot of them would also find it fun. I mean, in my software engineering course, I have a feature that every couple of weeks I’ll do something I call Armando’s Computer History Minutes. I’ve gathered about a dozen anecdotes about different aspects of computer history, in particular, software engineering history–which, by the way, I’d be happy to make available to any colleagues who want to use them.
Kristin: I think that would be awesome.
Armando: I think if you go to my personal web page, ArmandoFox.com, you may find them. But the students really seem to enjoy learning about them. So, beyond the fact that I think it will serve them well–from the point of view of context and understanding what they’re doing–they genuinely seem to enjoy hearing, you know, what things were like in the old days, or as I call it, the 80s. I know, I know, it makes us feel real old.
Kristin: Yeah, and more and more of your students probably don’t even–like, the 80s, was just way before you were born.
All right, let’s wrap up. So, that would mean we do our next segment, which is TL; DL, Too Long, Didn’t Listen. What, would you say, is the most important thing you would want our listeners to get out of our conversation today?
Armando: I think that the longer-term legacy of MOOCs will have been, first of all, not that they would replace instructors, something that, at Berkeley, we never believed would happen, but that they give instructors new opportunities to use their time in more creative ways. That by having well-curated, interactive exercises that are battle tested, instructors can actually adapt those to classroom use, and I think that–that model of an instructor providing facilitation, along with really great course materials that they did not have to invent–that’s really, I think, long-term, going to be the bigger impact of MOOCs.
I think, sort of a corollary of that is, well, if we’re gonna look at it as an opportunity for facilitated guidance and those materials, then we also need to think about: what does it mean to train more instructors? And again, I think where MOOCs can help us is because they’re structured and–and well-curated, we can have students, and other people who are not very deep content experts, who are not, you know, sort of full-faculty level, but can still provide a great deal of help for their fellow students, in going through the course. And I think all of us, whether we’re looking at the online-only world, or whether we work in a traditional academic setting, would be well-served by asking, “What can we do to train and encourage and empower our students to help teach the other students?” Because it’s not like you’re handing the students the textbook and saying, “Teach the class.” Instead you can think of the MOOC as providing a really nice set of structural scaffolding, and what you’re doing is plugging very targeted kinds of student facilitation into that scaffolding. And like I said, we’ve sort of been doing that at Berkeley, and this is maybe just a way to–to unify those two threads.
So, enhance, not replace, and find out what, you know–teach your teachers, right? It’s, uh–how does the go? Give a person a fish and eat for a day, teach a person to fish, they eat for a lifetime? But teach a person to teach people to fish, and then everybody gets to eat more all the time. And I think that’s what we’re trying to do in combining great MOOC materials with training our student facilitators.
Kristin: Thank you so much for joining us, Armando.
Armando: Thank you for having me.
Kristin: This was the CS-Ed podcast, hosted by me, Kristin Stephens-Martinez at Duke University, edited by Susannah Roberson, and funded by a SIGCSE 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.