Being Smart Considered Harmful

Ben Chun is a Computer Science teacher at Galileo Academy of Science & Technology in San Francisco. He teaches classes in the Academy of Information Technology (AOIT), including AP CS courses. This past December, he encountered Scratch on a visit to UC Berkeley for CS Ed Day with his 11th graders. Soon afterwards, he developed his first Scratch activity for his 10th grade students - inspired by the Giants' World Series win.

The following is taken from an article that Ben recently posted on his blog, And Yet It Moves...

Last weekend I had the opportunity to give a talk about computer science education to a group of non-CS teachers through the KCI MERIT program. My pitch was: Scratch should be used in all subject areas to teach an iterative problem-solving approach in which revision — and failure — is a natural part of the process. This philosophical angle is cribbed directly from Papert (as articulated in his book Mindstorms). He writes:

"[M]any children are held back in their learning because they have a model of learning in
which you have either “got it” or “got it wrong”. But when you learn to program a computer
you almost never get it right the first time. Learning to be a master programmer is learning
to become highly skilled at isolating and correcting “bugs,” the parts that keep the program
from working. … If this way of looking at intellectual products were generalized to how the
larger culture thinks about knowledge and its acquisition, we all might be less intimidated
by our fears of "being wrong"." (p. 23)

As I read that paragraph, I thought back to 2007 and my first encounter with Carol Dweck’s research. What she (and Claude Steele) have added to Papert’s line of thinking from 1980 is proof that priming has a major impact on the type of model a person adopts when approaching a problem. We’re all capable of switching between multiple models — and you might even say we are highly susceptible to being switched into a given model based on subtle differences in how a challenge is presented. Papert, from Mindstorms again:

"School teaches that errors are bad; the last thing one wants to do is pore over them,
dwell on them, or think about them. The child is glad to take advantage of the computer’s
ability to erase it all without any trace for anyone to see. The debugging philosophy
suggests an opposite attitude. Errors benefit us because they lead us to study what
happened, to understand what went wrong, and, through understanding, to fix it.
Experience with computer programming leads children more effectively than any other
activity to “believe in” debugging." (p. 114)

Scratch supports this at an infrastructure level through built-in functions for sharing projects online and automatic tracking of remixes. Every project can be improved or branched. We can all improve on our own work, and we can all help each other explore new ideas. We need to be able to start with an initial effort, knowing it will take more work to create a finished product and knowing that’s okay. This is exactly what we want students to do when they revise an essay in English class; it is exactly what we want students to do when they use data to formulate a new hypothesis in science class. And it is exactly what professional computer programmers do all day long.

In Scratch, we have a tool that supports the growth mindset and the process of iterative improvement. All we have to do is not screw it up. But that turns out to be a harder than it looks. Talking about accomplishments and intellect in the vocabulary of the fixed mindset (“she’s very smart,” or, “he’s one of those kids that gets it right away”) is incredibly common even among teachers who know the research.

For example, at a recent CSTA meeting at UC Berkeley we were discussing prerequisites and placement for various programming classes. Can you do this or that in 8th grade? Can a student go directly into some second-semester course without taking the first? A number of us, myself included, said things like, “Well, if the student is smart and has a strong intuitive understanding, then of course you can let them skip ahead.”

Grad student Colleen Lewis then warned us that she was going to get on her soapbox and proceeded to do an outstanding job reminding us about the dangers of this way of talking. She pointed out that if we use fixed-mindset descriptions of ability, we’re not helping anyone — the students we think we are describing positively are actually harmed. And we’ve all had experiences where students who were initially lost turn out to be much stronger in the long run because they figure out how to learn the subject early on instead of just magically knowing the answer.

This was a really important reminder for me to be mindful about how we talk about programming and computer science. Through our choices of language, we are literally programming ourselves and each other. We can be condescending just by being careless. So how can we avoid these mistakes? I’m going to start by trying to think and talk more about problem-solving skills rather than “intelligence”.

• A student is doing a good job digging in to a problem.
• A student is doing a good job deepening their investigation.
• A student is doing a good job analyzing a situation to find new approaches.
• A student is doing a good job upgrading their skillset.

Aren’t these all so much more important than just being smart?