Audrey does an excellent job of describing the big trends in learning to code this last year, from CodeAcademy to Bret Victor and Khan Academy and MOOCs. But the part that I liked the best was where she identified the problem that cool technology and badges won’t solve: culture and pedagogy.

This is a problem. A big problem. A problem that an interactive JavaScript lesson with badges won’t solve.

Two organizations — Black Girls Code and CodeNow — did hold successful Kickstarter campaigns this year to help “change the ratio” and give young kids of color and young girls opportunities to learn programming. And the Irish non-profit CoderDojo also ventured state-side in 2012, helping expand afterschool opportunities for kids interested in hacking. The Maker Movement another key ed-tech trend this year is also opening doors for folks to play and experiment with technologies.

And yet, despite all the hype and hullaballoo from online learning startups and their marketing campaigns that now “everyone can learn to code,” its clear there are still plenty of problems with the culture and the pedagogy surrounding computer science education.

We still do need new programming languages whose design is informed by how humans work and learn. We still do need new learning technologies that can help us provide the right learning opportunities for individual student’s needs and can provide access to those who might not otherwise get the opportunity. But those needs are swamped by culture and pedagogy.

What do I mean by culture and pedagogy?

Culture: Betsy diSalvo’s work on Glitch is a great example of considering culture in computing education. I’ve written about her work before — that she engaged a couple dozen African-American teen men in computing, by hiring them to be video game testers, and the majority of those students went on to post-secondary education in computing. I’ve talked with Betsy several times about how and why that worked. The number one reason why it worked: Betsy spent the time to understand the African-American teen men’s values, their culture, what they thought was important. She engaged in an iterative design process with groups of teen men to figure out what would most appeal to them, how she could reframe computing into something that they would engage with. Betsy taught coding — but in a different way, in a different context, with different values, where the way, context, and values were specifically tuned to her audience. Is it worth that effort? Yeah, because it’s about making a computing that appeals to these other audiences.

Let me give you an example with graphs that weren’t in Lauren Margelieux’s paper, but are in the talk slides that she made for me. As you may recall, we had two sets of instructional materials: A set of nice videos and text descriptions that Barbara Ericson built, and a similar set with subgoal labels inserted. We found that the subgoal labelled instruction led to better performance (faster and more correct) immediately after instruction, more retention (better performance a week later), and better performance on a transfer task (got more done on a new app that the students had never seen before). But I hadn’t shown you before just how enormous was the gap between the subgoal labelled group and the conventional group on the transfer task.

Part of the transfer task involved defining a variable in App Inventor — don’t just grab a component, but define a variable to represent that component. The subgoal label group did that more often. ALOT more often.

Lauren also noticed that the conventional group tended to “thrash,” to pull out more blocks in App Inventor than they actually needed. The correlation between number of blocks drawn out and correctness was r = -.349 — you are less likely to be correct (by a large amount) if you pull out extra blocks. Here’s the graph of number of blocks pulled out by each group.

These aren’t small differences! These are huge differences from a surprisingly small difference between the instructional materials. Improving our pedagogy could have a huge impact.

I agree with Audrey: Culture and pedagogy are two of the bigger issues in learning to code.

[…] piece in our C21U newsletter, suggesting that pedagogy is more important than the MOOC technology. How we teach is much more important for dramatic impacts on learning, than aiming for scale via […]

(*) [pacing] How can a self-study student gauge their progress? When is it time to move on?
(*) [parroting] How can a self-study student distinguish between useful (deep) and non-useful (trivial) understandings?
(*) [fundamentals] How can a self-study student recognize when it’s appropriate to review prior material?
(*) [jargon] How can a self-study student recognize and resolve conflicting contexts? (for example: x=y+1 and x=sin(y), or Hippocrates of Chios and “the other” Hippocrates)

Or, perhaps: how can we teach people to recognize that a complex understanding of an issue typically means a lack of understanding – that understanding an issue makes the issue seem simple? And, how can we tolerate the complexities? [There’s no point in learning things you already understand, but in some subjects significant details have been lost in the fog of history while in other subjects far more detail is available than anyone has time to appreciate.]

Anyways, I think my point here is that I do not disagree that pedagogy is important, but I think I am also not seeing a fundamental conflict between developing pedagogy and developing MOOCs. I agree they are different, but I think areas of focus can usefully inform the other areas. That said, I think I would also agree that MOOCs, and current approaches to pedagogy both currently contain deep flaws.

[…] An interesting though somewhat sad story from a school-age girl (probably high school level?) about why she’s not interested in Information and Communications Technology. A good part of her story has to do with self-efficacy — how do you get better at this? […]