Archive for February, 2019

The biggest concerns for institutionalized CS education in the United States: Standards, limited models, and undergraduate enrollment caps

I was interviewed for the SIGCSE Bulletin by my long-time collaborator, Leo Porter (see  I talk about this blog, how I started teaching in 1980, about Media Computation, and about what inspires me.

One of the questions relates to the recent discussion about standards and frameworks (see post here).

LP: You have worked with education public policymakers in “Georgia Computes!” and Expanding Computing Education Pathways (ECEP) over the last dozen years. What’s your biggest worry as US states start institutionalizing CS education?

I have two. The first is that the efforts to standardize CS education are making the bar too low. When the K-12 CS Ed Framework was being developed, decisions were being made based on how current teachers might respond. “Teachers don’t like binary, so let’s not include that” is one argument I heard. I realize now that that’s exactly the wrong idea. Standards should drive progress and set goals. Defining standards in terms of what’s currently attainable is going to limit what we teach for years. Computing education research is all about making it possible to teach more, more easily and more effectively. I worry about setting standards based on our limited research base, not on what we hope to achieve.

The second is that most of our decisions are being made around the assumption of standalone CS classes and having teachers with a lot of CS education. I just don’t see that happening at scale in the US. Even in the states with lots of CS teachers in lots of schools, a small percentage of students take those classes. This limits who sees computer science. To make CS education accessible for all, we have to be able to explore alternative models, like integrating computing education in other subjects without CS-specific teachers. If we only count success in CS education as having standalone CS classes, we are incentivizing only one model. I worry about building our policy to disadvantage schools that want to explore integrated models, or have to integrate because of the cost of standalone CS classes.

Since this interview, I have a third concern, that may be more immediate than the other two.  This is what I wrote my CACM Blog on this month. The NYTimes just published an article “The Hard Part of Computer Science? Getting Into Class” about the growing CS undergraduate enrollment and about the efforts by departments to manage the load.  Departments used to talk about building capacity, but increasingly, the discussion is about capping or limiting enrollments.  The reason why this is concerning is because we’ve been down this road before — see Eric Roberts’ history of CS capacity challenges. Our efforts to limit enrollment send a message about computer science being only for elites and being unwelcoming to non-CS majors. This is exactly opposed to the message that, CS for All, and the AP CS Principles exam is trying to send. We’re creating a real tension between higher education and the efforts to grow CS, and it may (as Eric suggests) send enrollments into the next dive.

February 18, 2019 at 7:00 am 8 comments

How to organize a state (summit): From ECEP and NCWIT

Soon after we started the Expanding Computing Education Pathways (ECEP) Alliance, we were asked: What should a state do first?  If they want to improve CS Education, what are the steps?

We developed a four step model — you can see a three minute video on ECEP that includes the four step model here. It was evidence-based in the sense that, yup, we really saw states doing this.  We had no causal evidence. I’m not sure that that’s possible in any kind of education public policy research.

One of those steps is “Organize.” Gather your allies. Have meetings where you CS Ed people rub elbows with the state public policymakers, like legislators and staffers in the Department of Education (or Department of Public Instruction, or whatever it’s called in your state).

A lot of states have had summits since then (see a list of some here).  Now, working with the fabulous NCWIT team of communicators, graphic designers, and social scientists, ECEP has released a state summit toolkit.  We can’t yet tell you how to organize a state. We can tell you how to organize a state summit.

From finding change agents to building a steering committee of diverse stakeholders, convenings play an important role in broadening participation in computing at the state level. ECEP and NCWIT have developed the State Summit Toolkit to assist leadership teams as they organize meetings, events, and summits focused on advancing K-16 computer science education.


February 15, 2019 at 7:00 am Leave a comment

Need for Reviewers for US Department of Education CS Education Grants – Guest Post from Pat Yongpradit

Pat Yongpradit of asked me to share this with everyone.

The US Department of Education has announced the EIR grant competition for FY 2019. This year EIR incorporates an exclusive priority for computer science with a focus on increasing diversity and equity in access, as compared to last year where the highlight was that CS was merged with STEM as a combined priority. See more detail in our blog.

There are many moving parts to the federal grant review and award process, including a merit-based review process. In order to adequately score grants featuring computer science, the US Department of Education must have enough reviewers with K-12 computer science education experience. There is more information on the merit-review process and the Department’s mechanism for selecting reviewers in this blog. has been asked to put interested folks in touch with leaders of the EIR grant program. If interested, please send your CV to

Having CS knowledgeable reviewers participating in the federal grant review process is crucial to maximizing the opportunity these grants present the field and our collective goal of expanding access to K-12 computer science.



February 14, 2019 at 9:45 am Leave a comment

Hadi Partovi’s keynote at CrossRoads 2018: CS Ed Research needs to up its game

I was scheduled to be on a panel at last year’s InfoSys Crossroads 2018 conference, but my father passed the week before, so I couldn’t make it.  Several people told me that I had to see the video of Hadi Partovi’s talk, because “he talks about CS Education Research.”  The facial expression suggested I should feel warned.

I enjoyed the talk. Hadi made some critical and completely fair statements about CS Ed Research today. I recommend watching.


The really research-y stuff is around 30 minutes into the talk.  He talks about CS competing with other fields (a point that Joan Ferrini-Mundy also made to ECEP), and that CS has to make the argument for itself. I most appreciated the point (around 31:50) that no CS Ed research meets the “What Works Clearinghouse” standards for “works without reservations.” He’s right, and it’s a fair criticism.  Maybe it’s too early, but at some point, we have to be able to compete at the evaluation standards applied to all other subjects. is stepping up their game, with the first evaluation demonstrating that their CSP curriculum significantly increases the rate at which students take and pass the AP CSP exam (see paper here).

I learned a lot from his talk, especially his points about how to scale. I love the advice to “Execute first, raise funding after.”  Since I’m trying to re-start my research program at Michigan, I am thinking about that advice a lot. I hear Hadi saying that I need to be executing on something interesting to fund first, before trying to sell the something interesting I want to do. Writing proposals about things I’m not executing on will probably not be convincing, and delays me making progress on the things I’m passionate about.

Of course, I vehemently agree with his argument that the future of CS Ed is to integrate CS into other subjects.


February 11, 2019 at 7:00 am 12 comments

Inverse Live Coding: A practice for learning web development

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

February 4, 2019 at 7:00 am 9 comments

Come to my workshop on CS Education at ASEE June 16!

I am attending my first American Society for Engineering Education (ASEE) Conference this year — see the website here:

I’m still figuring out Engineering Education Research, so I’ll be offering a workshop based on our work at Georgia Tech: Techniques for Improved Engagement and Learning of Programming. The workshop is Sunday, June 16, 2019 from 9:00 am to noon. Please come, and please pass this on to others you know who are attending ASEE and might be interested.

Computing education research at Georgia Tech over the last 15 years has led to techniques for teaching programming which improve student learning. Learning is enhanced through greater engagement and reduced cognitive load.

These techniques are:

  • Media computation: Teaching programming through manipulation of digital media which improves students’ sense of utility and relevance leading to greater engagement;
  • Worked examples: Using worked examples in peer instruction and for prompting for predictions that improve learning;
  • Subgoal labeling: Structuring and labeling worked examples to improve immediate learning, retention over time, and transfer to new problems.

The learning objectives for this workshop are for participants to experience these techniques so that they might be able to judge which are most useful for their own practice. Participants will:

  • Manipulate digital media with programs that they write during the workshop (laptops required).
  • Participate in peer instruction questions using worked examples.
  • Compare worked examples with and without subgoal labeling.


February 1, 2019 at 7:00 am Leave a comment

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 6,147 other followers


Recent Posts

Blog Stats

  • 1,608,827 hits
February 2019
« Jan    

CS Teaching Tips