I don’t think so. I do believe in this mission. I do research on this mission. I feel strongly that if we don’t massively increase the number of teachers in computing, we’ll get nowhere. But I don’t think that by simply increasing the number of people who can code, we’ll address this gap. This is because the problem, as code.org frames it, is one of quantity, where as the problem is actually about quality.

To put it simply, companies don’t need more developers, they need better developers. The Googles, Facebooks, Apples, and Microsofts of the world get plenty of applicants for jobs, they just don’t get applicants that are good enough. And the rest of the companies in the world, while they can hire, are forced to hire developers who often lack the talent to create great software, leading to a world of poor quality, broken software. Sure, just training more developers might increase the tiny fraction who are great, but that seems like a terribly inefficient way of training more great developers.

This brings us back to teaching. We absolutely need more teachers, but more importantly we need more excellent teachers and excellent learning opportunities. We need the kind of learning infrastructure that empowers every 15 year old who’s never seen a line of code to become as good as your typical CMU, Stanford, Berkely, or UW CS grad, without necessarily having to go to those specific schools. (They don’t have the capacity for the kind of growth, nor should they). We need to understand what excellent software development is, so we can discover ways to help developers achieve it.

This infrastructure is going to be difficult to create. For one, there are going to be a tiny fraction of excellent developers who choose to choose to take a 50% pay cut to teach in a high school or university, and yet we need those engineers to impart their expertise somehow. We need to understand how to create excellent computing teachers and how to empower them to create excellent developers. We need to learn how to make computing education efficient, so that graduates in computing and information sciences have 4 years of actual practice, rather than 4 years of ineffective lectures. We need an academic climate that respects current modes of computing education as largely broken and ineffective for all but the best and brightest self-taught.

Unfortunately, all of this is going to take significant investment. The public and the most profitable of our technology companies must reach deep into their pockets to fund this research, this training, and this growth that they and our world so desperately needs. And so kudos to code.org and every other bottom up effort to democratize computing, but it’s not enough: we need real resources from the top to create real change.

Of course, all of this is a bit overblown. The maps application’s user interface itself is much more usable than the previous version and in many ways, the maps themselves are more readable. The transit plug-in feature, while completely useless at the moment, might actually provide a better experience in the long term, as local apps might be better able to account for subtle differences in transit information accuracy and availability. And while Apple is certainly several years behind in developing comprehensive and accurate map information, its completeness and accuracy will inevitably improve.

The real story here is how Apple communicated the change, and how software companies communicate change more generally. If you looked only at Apple’s communication, you’d think that the new maps was superior in every way, rather than superior in some ways and temporarily flawed in others. But most users probably didn’t read anything about the change at all. They simply pressed “okay” when their phone asked if they wanted to update and suddenly their whole mapping experience was different.

My girlfriend had this exact experience, even though I’d told her it had changed. She didn’t recognize it as the maps app at all; she thought it was a different app altogether and wondered where Google Maps had gone. For an existing user, there are dozens of new things to learn to do even basic things and Apple provided virtually no guidance on what these changes were.

The larger question here is what software companies should communicate to avoid dramatic outbursts of vitriolic hate every time they make a major change. Are release notes enough? Do applications need a standard model for introducing and explaining changes to users? To what extent should companies be responsible for communicating negative changes, such as abandoned features and poorer accuracy, and the rationale for them? As software change becomes more inevitable and more rapid, so will the need for more carefully explained transitions to new platforms, apps, and functionality.

(On a personal note, I’ve found the new Maps to be quite good around Seattle. Yesterday I asked Siri for directions to my daughter’s friend’s house and not only did she find her name in the notes in the contact for the friend’s parents, but Siri found directions that not only routed me around the SR-520 weekend closure, but explained to me that the bridge was closed. The turn-by-turn directions were fast, clear, and accurate and the continuously updating ETA was quite helpful in deciding whether to run the errand we’d planned on doing before we knew about the bridge closure. Overall, a vast improvement over the old maps.)

First and foremost, the lack of a strict length restriction on the journal paper was surprisingly freeing. While on the CHI paper, every other discussion with my student was what to cut and what to keep, discussions about the journal paper were much more about what details and results were missing. Obviously, there are advantages to each: with the CHI paper we were probably forced to be much more concise and selective about the most significant results; similarly, the journal paper was slightly more verbose than it needed to be, because I didn’t have the threat of desk rejection to force more careful editing. At the same time, there were many interesting things that we had to leave out of the CHI paper that could have fit into just one additional page. With journal paper, the question was not “what’s most significant?” but “is this complete?”

The length differences also had a significant effect on how much space we gave to details necessary for reproducibility. For the journal paper, I felt like our task was to enable other researchers understand exactly what we did and how we did it. With the CHI paper, our task was to provide enough detail for reviewers to see the rigor of what we did, but the amount of detail we ended up including really wasn’t enough to actually reproduce our study. In the long term, this is not good science.

Although the journal paper didn’t have a deadline, I did impose one on my lab in order to align with the end of summer, since the undergrad research assistants on the paper would have to resume classes (as would I). The deadline worked well enough to motivate us to finish the paper, but it also freed us to take an extra day or two to read through the manuscript a few extra times, improve some of the figures, and verify some of the results that we felt may have been done too hastily. The CHI paper, in contrast, was rushed, as most CHI submissions are. There was just enough time to edit thoroughly yesterday and submit today, but there’s an extensive list of to do’s that we have if the paper is accepted. Sure, we could do them now, but why not wait until reviewers provide more feedback? With the journal paper, we submitted when we felt it was ready.

Of course, the biggest difference between the two submissions has yet to come. In November, we’ll get CHI reviews back and likely know with some certainty whether the paper will be accepted or rejected. There will be no major revisions, no guidance from reviewers about what they’d like to see added or changed, and certainly no opportunity for major improvements if it is accepted. Instead, the reviews will focus on articulating a rationale for acceptance or rejection. With the journal paper, I’ll (hopefully) get three extensive positions in a few months on what is missing or wrong with the paper and what they’d like me to change in a revision. The process will likely take longer, but in trade, I hope the paper will be much better than original manuscript.

One of these processes is designed for speed, the other is designed for quality. I’ll let you guess which is which. And let me be clear: I’m a big fan of conferences. Most of my work is published at major HCI and software engineering venues and not journals and I truly enjoy the fact that nearly everyone in our community rallies together at the same time of year to contribute our latest and greatest for review. But as someone who has the freedom to really publish in either, I’m really starting to question whether the average conference paper can actually be of comparable quality to the average journal paper. There might just be inherent limits to a review process that is optimized for selecting papers for presentation rather than improving them.

Of course, this isn’t a necessary dichotomy. I’ve talked to many people in my research community about blending the two. For example, if we simply had journals of infinite capacity and no conference papers, and instead put all of our reviewing effort into our journals, we could easily design an annual conference where people present the best work from recent journal publications (and work in progress, as we already do). In fact, CHI already lets ToCHI authors present their recently published papers, so we’re part way there. With changes like this, we might find a nice balance between a review process designed for improving papers and a conference designed for fostering discussion about them.

What I heard instead was a hacker’s hacker talk about his recent realization that software engineering is actually a social science. Across 10 minutes, he covers many human aspects of developer mistakes, programming language design, static analysis, code reviews, developer training, and cost/benefit analyses. The emphasis throughout is mine (and I also transcribed this, so I apologize for any mistakes).

In trying to make the games faster, which has to be our priority going forward, we’ve made a lot of mistakes already with Doom 4, a lot of it is water under the bridge, but prioritizing that can help us get the games done faster, just has to be where we go. Because we just can’t do this going, you know, six more years, whatever, between games.

On the software development side, you know there was an interesting thing at E3, one of the interviews I gave, I had mentioned something about how, you I’ve been learning a whole lot, and I’m a better programmer now than I was a year ago and the interviewer expressed a lot of surprise at that, you know after 20 years and going through all of this that you’d have it all figured out by now, but I actually have been learning quite a bit about software development, both on the personal craftsman level but also paying more attention by what it means on the team dynamics side of things. And this is something I probably avoided looking at squarely for years because, it’s nice to think of myself as a scientist engineer sort, dealing in these things that are abstract or provable or objective on there and there.

In reality in computer science, just about the only thing that’s really science is when you’re talking about algorithms. And optimization is an engineering. But those don’t actually occupy that much of the total time spent programming. You know, we have a few programmers that spend a lot of time on optimizing and some of the selecting of algorithms on there, but 90% of the programmers are doing programming work to make things happen. And when I start to look at what’s really happening in all of these, there really is no science and engineering and objectivity to most of these tasks. You know, one of the programmers actually says that he does a lot of monkey programming—you know beating on things and making stuff happen. And I, you know we like to think that we can be smart engineers about this, that there are objective ways to make good software, but as I’ve been looking at this more and more, it’s been striking to me how much that really isn’t the case.

Aside from these that we can measure, that we can measure and reproduce, which is the essence of science to be able to measure something, reproduce it, make an estimation and test that, and we get that on optimization and algorithms there, but everything else that we do, really has nothing to do with that. It’s about social interactions between the programmers or even between yourself spread over time. And it’s nice to think where, you know we talk about functional programming and lambda calculus and monads and this sounds all nice and sciency, but it really doesn’t affect what you do in software engineering there, these are all best practices, and these are things that have shown to be helpful in the past, but really are only helpful when people are making certain classes of mistakes. Anything that I can do in a pure functional language, you know you take your most restrictive scientific oriented code base on there, in the end of course it all comes down to assembly language, but you could exactly the same thing in BASIC or any other language that you wanted to.

One of the things that’s also fed into that is my older son’s starting to learn how to program now. I actually tossed around the thought of should I maybe have him try to learn Haskell as a 7 year old or something and I decided not to, that I, you know, I don’t think that I’m a good enough Haskell programmer to want to instruct anybody in anything, but as I start thinking about how somebody learns programming from really ground zero, it was opening my eyes a little bit to how much we take for granted in the software engineering community, really is just layers of artifice upon top a core fundamental thing. Even when you go back to structured programming, whether it’s while loops and for loops and stuff, at the bottom when I’m sitting thinking how do you explain programming, what does a computer do, it’s really all the way back to flow charts. You do this, if this you do that, if not you do that. And, even trying to explain why do you do a for loop or what’s this while loop on here, these are all conventions that help software engineering in the large when you’re dealing with mistakes that people make. But they’re not fundamental about what the computer’s doing. All of these are things that are just trying to help people not make mistakes that they’re commonly making.

One of the things that’s been driven home extremely hard is that programmers are making mistakes all the time and constantly. I talked a lot last year about the work that we’ve done with static analysis and trying to run all of our code through static analysis and get it to run squeaky clean through all of these things and it turns up hundreds and hundreds, even thousands of issues. Now its great when you wind up with something that says, now clearly this is a bug, you made a mistake here, this is a bug, and you can point that out to everyone. And everyone will agree, okay, I won’t do that next time. But the problem is that the best of intentions really don’t matter. If something can syntactically be entered incorrectly, it eventually will be. And that’s one of the reasons why I’ve gotten very big on the static analysis, I would like to be able to enable even more restrictive subsets of languages and restrict programmers even more because we make mistakes constantly.

One of the things that I started doing relatively recently is actually doing a daily code review where I look through the checkins and just try to find something educational to talk about to the team. And I annotate a little bit of code and say, well actually this is a bug discovered from code review, but a lot of it is just, favor doing it this way because it’s going to be clearer, it will cause less problems in other cases, and it ruffled, there were a few people that got ruffled feathers early on about that with the kind of broadcast nature of it, but I think that everybody is appreciating the process on that now. That’s one of those scalability issues where there’s clearly no way I can do individual code reviews with everyone all the time, it takes a lot of time to even just scan through what everyone is doing. Being able to point out something that somebody else did and say well, everybody should pay attention to this, that has some real value in it. And as long as the team is agreeable to that, I think that’s been a very positive thing.

But what happens in some cases, where you’re arguing a point where let’s say we should put const on your function parameters or something, that’s hard to make an objective call on, where lots of stuff we can say, this indirection is a cache miss, that’s going to cost us, it’s objective, you can measure it, there’s really no arguing with it, but so many of these other things are sort of style issues, where I can say, you know, over the years, I’ve seen this cause a lot problems, but a lot of people will just say, I’ve never seen that problem. That’s not a problem for me, or I don’t make those mistakes. So it has been really good to be able to point out commonly on here, this is the mistake caused by this.

But as I’ve been doing this more and more and thinking about it, that sense that this isn’t science, this is just trying to deal with all of our human frailties on it, and I wish there were better ways to do this. You know we all want to become better developers and it will help us make better products, do a better job with whatever we’re doing, but the fact that it’s coming down to training dozens of people to do things in a consistent way, knowing that we have programmer turnover as people come and go, new people coming and looking at the code base and not understanding the conventions, and there are clearly better and worse ways of doing things but it’s frustratingly difficult to quantify.

That’s something that I’m spending more and more time looking at. I read NASA’s software engineering laboratory reports and I can’t seem to get any real value out of a lot of those things. The things that have been valuable have been automated things, things that don’t require a human to have some analysis, have some evaluation of it, but just say, enforced or not enforced. And I think that that’s where really where things need to go as larger and larger software gets developed. And it is striking the scale of what we’re doing now. If you look back at the NASA reports and the scale of things and they considered large code bases to be things with three or four hundred thousand lines of code. And we have far more than that in our game engines now. It’s kind of fun to think that the game engines, things that we’re playing games on, have more sophisticated software than certainly the things that launch people to the moon and back and flew the shuttle, ran Skylab, run the space station, all of these massive projects on there are really outdone in complexity by any number of major game engine projects.

And the answer is as far as I can tell really isn’t out there. With the NASA style development process, they can deliver very very low bug rates, but it’s at a very very low productivity rate. And one of the things that you wind up doing in so many cases is cost benefit analyses, where you have to say, well we could be perfect, but then we’ll have the wrong product and it will be too late. Or we can be really fast and loose, we can go ahead and just be sloppy but we’ll get something really cool happening soon. And this is one of those areas where there’s clearly right tools for the right job, but what happens is you make something really cool really fast and then you live with it for years and you suffer over and over with that. And that’s something that I still don’t think that we do the best job at.

We know our code is living for, realistically, we’re looking at a decade. I tell people that there’s a good chance that whatever you’re writing here, if it’s not extremely game specific, may well exist a decade from now and it will have hundreds of programmers, looking at the code, using it, interacting with it in some way, and that’s quite a burden. I do think that it’s just and right to impose pretty severe restrictions on what we’ll let past analysis and what we’ll let into it, but there are large scale issues at the software API design levels and figuring out things there, that are artistic, that are craftsman like on there. And I wish that there were more quantifiable things to say about that. And I am spending a lot of time on this as we go forward.

my stance on public education

This angered me. I came from a middle income household; my mom was a 5th grade teacher and my dad worked in quality assurance for food and lenses, and neither were paid particularly well for their trade. The only way I was going to make it to college was to work my ass off in high school, work a part time job to pay for AP exams, get a lot of scholarships and borrow a lot of money. So that’s what I did. And when I made it to college, I worked part time, I accrued massive debt, and I made it into a great Ph.D. program. I was lucky enough to have chosen a field where Ph.D. students get paid out of public research funds, but I wasn’t paid much (certainly not enough to support myself, my wife and my newborn daughter). So I borrowed more, I earned two public fellowships from the National Science Foundation and the Department of Defense, and we squeaked by for six years financially. After 23 years of public education, I’d used $91,000 in Oregon taxpayer’s money to fund my K-12 education, $36,000 of Oregon taxpayer’s money to subsidize my Oregon State tuition, $7,000 in Pell grants and free interest from U.S. taxpayers, $76,000 from an NSF Fellowship, and another $187,500 from an NDSEG Fellowship. And even with all of this help from public funding, I still had to work part time during high school and college and was still left with $50,000 of student loans to repay.

When you start to look at the cost of educating U.S. citizens—whether someone like me who goes for a terminal degree, or someone who simply wants a college degree—it becomes immediately clear that a person can work incredibly hard to become a valuable contributor to society, fully realizing Ryan and Rand’s vision, and still depend a great deal of support from taxpayers. This idea that people are either self-supporting or dependent leeches is an entirely false dichotomy.

The real question we should be asking is whether sharing the cost of educating our youth is something worthwhile and something to be shared. I know that in my own case that without public funding, I simply could not have gone to college. I’m sure I would have been successful in some other way; I would have taught myself, perhaps going to a community college. Or perhaps my parents would accrued their own massive debt to send me anyway. Either way, the 100 million taxpayers who each gave me less than half a penny of their money probably don’t miss it. And I hope that the work I do to educate our children, advance science, and invent new technologies that make our lives easier is worth that small investment. After all, after a time, the world we live in is not the one we make, but the one our children and grandchildren make for us.

There are a lot of important things that I observed out of all of these discussions and talks:

• The first thing that was apparent is just how different the motives and values are in the different communities that attended. The majority of the attendees were coming from a computing perspective, with primary interests in creating new, more powerful, and more effective learning technologies. There were a smaller number of learning scientists, with interests in explaining learning and devising better measurements of learning, much more rigorously than any of the computing folks had done. Two representations from the Gates Foundation also came briefly, and it was clear that their primary interests were much less in specific technologies and much more in creating educational infrastructure and new, sustainable markets of educational technologies. There were also representatives from Khan Academy and Coursera, who were broadly interested in providing access to content, and mechanisms to enable experts to share content. My view on what’s really new behind all of this press on online learning is that computing researchers are newly interested in learning and education: almost everything else, except for the scale of access, has been done in online learning before.
• Jennifer Widom, Andrew Ng, and Scott Klemmer (all at Stanford), talked about their experiences creating MOOCs for their courses. The key take away message is that it is very time consuming to create the course, with each spending countless hours recording high quality lectures before the hours, negotiating rights for copyrighted material, and working out bugs in the platform. All of them implied that running the course the first time was more than a full time job. On the other hand, many were confident it would take much less time for later offerings and had confidence that most aspects of the class can scale to be arbitrarily large (even design critiques, in Scott Klemmer’s case, through calibrated peer assessment). The one part that doesn’t scale is student-specific concerns (for example, students getting injured and needing an extension on an assignment). Scott also suggested that every order of magnitude increase in the number of students demands an order of magnitude increase in the perfection of the materials (because there are so many more eyes on the material), but again, this is a decaying cost, assuming the materials don’t change frequently.
• In many of the conversations I had around how MOOCs might change education, many faculty believed that the sheer availability and accessibility of instructional content would shift the responsibilities of instructors. Today, most individual instructors are responsible for making their own materials, making them accessible, and then using them to teach. In a world where great materials are available for free, these first two responsibilities disappear. The new job of a higher ed instructor may therefore much less about designing materials and providing access to them, but correcting misconceptions, motivating students, designing good measurements, and building learning communities. One could argue that this is an overall improvement (and also that it actually mirrors the way that textbooks work, which are written by a small number of experts and used as is by instructors).
• Interestingly, most of the MOOC teachers reported that the social experience of students online were critical, including forum conversations, ad hoc study groups in different cities around the world, and peer assessments. This might quell a lot of the concerns that higher ed teachers had about the loss of interaction in online—it might just be that the interaction shifts from instructor/student interaction to student/student interaction and student/intelligent tutor interaction. Some of the preliminary data suggests that students actually greatly prefer this, since they don’t get that much instructor interaction already, but they’re getting much more student/student interaction than in a traditional co-located course. This might therefore be an improvement over traditional lecture-based classes, but not classes in which teachers interact closely with students (such as small studio courses).
• No one knows what will happen to the education market, including the people running Kahn and Coursera. However, there were some predictions. First, these platforms are going to make it so easy to share and access content, in the same way that the web has for everything else, that finding and choosing content is going to become a critical challenge for students. Therefore, one new role that instructors might play is in selecting and curating content in a way that is coherent and personalized for the populations that they teach.
• Most of the interests related to crowdsourcing are either in (1) enabling classes to be taught at scale (by finding ways to free instructors and TAs to have to grade and assess all of the work), (2) to improve the effectiveness, efficiency, and or engagement of learning activities, or (3) to create new opportunities through informal learning, such as through oDesk or Duolingo. Researchers are thinking about how to use data to optimize the sequence of instruction, give just the right hints to correct misconceptions, select a task that is challenging but not too challenging. In my view, this is leading to a renewed interest intelligent tutoring systems.
• As usual, most of this new research work suffers from a lack of grounding in and leveraging of prior literature in learning sciences and intelligent tutoring systems. There is tons of research on all of these challenges that computing researchers are tackling, but I don’t seem them really using any of the work. This happens over and over in computing research, since the interests are often in creating new things and not understanding the things themselves. I was impressed, however, how much Andrew Ng had leveraged findings in learning sciences to support certain design decisions in Coursera.
• There was a big undercurrent of data science at the workshop. Everyone was excited about big data sets and how they might be leveraged to improve learning technologies. Most of the methods reported were fairly primitive (AB testing, retention rates), but I’m hoping this new energy behind learning will lead to much better methods and tools for doing educational data mining.

Phew! Sorry for the lack of coherence here. We covered a lot of ground in 2.5 days and this is just a sliver of it.

The most compelling idea from this post (and most of it was compelling), was the “lump of labor” fallacy, which I hadn’t heard of before. This is the idea that there is a fixed amount of work available in the world and it just gets shifted around between cities, companies, and countries. Economists apparently show little support for this idea, as history has repeatedly shown that innovations typically create more work, rather than less.

Andrew McAfee, argues that information technology is different. All past innovations, he argues, automated things that humans primarily could not do (for example, reaching places we could not reach or lifting things we could not lift, transporting us places we could not reach). In contrast, information technology is beginning to be capable of doing many information related things that humans can do, in addition to all of the information related things we can’t do. Therefore, the only rational thing for employers to do as software becomes functional and cheap enough is to replace people with machines.

Is he right? It’s certainly compatible with a rejection of the lump of labor fallacy. Computing can create more work just like any other innovation, but McAfee might argue that the new work can also be done computers. For example, the fact that I buy a new iPhone every two years means that there does need to be people to manufacture it and fix it when it breaks. But the very technologies embedded in the device are the same ones that enable its manufacturing to be almost completely automated and allow me to get a substantial amount of support from Q&A forums archived on the web, rather than using human technical support. On the other hand, that automation and information access requires a lot of energy, a lot more manufacturing, and a great deal of human time to maintain the Internet. It seems possible that much of this could be taken over by machines eventually.

Can all of the work really be shifted to non-humans? Let’s do a thought experiment to see. Consider a small remote village of 100 humans run entirely by robots and powered by an effectively infinite supply of solar energy. One of the human at any given time is an expert roboticist who can maintain and repair all of the robots independently. This roboticist trains one of the village children to replace her, so that when that roboticist dies, there is another to take over. The roboticist has immense power because the other 99 people depend on her to keep the robotic work force functional (including the robotic work force that keeps the rest of the robotic workforce functional). The result is that the 99 people don’t work (because there’s no work to do), and live a life of leisure. The only reason that everyone survives is because of the roboticist’s knowledge and benevolence and that nearly all of the work has been shifted to the robots. In fact, the robots may even become intelligent enough to fix and maintain themselves one day, making even the roboticist obsolete.

There are most certainly things missing from this little story that make it implausible. For example, the population wouldn’t stay at 100 people, especially with everyone living such a life of leisure. Assuming the robots could reproduce themselves and gather their own natural resources, the population would continue to grow until Earth was out of resources, as it does now.

The more significant missing element, I think, is boredom. In such a life of leisure, wouldn’t people create work for themselves, just to be entertained or to find meaning? I could imagine for example, one particularly inquisitive villager deciding to write a book on the meaning of life in a world where there is no human work. She might outsource the editing, printing, and binding of her book to the robots, but would she outsource the audience? The critical reflections? The impassioned rebuttals? Surely the villages would create work for themselves, if only to create meaningful social bonds and avoid listlessness.

Perhaps the reason that “lump of labor” is a fallacy, even for computing, is that work isn’t a separate entity from humanity that can be shifted to and from humanity. Humanity is the source of work. Computing many eliminate forms of work that we are used to in present day society, but we will inevitably find ways to occupy ourselves otherwise. Perhaps its just the disruptive transitions that are painful, where the middle class struggles, starves, and loses, only to be motivated by their hunger to create new work with which to fill their bellies.

As a researcher, however, looking young can feel like a disadvantage, since the wisdom and knowledge one has typically grows with age (at least in academia). Sometimes I feel like people discount my opinions because I look young, perhaps because my face communicates inexperience. Sometimes I feel like I have to compensate by being extraordinarily articulate or insightful, just to get people to listen to me. At conferences, people always ask me what I’m studying, who my advisor is, or where I go to school. I suspect that when people who don’t know me see me at a conference, they think, “just another student” instead of “I wonder who that important researcher is” like I do when I see older researchers at conferences.

Not that this has held me back. If anything, it means that any success I’ve had has been earned, which makes it all the more rewarding. And it shows that academia is still indeed some form of meritocracy, where it is the ideas and knowledge that one produces that ultimately shapes our reputations. In fact, when I’m 60, I’ll probably look like I’m in my 40’s (as my parents do), which will help me avoid all of the ageism directed at older professors, so any disadvantage I have now might turn into an advantage later in life. That should enable me to have a nice long career into my 70’s (assuming my brain still works!).

Ultimately, I feel lucky that ageism is the only real discrimination that I face. There are faculty who face ageism, sexism, and racism, which seems like an incredible amount of bias for one person to struggle against. Facing a bit of ageism here and there makes me empathize with people who face even more discrimination and makes it easier for me to avoid assuming anything about a person until I talk with them. And it helps me respect their successes even more, because I have a tiny glimpse into what it took to earn it.

A snapshot from INSC 541, one of the design methods classes that I teach.

As a professor in higher ed, I’ve been thinking a lot lately about massive open online courses (MOOCs), and in particular, how they differ from modern classrooms in higher ed. For a while now, I’ve been quite certain that there are crucial benefits to teaching in physical environments, but we just haven’t been able to articulate what they are. After a lot of thought and observation, I’ve decided that while there are significant differences in the teaching affordances, in practice, most higher ed classrooms are nearly identical to MOOCs, except in scale, where MOOCs win hands down.

Why? It all comes down to feedback. (This shouldn’t be surprising come from me, since nearly everything I think about as a researcher has to do with feedback). I believe strongly, as does the rest of learning sciences and psychology, that feedback is a fundamental part of learning and understanding. Without it, people are left to make sense of the world in a vacuum. And the opportunities for feedback in most higher ed classrooms are simply not that different from those posed by MOOCs.

Consider your standard 150 student lecture course. Let’s take CS1 as an example and imagine the best possible delivery of this kind of instruction. Such a course would have a sage on the stage, lecturing about for loops and variables; you might even have innovative classroom practices such as peer learning or quizzes every 10 or fifteen minutes. At best, students get immediate feedback on quiz results and perhaps even automated feedback on homework assignments. A few students may even be bold enough to ask questions in class or make it to office hours for additional help. If the course uses peer learning, they’ll get some corrective feedback from their peers, which can help greatly. In this setting, the real value is access to these limited instructional resources offered by the instructor and the TAs. Ultimately, however, the vast majority of these 150 students receive little, if any, personalized instructional feedback from experts.

Now consider a CS1 MOOC, like those offered by Coursera and Udacity. The central structure of these courses is nearly identical: a sage on the stage imparts wisdom in brief chunks; students get feedback through automatically graded quizzes and homework assignments. Self-motived learners use this feedback, and the guidance of their fellow students via discussion boards (ala peer learning), to understand and correct their own misconceptions. Like the students in the physical classroom, they are largely on their own, unless they are resourceful enough to solicit feedback from peers, instructors, or other online resources.

The big difference with a MOOC are that many more students can be taught and that automatic, immediate feedback (even if it’s suboptimal to an individual human tutor) is guaranteed (whereas it is not in most physical CS1 courses). It’s no wonder higher ed instructors are scared. For a course of the same kind, the physical version has almost no advantages over the online one!

But this doesn’t have to be. There are a huge number of affordances that physical classrooms offer that no online course can match. First and foremost, the walls and surfaces in classrooms, and the throughput of face to face communication, offer vastly superior means with which to view and critique student work. The image above, for example, shows a design methods class that I teach to Ph.D. students. We constantly use the walls to post work and facilitate peer critique and because I can see all of the discussion that are happening, and overhear how well each is going, I know who needs help and when and can quickly connect students who are struggling with similar ideas. None of this is possible online because the channels of communication are too few and to serialized.

Another instructional affordance that is still absent online is laughter. Don’t laugh! I’m serious. In my brief experience as a teacher, I’ve come to view laughter as a crucial part of motivating students who aren’t already self-motivated. Finding ways for students to interact in physical space, and giving them opportunities to not only discuss and work through ideas, but comment on the very discussion of them in humorous ways, creates motivational bonds in students that I’ve yet to see happen in MOOCs. There are simply too many people and too few identity cues to create these types of motivating relationships.

There is one major caveat to this line of reasoning: just because physical classrooms have these affordances doesn’t mean they are useful or valuable to teaching all subjects. A student taking a medical terminology course, where their sole job is to memorize and understand thousands of medical terms, is probably much better off with an online drill and practice mode of instruction and skip the physical classroom. In the same way, it’s likely that online courses will always be infeasible for a Chemistry lab: there’s simply too much physical infrastructure and safety concerns to imagine students either creating their own lab or finding a local one, in which to perform experiments.

The real challenge then for us in higher ed is to figure out what forms of instruction really do require or strongly benefit from physical space and focus on those. Tear out the rows of desks and replace them with flexible walls and surfaces. Invest in course release so that faculty can learn how to utilize these physical affordances. Give faculty whose expertise is in something best delivered online the time and incentive to create outstanding versions of these courses that benefit both students and their home universities, but also students anywhere in the world. This future isn’t one where universities disappear, but one in which we faculty finally start taking teaching seriously. It’s about time we had a little competition to give us the clear feedback that the status quo isn’t good enough (except online).

Today, however, machining is less about operating machines, and more about writing code that operates machines (CNC machines, in particular, standing for computer numerically controlled). To learn the CNC programming language, workers typically take an 18-week course before their ready to operate CNC machines, but then they can make a reasonable manufacturing wage without getting their hands dirty or risking injury. This is a classic example of end-user programming, where someone has to write code as a means to an end (a physical object).

What’s even more fascinating is the economic discussion surrounding this jobs. Apparently, the problem isn’t training the machinists, but finding people who want to be trained. The Manufacturing Institute found in a survey that there are as many 600,000 manufacturing jobs going unfilled, the majority of which are jobs that require these kinds of technical computing skills. This is therefore as much a training problem as it is a recruiting problem.