Archive for June, 2016

Mattel’s Game Developer Barbie is fantastic, says Casey Fiesler

Casey Fiesler and Miranda Parker did a wonderful remix of the original computer engineer Barbie (see Guardian article about that).  Great to see that Mattel did a better job the next time around, and Casey loves it.  I love the point she makes below, which echoes a concern I’ve voiced about open source software.

This is particularly important is because as much as we don’t want to suggest that girls can’t code, we also don’t want to suggest that coding is the only path to working with computers or games. Sometimes other parts of computing—like design or human-computer interaction—are delegitimized, considered less rigorous or less important. Or maybe they’re delegitimized in part because they happen to be the parts of computing where there are more women present (in other words, more inclusive), which is even worse.

Source: Mattel’s Game Developer Barbie is fantastic.

June 29, 2016 at 7:47 am 2 comments

NSF director unveils big ideas, with an eye on the next President and Congress

Interesting and relevant for this list. There’s a lot in the NSF big ideas document (see link here) about using technology for learning, but there’s also some on what we want students to know (including about computing technology), e.g., “the development and evaluation of innovative learning opportunities and educational pathways, grounded in an education-research-based understanding of the knowledge and skill demands needed by a 21st century data-capable workforce.”

The six “research” ideas are intended to stimulate cross-disciplinary activity and take on important societal challenges. Exploring the human-technology frontier, for example, reflects NSF’s desire “to weave in technology throughout the fabric of society, and study how technology affects learning,” says Joan Ferrini-Mundy, who runs NSF’s education directorate. She thinks it will also require universities to change how they educate the next generation of scientists and engineers.

Source: NSF director unveils big ideas, with an eye on the next president and Congress | Science | AAAS

June 27, 2016 at 8:03 am Leave a comment

Dr. Kamau Bobb Talks Research and Challenges in STEM Education

I’ve talked about Kamau Bobb’s work in this blog previously, when he wrote a depressing but deeply-insightful op-ed about the state of mathematics education in Atlanta public schools. He’s recently been interviewed in a three part series in Black Enterprise about his role as an NSF program officer.  The below quote is from Part II — I recommend the whole series.

The most significant challenge facing STEM education and the workforce is the capacity of the U.S. educational system to produce interested and qualified participants in the STEM enterprise. Here is where the racial and socio-economic challenges facing the nation are most glaring.

According to the National Center for Education Statistics National Report Card, there are some damning realities that significantly challenge STEM education and the STEM workforce. In 2015, only 33% of all eighth grade students in the U.S. were proficient or better in mathematics. Only 13% of black eighth graders and 19% of Hispanic eighth graders were proficient or better in mathematics, which is in contrast to 43% of white students and 61% of Asian students. For students who live in poverty and qualify for the National School Lunch Program, only 18% were proficient in eighth grade mathematics.

According to the College Board, only 16% of black students are college or career ready by the time they take the SAT in eleventh grade. For Hispanic students, 23% are ready. For Asian and white students, 61% and 53%, respectively, are ready for higher education or to take on meaningful work. This landscape is a problem.

Source: Dr. Kamau Bobb Talks Research and Challenges in STEM

June 24, 2016 at 8:03 am 4 comments

Google-Gallup Survey now Disaggregated by States: Fascinating and confusing reading

Google has now released the results of the Gallup surveys from last year of parents, teachers, and principals about attitudes on CS disaggregated by 11 populous US states — see state reports (and methodology explanation) here.  The blog announcement about the report is here. These are fascinating to read, especially for me and my colleagues since some of these states are also ECEP states (see our recent report on activity in ECEP states).  Pennsylvania, Wisconsin, and Texas are doing much better than the US average in this analysis, while Ohio and North Carolina are far behind.

These are the results of a large scale survey, not an interview, or focus groups.  The advantage is that we get a lot of answers (9, 693 elementary school principals across the US). The disadvantage is that they answered these questions, without probes, follow-ups, or any “What did you mean by that?”

For example, one of the benchmark items is “CS offered > 5 years.”  My first thought was that this meant that there was CS offered in the curriculum for five grades, e.g., middle school and high school.  The actual question answered by principals was “How long has your school offered opportunities to learn computer science? (% greater than 5 years)”  So this item is about the longevity of CS ed at these particular schools that were sampled.  That’s interesting, but I’m not sure what it says about the state compared to the particular schools sampled — especially in local control states (e.g., California, Massachusetts, Nebraska) where individual districts can do anything they want.

We’re told that parents want more CS, but principals and parents mostly think that CS is computer literacy (e.g., how to use a computer).  We’re told that 64% of Michigan principals say “just as/more important” to “Do you think offering opportunities to learn CS is more important, just as important, or less important to a student’s future success than required courses like math, science, history and English?”  What does that mean, if they think that CS is keyboarding skills?  When 11% of the principals in Illinois say that demand for CS education among parents is high, does that mean that the principals think the parents think it’s keyboarding? or real CS? Is one more valuable than the other to parents, in the opinion of principals?  Maybe the principals are right, and only 11% of the parents would want CS if they knew what CS was.

Overall, recommended reading, but sometimes, it feels like reading tea leaves.

June 22, 2016 at 7:26 am 2 comments

How to choose programming languages for learners: Reviewing JavaScript and Ready

My Blog@CACM post for June is Five Principles for Programming Languages for Learners. The five principles I identify are:

  1. Connect to what learners know
  2. Keep cognitive load low
  3. Be honest
  4. Be generative and productive
  5. Test, don’t trust

I wrote the essay in response to Idit Harel’s influential essay American schools are teaching our kids how to code all wrong. There were many responses to Idit’s essay, on social media and in other blogs. Much of the discussion focused on text programming languages vs. drag-and-drop, blocks-based languages, which I don’t think is the most critical distinction.

In this post, I respond to two of the suggestions that came up in some of these discussions. I use the five principles to review the suggestions in a kind of heuristic evaluation.


If we were going to teach a professional language to students, JavaScript is attractive. It’s free and ubiquitous, available in every Web browser. There are many jobs for JavaScript programmers. Because so much is built on top of it, it’s likely to remain around for many years in a compatible form. I argue in the Blog@CACM post that there are many dimensions to “real” when it comes to programming languages. “Use by professionals” is not the most important one when we talk about learners.

I recommend considering each of these five principles before choosing a programming language like JavaScript for learners.

  1. Connect to what learners know – You could teach JavaScript as a connection to what children already know. The notation of JavaScript doesn’t look like anything that children are likely to have seen before, in contrast to Logo’s emphasis on words and sentences, Squeak eToys’ “Drive the Car,” Boxer’s simple UI boxes (what diSessa calls naive realism), and Racket/Bootstrap’s connections between algebra and S-expressions.  However, JavaScript is the language of the Web today, so one could probably relate the programming activities to Web pages. Most learners are familiar with parts of a Web page, animations in a Web page, and other Web features that JavaScript can control. That might serve as a connection point for children.
  2. Keep cognitive load low – JavaScript has a high cognitive load. I’m a JavaScript learner and am just meeting some of its weirder features. I was shocked when I first read that = is assignment, == is type-insensitive equality, and === is type sensitive equality/equivalence. So, "5"==5 is true, but "5"===5 is false. Counting the number of = and remembering what 1 vs 2 vs. 3 means is an excellent example of extraneous cognitive load. My bet is that JavaScript overwhelms children and is probably inefficient for adult learners. This means that learners are spending so much time making sense of the syntax, it takes them longer and more effort to get to the concepts (and they may lose interest before they get to the good stuff).
  3. Be honest – JavaScript is authentic, it’s real for most senses of the term.
  4. Be generative and productive – I don’t know if JavaScript would be generative and productive for students. I don’t know anyone teaching JavaScript as a way to teach significant ideas in CS or other STEM disciplines. My worry is that the cognitive load would be so overwhelming that you couldn’t get to the interdisciplinary or complex ideas. Students would spend too much effort counting = and fighting for loops.
  5. Test, don’t trustThe only study that I know comparing JavaScript to a blocks-based language had JavaScript losing. JavaScript conditionals and loop structures were far harder for students than the equivalent block-based structures.

We should experiment more with JavaScript, but I suspect that students would do better (struggle less with syntax, learn more, connect to other disciplines more) with a different syntax. If I were trying to get the advantages of JavaScript without the syntax cost, I’d try something like ClojureScript — freely available, as fast as JavaScript, as ubiquitous as JavaScript, used professionally, can be used to control Web pages like JavaScript (so connectable for learners), and with the syntactic similarities to mathematics that Racket enjoys.


Baker Franke of is promoting the essay Coding snobs are not helping our children prepare for the future as a response to Idit’s essay. The essay is about the application-building tool, Ready. Media theorist Dough Rushkoff has also been promoting Ready, What happens when anyone can code? We’re about to find out.

I disagree with Rushkoff’s description of Ready, even in the title. As the first essay by David Bennahum (a “Ready Maker and Venture Partner) points out, it’s explicitly not about using a programming language.

Our efforts at Ready, a platform that enables kids to make games, apps, whatever they want, without knowing a computer language, are designed to offer a new approach to broadening access to code literacy.

Bennahum’s essay means to be provocative — and even insulting, especially to all the teachers, developers, and researchers who have been creating successful contextualized computing education:

In this new world, learning coding is about moving away from computer languages, syntax, and academic exercises towards real world connections: game design and building projects that tie into other subjects like science and social studies… This is the inverse of how computer science has been taught, as an impersonal, disconnected, abstracted, mathematical exercise.

I can see how Rushkoff could be confused. These two quotes from the Ready team seem contradictory. It’s not clear how Ready can be both about “learning coding” and “code literacy” while also allowing kids to make “without knowing a computer language.” There is no programming language in Ready.  What is coding then? Is it just making stuff?  I agree with Rushkoff’s concerns about Ready.

True, if people don’t have to code, they may never find out how this stuff really works. They will be limited to the programming possibilities offered by the makers of the platforms, through which they assemble ready-made components into applications and other digital experiences.

Let’s consider Ready against the five principles I propose.

  1. Connect to what learners know – the components of Ready are the icons and sliders and text areas of any app or game. That part is probably recognizable to children.
  2. Keep cognitive load low – Ready is all about dragging and dropping pieces to put them together. My guess is that the cognitive load is low.
  3. Be honest – Ready is not “real” in most sense of authenticity. Yes, students build things that look like apps or games, but that’s not what motivates all students. More of Betsy DiSalvo’s “Glitch” students preferred Python over Alice (see blog post). Alice looked better (which appealed to students interested in media), but students knew that Python was closer to how professional programmers worked. Authenticity in terms of practice matters to students. No professional programmer solely drags and drops components. Programmers use programming languages.
  4. Be generative and productive – Ready completely fails this goal. There is no language, no notation. There is no tool to think with. It’s an app/game builder without any affordances for thinking about mathematics, science, economics, ecology, or any other STEM discipline. There’s a physics engine, but it’s a black box (see Hmelo and Guzdial on black box vs glass box scaffolding) — you can’t see inside it, you can’t learn from it. They build “models” with Ready (see this neurobiology example), but I have a hard time seeing the science and mathematics in what they’re building.
  5. Test, don’t trust – Ready offers us promises and quotes from experts, but no data, no results from use with students.

Ready is likely successful at helping students to make apps and games. It’s likely a bad choice for learners. I don’t see affordances in Ready for computational literacy.

June 20, 2016 at 7:46 am 23 comments

Getting closer to “all” in #CSforAll: Instructional supports for students with disabilities in K-5 computing

I’ve been arguing for a while that we don’t know how to get to CS for All, because we don’t know how to teach “all” yet.  This is what the Bootstrap group has been arguing from a STEM discipline and economics perspective (see blog post). I’ve also been concerned that we’re biased by the Inverse Lake Wobegone Effect and are assuming that the high-ability learners we’ve been teaching represent everyone.

Maya Israel is one of the few researchers who’s asking, “How do we teach computing to students with cognitive or learning disabilities in K-12?”  Below is a link to her most recent study.  Here, she’s looking at how we teach, what helps the students to engage in the computing activity.  I talked with her about this paper — we still don’t know what the students are learning.

As computer programming and computational thinking (CT) become more integrated into K-12 instruction, content teachers and special educators need to understand how to provide instructional supports to a wide range of learners, including students with disabilities. This cross-case analysis study examined the supports that two students with disabilities, who were initially disengaged during computing activities, received during computing instruction. Data revealed that students’ support needs during computing activities were not CT-specific. Rather, supports specific to these students’ needs that were successful in other educational areas were also successful and sufficient in CT. Although additional studies would need to be conducted to ascertain the transferability of these findings to other contexts and students, our results contribute evidence that students with disabilities can and should participate in CT and be provided with the supports they need, just as in all other areas of the curriculum. We present a framework for evaluating student engagement to identify student-specific supports and, when needed, refine the emerging K-12 CT pedagogy to facilitate full participation of all students. We then offer a list of four implications for practice based on the findings.

Source: Instructional supports for students with disabilities in K-5 computing: Findings from a cross-case analysis

June 17, 2016 at 7:51 am Leave a comment

An Ebook Integrating Minimal Manuals with Constructionism, Worked Examples, and Inquiry: MOHQ

Our computing education research group at Georgia Tech has been developing and evaluating ebooks for several years (see this post with discussion of some of them). We publish on them frequently, with a new paper just accepted to ICER 2016 in Melbourne. We use the Runestone Interactive platform which allows us to create ebooks with a lot of different kinds of learning activities — not just editing and running code (which I’ve been arguing for awhile is really important to support a range of abilities and motivations), but including editing and running code.

It’s a heavyweight platform. I have been thinking about alternative models of ebooks — maybe closer to e-pamphlets. Since I was working with GP (see previous post) and undergraduate David Tran was interested in working with me on a GP project, we built a prototype of a minimalist medium for learning CS. I call it a MOHQ: Minimal manual Organized around Hypertext Questions: (Suggestion: Use Firefox if you can for playing with browser GP. WAY faster for the JavaScript execution than either Chrome or Safari on my Mac.)

Minimal Manuals

John Carroll came up with the idea of minimal manuals back in the 1980’s (see the earliest paper I found on the idea). The goal is to help people to use complicated computing devices with the minimum of overhead. Each page of the manual starts with a task — something that a user would want to do. The goal is to put the instruction for how to achieve that task all on that one page.

The idea of minimalist instruction is described here:

The four principles of minimal instruction design are:

  1. Allow learners to start immediately on meaningful tasks.
  2. Minimize the amount of reading and other passive forms of training by allowing users to fill in the gaps themselves
  3. Include error recognition and recovery activities in the instruction
  4. Make all learning activities self-contained and independent of sequence.

There’s good evidence that minimal manuals really do work (see Learners become more productive more quickly with minimal manuals, with surprisingly high scores on transfer and retention. A nice attribute of minimal manuals is that they’re geared toward success. They likely increase self-efficacy, a significant problem in CS education.

The goal of most minimal instruction is to be able to do something. What about learning conceptual knowledge?

Adding Learning Theory: Inquiry, Worked Examples, and Constructionism

I started exploring minimal manuals as a model for designing CS educational media after a challenge from Alan Kay. Alan asked me to think about how we would teach people to be autodidacts. One of the approaches used to encourage autodidactism is inquiry-based learning. Could we structure a minimal manual around questions that they might have or that we want students to ask themselves?

We structure our Runestone ebooks around an Examples+Practice framework. We provide a worked example (typically executable code, but sometimes a program visualization), and then ask (practice) questions about that example. We provide one or two practice exercises for every example. Based on Lauren Margeliux’s work, the point of the practice is to get students to think about the example, to engage with it, and to explain it to themselves. It’s less important that they do the questions — I want the students to read the questions and think about them, and Lauren’s work suggests that even the feedback may not be all that important.

Finally, one of the aspects that I like about Runestone is that every example in an active code area is a complete Python interpreter. Modify the code anyway you want. Erase all of it and build something new if you want. It’s constructionist. We want students to construct with the examples and go beyond them.

MOHQ: Minimal Manual Organized around Hypertext Questions

The prototype MOHQ that David Tran and I built ( is an implementation of this integration of minimal manuals with constructionism, inquiry, and worked examples. Each page in the MOHQ:

  • Starts with a question that a student might be wondering about.
  • Offers a worked example in a video.
  • Offer the opportunity to construct with the example project.
  • Asks one or two practice questions, to prompt thinking about the project.

Using the minimal design principles to structure the explanation:

  1. Allow learners to start immediately on meaningful tasks.

The top page offers several questions that I hope are interesting to a student. Every page offers a project that aims to answer that question. GP is a good choice here because it’s blocks-based (low cognitive load) and I can do MediaComp in it (which is what I wanted to teach in this prototype).

#1: Minimize the amount of reading and other passive forms of training by allowing users to fill in the gaps themselves.

Each page has a video of David or me solving the problem in GP. Immediately afterward is a link to jump directly into the GP project exactly where the video ended. Undo something, redo something, start over and build something else. The point is to watch a video (where we try to explain what we’re doing, but we’re certainly not filling in all the gaps), then figure out how it works on your own.

Then we offer a couple of practice questions to challenge the learner: Did you really understand what was going on here?

#2: Include error recognition and recovery activities in the instruction.

Error recovery is easy when everything is in the browser — just hit the back button. You can’t save. You can’t damage anything. (We tell people this explicitly on every page.)

#3: Make all learning activities self-contained and independent of sequence.

This is the tough one. I want people to actually learn something in a MOHQ, that pixels have red, green, and blue components, and chromakey is about replacing one color with a background image, and that removing every other sample increases the frequency of a sound — and more general ideas, e.g., that elements in a collection can be referenced by index number.

So, all the driving questions from the home page start with, “Okay, you can just dive in here, but you might want to first go check out these other pages.” You don’t have to, but if you want to understand better what’s going on here, you might want to start with simpler questions.

We also want students to go on — to ask themselves new questions, to go try other projects. After each project, we offer some new questions that we hope that students might ask themselves. The links are explicitly prompts. “You might be thinking about these questions. Even if you weren’t, you might want to. Let’s see where we can explore next.”

Current Prototype and What Comes Next

Here’s the map of pages that we have out there right now. We built it in a Wiki which facilitated creating the network of pages that we want. This isn’t a linear book.


There’s maybe a dozen pages out there, but even with that relatively small size, it took most of a semester to pull these together. Producing the videos and building these pages by hand (even in a Wiki) was a lot of work. The tough part was every time we changed our minds about something — and had to go back through all of the previously built pages and update them. Since this is a prototype (i.e., we didn’t know what we wanted when we started), that happened quite often. If we were going to add more to the GP MOHQ, I’d want to use a tool for generating pages from a database as we did with STABLE, the Smalltalk Apprenticeship-Based Learning Environment.

I would appreciate your thoughts about MOHQ. Call this an expert review of the idea.

  • Thumbs-up or down? Worth developing further, or a bad direction?
  • What do you think is promising about this idea?
  • What would we need to change to make it more effective for student learning?

June 15, 2016 at 7:35 am 12 comments

Introducing GP: A General Purpose Block Language

GP is a new blocks-based programming language being developed by John Maloney (most well-known for developing Scratch), Jens Mönig (developer of Snap!), and Yoshiki Ohshima (one of the developers of Squeak EToys) in Alan Kay’s group. They are all part of the new partnership between Alan Kay and Y-Combinator Research: HARC (Human Advancement Research Community). GP started in the SAP-funded CDG (Communications Design Group).

GP is not yet released, and there’s not much publicly available on it yet. The GP Team published a paper and poster in the Blocks and Beyond Workshop at last year’s VL/HCC on GP. The best introductory article on GP so-far is on the Scratch Wiki at MIT based on John’s presentation at the Scratch conference last year.

What makes GP remarkable is that it aims to be a general purpose language. John’s vision for GP is to be the language that students might move to after Scratch, with the highest possible ceilings. Think about GP as Python or Smalltalk in blocks — and even more the latter than the former. From the virtual machine (VM) on which it runs to the class browser, GP feels like a blocks-based form of Smalltalk. Because GP is VM-based, it’s portable — there are versions for Mac, Windows, iOS, and even a JavaScript implementation of the VM so that GP runs in the browser.

GP is an exploration of the question, “How far can we go with a blocks-based programming language? Do we have to move students to a textual programming language to let them develop everything from data analyses to real applications?”

GP users can do a lot with GP’s built-in blocks. However, as they grow in mastery, some users may wish to add new blocks to GP (e.g. to manipulate images), or even to extend the GP programming environment itself (e.g. by adding an image editor). GP is designed to be extended in itself using the same blocks language that users already know. However, unlike Smalltalk or Snap!, the GP language itself cannot be extended (e.g. to add a new control structure) without modifying the virtual machine. Keeping the GP language simple and fixed is intended to ease the learning path for beginners.

A brief tour of Smalltalk-like features of GP

When you first start up GP, it looks like Scratch. The blocks palette is different, because it’s covering a larger space of blocks. GP includes blocks for dealing with data (e.g., JSON, comma-separated values), media generation and manipulation, connections to the network and external devices, and the ability to create and coordinate multiple objects.


There are even blocks in there for manipulating pixels in an image and samples in a sound. GP is the first blocks-based language in which I’ve been able to do both sound and pixel Media Computation examples. I built the first version of MediaComp blocks for GP, then John figured out which ones were actually useful and then re-implemented them in GP much more efficiently than what I did.

I’m introducing GP here with the GP Team’s permission in order to show you a prototype ebook I’ve been building the last few months. You can play with GP at This is the browser-based version which is offered with no guarantees — the browser version will likely change dramatically as GP is still being developed, and even the examples in the ebook may break over time. (Note: These browser-based examples are best viewed in Firefox on a desktop or laptop computer; they do not yet work on iOS or Android tablets.)

Here’s a brief series of snapshots to give you a sense of what makes GP so interesting and powerful compared to most other blocks-based languages. In the stage area (upper right-hand corner) right-click (control-click on a Mac) to bring up the stage menu.


The menu options for a workspace and to browse will elicit warm feelings of recognition for Smalltalk and Self programmers. Go ahead and click on the browse menu item.


Scanning the classes along the left hand side you realize that this is a full Smalltalk-like language. All the pieces are there and inspectable. The middle panes show the instance variables in the class (top) and the methods for the class (bottom). The rightmost pane shows the code for the method — in blocks!

One of the big goals of GP is that all of GP is written in GP. Even the lowest levels of GP (e.g., how bitmaps and blocks are constructed) can be manipulated in GP, all in blocks. Those methods are real code and “live.” Change them and you change how GP is working immediately. Right now, that’s super dangerous — there is no “editing” mode. Move a block out of place, and the method is changed at that moment. Beware of re-defining how Integers work! The GP team is currently working to complete this part of GP, allowing the GP programming system to be used to modify itself, like Smalltalk.

The GP team is also exploring the stages between blocks and text. At the top right hand corner of GP is a slider between blocks and text. Switch it to text, and all of GP is presented and usable in a textual form. (There’s even an interesting middle stage between blocks and text.)


I’ve been using GP for about nine months. During the Spring semester, I’ve been using GP with an undergraduate research assistant, David Tran, to build a prototype of a new kind of ebook structure. Play around (muck/MOHQ around) in the GPBlocks MOHQ, and in the next blog post, I’ll explain what it is and what we’re exploring in it.

My thanks to the GP team for review and comments on drafts of this post.

June 13, 2016 at 7:28 am 26 comments

Final Review Period for the K-12 CS Framework for K-12 Computer Science Education June 8-29

The final review period is June 8-29. Do engage with the review.  Whatever comes out of this is likely to influence the standards for K-12 CS education in the United States for the next five to ten years.

I’m not so happy with the framework, but I recognize that it’s a collaborative process where no one is going to be completely happy (see previous post about the framework).  A source of difficulty for building the framework is that we are so early in CS Education in the United States. We are optimizing for the current state, at time when that state is rapidly changing.

Here’s an instance of the general problem. Last time I was at a framework meeting as an advisor, I pushed hard to include the concept of the word bit as a learning objective in the framework.  Even as quantum computing is developed, the Claude Shannon notion of a bit as a fundamental unit of information is still relevant and useful — it’s one of the foundational ideas of computing. The suggestion was vehemently rejected by the writers because current teachers fear binary.  I tried to argue that we can talk about bits (e.g., what is information, how we can store/represent bits, and how we can encode information in bits) without talking about binary, but the writers argued that teachers will perceive bits as being about binary and reject it.  I pointed out that the word bit did appear in the document, just not explained. It’s hard to talk about computing without talking about “bits.” In response, every instance of the word bit was removed from the framework document.

We have so few teachers today in schools (e.g., no state has high school CS teachers in more than even 30% of their high schools, we likely need ten times the number of current teachers in order to provide CS education to everyone in the United States), and we’re still just figuring out how to develop new CS teachers.  Should we really make decisions about the next 5-10 years based on what current teachers dislike? Especially when too few of those teachers have had significant teacher professional development? Maybe we do — we might need to keep those teachers engaged in order to grow the programs to create more teachers.

I argued in the past that it’s about consensus not vision.  It still is. The question is how much unpleasantness we can swallow and still agree on the framework.

The goals of the K-12 CS framework review process are to provide transparency into the development of the K-12 CS framework and include feedback from a diverse range of voices and stakeholders. If you haven’t already, please sign up for framework updates.Individuals and institutions are invited to be reviewers of the K-12 CS framework. Institutions, such as state/district departments of education and organizations (industry, companies, non-profits), are responsible for selecting an individual or a group to represent the institution.

Source: Review – A Framework for K-12 Computer Science Education

June 10, 2016 at 8:03 am 10 comments

Highlighting NSF STEM Education Showcase Videos

Last month, NSF hosted a STEM Education video showcase.  I was surprised at how much I enjoyed and learned from these.  They’re only 3 minutes each, so it’s a brief investment in getting a sense of a project — and there are a lot of interesting projects here.  Here are some of my notes on what I found that was cool:

There are a lot more great videos, but I’ll stop there.  Highly recommended viewing!

June 8, 2016 at 7:26 am Leave a comment

The programming guild doesn’t want you to learn to code

Medieval guilds were associations of craftsmen who carefully protected who had could practice the craft. In the end, they faded away because (as Wikipedia describes), “the guilds negatively affected quality, skills, and innovation.” The economy grew after the guilds faded away.

The below linked article in TechCrunch is an example of programming craftsmen protecting their turf, the way that the guilds did hundreds of years ago.  I have responded to some of these complaints before, like the one that suggested that people should just be users and not programmers. “You can’t do it as well as we can” and “you’ll just make a mess of it” are the kinds of complaints that professionals have made over the centuries to keep others from adopting their practice.  Of course, both of those are correct statements, as they are true whenever you’re talking about learners.  They are correctable problems.

The below quote is particularly aggravating because it says that programming is only right for a certain “type of person.” For the technology industry, that usually equates to privileged white or Asian males.

When has it ever worked to say, “You shouldn’t learn X” especially if X is valuable and useful?

Don’t get me wrong; I do believe that engineering and programming are important skills. But only in the right context, and only for the type of person willing to put in the necessary blood, sweat and tears to succeed. The same could be said of many other skills. I would no more urge everyone to learn to program than I would urge everyone to learn to plumb.

Source: Please don’t learn to code | TechCrunch

June 6, 2016 at 7:54 am 7 comments

Growing Computing Education Research to Critical Mass at UNO and UCSD

I recently posted a piece about my personal plans for the future, and I talked about how great it would be to be at a place where there were three or more CS Ed faculty — a critical mass. Kevin rightly called me out on that in the comments, suggesting that it would be hard to get more than a couple Computing Education researchers in a US CS department. (Outside the US, there are multiple institutions with critical mass CER communities, including U. Kent at Canterbury and U. Adelaide.)

With this year’s hires, there are now two US campuses with that kind of depth! In both cases, they’re avoiding the problem Kevin describes by spreading across multiple departments, not just in CS.

University of Nebraska at Omaha: I knew that my PhD student, Briana Morrison (dissertation proposal is described here, and her award-winning ICER paper is described here) was joining (my former student) Brian Dorn (here’s a post on his dissertation) in the CS department at UNO. Then I learned that Michelle Friend (whose work with middle school girls in CS was presented at ICER 2013 and mentioned in this post) just finished her PhD at Stanford is also joining UNO in teacher education.  They are well-situated to become a (the?) major player in research on CS teacher professional development.

University of California – San Diego: Leo Porter (winner of many SIGCSE and ICER best paper awards, including work described in this post) is in CS, Christine Alvarado (who was key to the growth of women in computing at Harvey Mudd), Scott Klemmer (who gave the keynote at ICER 2012) is in the Design Lab, and Beth Simon (whom still probably has the most ICER publications of anyone) has just returned to UCSD (from Coursera) to join Education. And now, Philip Guo just announced that he’s joining UCSD in Cognitive Science. Philip built the Python Tutor that we use in our ebooks, blogs frequently on CS Ed issues, and has been publishing a ton recently (including four papers at VL/HCC last year) on issues related to learning programming.

While I’m jealous that I’m not part of a critical mass CER group, it’s a great thing for the field — more students, more CS teachers, more development and evaluation of interventions and curricula, more answers for the growing demand for computing education research, and more attention to the issues of computing education.

June 3, 2016 at 7:04 am 5 comments

Amy Ko’s sabbatical research pivot into Computing Education

Great blog post from Amy Ko on why she’s shifting into computing education research.  I hope lots of researchers come to a similar realization — that computing education is valuable, hard, and interesting.

After I stepped down as AnswerDash CTO and begin my post-tenure sabbatical, it became clear I had to pivot my research focus. No more developer tools. No more studies of productivity. I’m now much less interested in accelerating developers’ work, and much more interested shaping how developers (and developers-in-training) learn and shape their behavior.

Source: My sabbatical research pivot | Bits and Behavior

June 1, 2016 at 7:55 am Leave a comment

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

Join 9,002 other followers


Recent Posts

Blog Stats

  • 1,875,057 hits
June 2016

CS Teaching Tips