Archive for December, 2012
(Thanks to Beth Simon for pointing this out to me!) A new paper from Carl Wieman reviewing the literature on science education is always worth reading, but the one linked below is particularly useful to us in computer science. One of the issues that Carl addresses in this paper is whether competitions and other informal science learning efforts really do help with student learning. We do have a lot of different kind of competitions in computing education, from the First Robotics league to the USA Computing Olympiad. His finding (quoted below): “there is little evidence that such programs ultimately succeed, and some limited evidence to the contrary.”
We use competitions in “Georgia Computes!” but for a very different purpose, not considered in Carl’s analysis below. As he points out later in the article, most efforts at improving teacher quality through in-service workshops fail because the teachers don’t have enough STEM knowledge to begin with, and content knowledge precedes pedagogical content knowledge. What Barbara Ericson has found is that competitions inspire the teachers to learn more. Competitions inspire students, but even more, teachers are inspired to learn in order to support their students. When we have Alice or Scratch competitions, teachers start showing up for our Alice and Scratch professional development, because they want to learn in order to help their students. While the impact of the competitions on the students might be short-lived, I would love to see some measure of the longer-term impact on the teachers.
Competitions and other informal science programs: Attempting to separate the inspiration from the learning. Motivation in its entirety, including the elements of inspiration, is such fundamental requirement for learning that any approach that separates it from any aspect the learning process is doomed to be ineffective. Unfortunately, a large number of government and private programs that support the many science and engineering competitions and out-of-school programs assume that they are separable. The assumption of such programs is that by inspiring children through competitions or other enrichment experiences, they will then thrive in formal school experiences that provide little motivation or inspiration and still go on to achieve STEM success. Given the questionable assumptions about the learning process that underlie these programs, we should not be surprised that there is little evidence that such programs ultimately succeed, and some limited evidence to the contrary. The past 20 years have seen an explosion in the number of participants in engineering-oriented competitions such as First Robotics and others, while the fraction of the population getting college degrees in engineering has remained constant. A study by Rena Subotnik and colleagues that tracked high-school Westinghouse (now Intel) talent search winners, an extraordinarily elite group already deeply immersed in science, found that a substantial fraction, including nearly half of the women, had switched out of science within a few years, largely because of their experiences in the formal education system. It is not that such enrichment experiences are bad, just that they are inherently limited in their effectiveness. Programs that introduce these motivational elements as an integral part of every aspect of the STEM learning process, particularly in formal schooling, would probably be more effective.
The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.
Here’s an excerpt:
About 55,000 tourists visit Liechtenstein every year. This blog was viewed about 180,000 times in 2012. If it were Liechtenstein, it would take about 3 years for that many people to see it. Your blog had more visits than a small country in Europe!
ACM Technews this week included this article about “Software Companies begging for Qualified Job Candidates“:
The big challenge facing the U.S. software industry might not be the economy, looming fiscal cliff or growing competition. First things first — the companies are begging for qualified job candidates.
Software firms say the U.S. isn’t producing enough qualified engineers and tech salespeople.
“I’d say that has been the industry’s biggest problem in the past year,” said Jeff Winter, chief executive of GravityPeople, a tech recruiting firm. “You have a harder time finding and hiring people for open positions.”
And then includes the article below about how very few women there are in the computing industry. Uh, folks? You’re not engaging 50% of the population — fixing that might help with the labor problem?
Women, however, account for just 6 per cent of the chief executives of the top 100 technology companies in the US, and just 22 per cent of the IT workforce overall, according to the National Center for Women & Information Technology. In the UK, women make up just 17 per cent of technology professionals, according to e-Skills, an organisation that promotes technology learning.
Moody’s is joining with others predicting that MOOCs will damage smaller schools and will benefit the largest universities. Sounds like a form of the MOOCopalypse. Interesting that they see the elites as doing well under MOOCs — the rich get richer.
A new report by Moody’s Investors Service suggests that while MOOCs’ exploitation of expanded collaborative networks and technological innovation will benefit higher education in the United States as a whole, their long-term effect on the for-profit sector and smaller not-for-profit institutions could be damaging.
The report suggests that institutions with the strongest brand identities will experience the most positive credit impacts from the new platform, although it predicts national universities will benefit more than those with a global presence.
I did a Blog@CACM post on the value of combining Education and Engineering. I was impressed by my visit to Tufts’ Center for Engineering Education and Outreach. Then when I got back to Georgia Tech, I attended a meeting that was explicitly asking, “What should the relationship be between Engineering and Education?” Thus, this blog post, where I argue that the relationship is important and deep, and benefits each.
I mentioned in a previous blog post the nice summary article that Audrey Watters wrote (linked below) about Learning to Code trends in educational technology in 2012, when I critiqued Jeff Atwood’s position on not learning to code.
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.
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.
Pedagogy: A lot of my work these days is about pedagogy. I use peer instruction in my classrooms, and try out worked examples in various ways. In our research, we use subgoal labels to improve our instructional materials. These things really work.
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.
Audrey Watters’ excellent post on Learning to Code in 2012 pointed me to Jeff Atwood’s piece (linked at the bottom). I want everyone to learn code, so I am in direct contradiction to his position, “Please don’t learn to Code.” Jeff and I disagree primarily on two points, both of which are issues of definition:
- Most people who write code are not trying to create code solutions. Most people who write code are trying to find solutions or create non-code solutions. By “most people,” I do mean quantitatively and I do mean all people, not just professional programmers. We know that there are many more people who write code to accomplish some task, as compared to professional programmers. When I visited the NASA Goddard Visualization Lab last month, I met the director Horace Mitchell, who told me that everyone there writes code, whether they are computer scientists or not. They write code in order to explore their data and create effects that they couldn’t given existing visualization systems. They are trying to create great visualizations, not great code. They simply throw the code away afterward. This is a critical difference between what Jeff is describing and what I hope to see. We agree that the goal is a solution. I want everyone to have the possibility of using code to create their solution, not to create code as the solution.
- Most people who program are not and don’t want to be software developers. Most of the people that I teach (non-CS majors, high school teachers) have zero interest in becoming programmers. They don’t want to be “addicted to code.” They don’t want a career that requires them to code. They want to use coding for their own ends. Brian Dorn’s graphic designers are a great case in point. Over 80% of those who answered his surveys said “No, I am not a programmer,” but everyone who answered his surveys wrote programs of 100 lines or more. Not everyone who “programs” wants to be known as a “programmer.”
The problem is that we in computer science often have blinders on when it comes to computing — we only see people who relate to code and programming as we do, as people in our peer group and community do. There are many people who code because of what it lets them do, not because they want the resulting code.
“You should be learning to write as little code as possible. Ideally none.” And people who want to do interesting, novel things with computers should just wait until a software developer gets around to understanding what they want and coding it for them? I could not disagree more. That’s like saying that the problem with translating the Bible is that it made all that knowledge accessible to lay people, when they should have just waited for the Church to explain it to them. “Please don’t learn to code” can be interpreted as “Please leave the power of computing to us, and we’ll let you know when we’ll make some available to you.”
It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can’t get behind that. You should be learning to write as little code as possible. Ideally none.
It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.