Learning is about the failure and struggle, not the success
May 10, 2012 at 9:25 am 8 comments
“It is not the result of scientific research that ennobles humans and enriches their lives, but the struggle to understand while performing creative and open-minded intellectual work.” Einstein
Several kind readers sent me links to this piece in The Chronicle, which argues that students in fields like humanities need to learn to be like computer science students, in that students learn to deal with failure. That we learn through failure isn’t a new idea. Roger Schank has talked a lot about learning through failure, and Seymour Papert connected the notion of “hard fun” (developed in his work on constructionist programming environments) to learning to write, much as The Chronicle author has. Not much gets learned from success, especially on the first draft.
Computer science is unusual among academic disciplines in that you can’t succeed without getting past an unrelenting critic with exacting standards–the computer. A program compiles, or it doesn’t. The program does exactly what you specified, not what you wanted or meant. Natural language is about engendering a meaning in the reader’s head. Roy Pea noted a long time ago (1986) that the major, language-independent “superbug” that students face in programming is that they think that there’s a mind in the computer — that they see the role of programming languages as being like natural language, that you want to give the computer the “idea” of what you want. But the computer has no mind to engender ideas in, and that’s confounding for students.
The Chronicle piece is also about the dangerous goal of avoiding failure in learning. Maybe that’s a side effect of the high-cost of education, and the desire to make each moment as productive and effective as possible. As the Einstein quote at the top points out, it’s not the success that ennobles us, but the struggle — and there is no struggle where there is no failure. The author paints an overly-optimistic picture of computer science and how they take failure “in stride.” While failure, and learning from failure, is a critical piece of computing education, it’s also the part that dissuades students from succeeding in computer science. The literature is rich with stories of students deciding that they “just can’t do computers” (low self-efficacy), and how that leads to students giving up on computer science. Successful computer science students respond to failure, and don’t find it “degrading.” But isn’t that true for students in any field?
One of the stories that we hear from teachers about Media Computation classes is that “failures” are interesting. You try to implement a particular image or audio effect, and you get something you didn’t expect. Why? It’s not a “failure” — you still got a picture or sound. But it’s not the one that you aimed for. Now, there’s a concrete artifact in front of you, with the program that generated it. Figure it out.
The real challenge, as Seymour Papert suggested back in 1981 in Mindstorms, is to change school culture. Learning should be seen as a process of “debugging,” which is just computer science speak for, “fail, then figure out why.” Computer science doesn’t have a monopoly on failure-based learning. You just can’t make progress in computer science unless you learn that attitude — and those that don’t pick up that attitude, don’t make progress.
I decided that as I sat in on a colleague’s computer-science course during the beginning of this, my last, semester in the classroom. I am moving into administration full time, and I figured that this was my last chance to learn some of the cool new digital-humanities stuff I’ve been reading about. What eventually drove me out of the class (which I was enjoying tremendously) was the time commitment: The work of coding, I discovered, was an endless round of failure, failure, failure before eventual success. Computer-science students are used to failing. They do it all the time. It’s built into the process, and they take it in stride.
via Next Time, Fail Better – Commentary – The Chronicle of Higher Education.
Entry filed under: Uncategorized. Tags: cognitive science, computing education, learning science, Logo, Papert, writing.
1.
Andy Ko | May 10, 2012 at 10:50 am
I think one possible strategy for changing how students view failure is to change who they attribute it to. Compilers tend to blame the learner and learners are quick to blame themselves. We’ve been exploring ways of reframing programming as a collaboration between the learner and the machine, where the failure is portrayed as the fault of the computer, or, at worst, a shared failure between the learner and computer:
Lee, M.J. and Ko, A. J. (2011). Personifying Programming Tool Feedback Improves Novice Programmers’ Learning. International Computing Education Research Workshop (ICER), Providence, RI, USA, 109-116
This significantly increases in engagement and possibly even learning efficiency.
Another possible strategy would be for learners to share in failures together. I’ve found that pairs of learners are much more resilient when they’re struggling together and seeing that they aren’t alone in their confusion.
2.
Jack Toole | May 10, 2012 at 12:05 pm
Is blaming the computer better? Doing so seems related to the “superbug” of thinking there’s a mind inside the computer that Mark mentions. Students in my course blame the computer (or the grading program) all the time, especially early on – and when they do, it usually means they stop trying to fix the problem. After all, they’ve done all they can, but the computer did something wrong. Does this not happen in practice (and if so, why)?
Sharing failures together sounds like a great idea though!
3.
Mark Miller | May 10, 2012 at 9:02 pm
Yep. I went through that learning stage of thinking the machine could infer what I meant by giving it a pattern of human expression. Here’s something for computer scientists to chew on. Maybe there’s a problem with the language as well if this is going on. Most of the time when it happened to me was due to the fact that in order to get the program to express anything in terms a human could understand, I had to deal with data, but I didn’t understand that the language considered code and data as different. There are languages where the distinction between code and data can blur, and I wonder if the focus was on the concept of “code as data,” where everything is executable, if this confusion would be lessened.
As much as I can see validity in the argument that computer science students take failure as a matter of course, there are areas where failure is avoided. The watchword for this avoidance is “impractical.” I think something both computer science and the humanities could learn is to recognize weak arguments (this skill I think is stronger in CS than in the humanities as they currently exist in academia, though the distinction still gets missed rather often in CS).
4.
Repeated failure is not a goal « Gas station without pumps | May 12, 2012 at 1:42 am
[…] Mark Guzdial’s comments on Krebs’s article, he echoes this notion: Computer science is unusual among academic disciplines in that you can’t […]
5. Mind Article : Its OK to fail (But not OK to give up). | mindbeingfit | May 22, 2012 at 12:47 pm
[…] Learning is about the failure and struggle, not the success (computinged.wordpress.com) […]
6.
What the Rich Know That Others Don’t « L.E.G.A.C.Y. | June 22, 2012 at 12:10 pm
[…] Learning is about the failure and struggle, not the success (computinged.wordpress.com) […]
7.
Interaction between stereotypes, expectations of success, and learning from failure | Computing Education Blog | July 23, 2013 at 1:32 am
[…] stereotypes about scientists and other professionals in STEM fields. So there are not just cognitive benefits to learning from failure, but there are affective dimensions to focusing on the struggle (including failures) and not just […]
8.
Task Specific Programming will only matter if it solves a user’s problem (Precalculus TSP Part 4 of 5) | Computing Education Research Blog | September 30, 2019 at 7:00 am
[…] would you have a deeper sense of what programs did (e.g., would you know that there is no Pea-esque “super-bug” homunculus)? Would you have a new sense for what the activity of programming is about, including […]