Skip to content
March 12, 2011 / Ben Chun

Being Smart Considered Harmful

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?

5 Comments

Leave a Comment
  1. Michelle Chung / Mar 14 2011 7:25 am

    Hi Ben,

    I was happy to find out about your blog post this morning. It was forwarded to me by another member of the Scratch Team. It’s thoughtfully written and a wonderful reminder. I also really enjoyed reading about your class on the Galileo site. I’d be interested to hear more about your work with your students.

    I couldn’t help but think how this would be great to share as a resource for other Scratch educators. Would you consider posting this post and any of your work with Scratch at Galileo on the ScratchEd site (scratched.media.mit.edu)?

    Thanks,
    Michelle (on behalf of the ScratchEd Team)

  2. Ziad Baroudi / Mar 15 2011 1:40 am

    Wonderful article. I can only endorse your view that debugging is a better approach than “either get it or not.” scratch is a great tool to get students programming and debugging.

  3. Wesley Fryer / Mar 22 2011 11:55 am

    Thanks for this encouragement to revisit Papert’s work– I’ve read “The Children’s Machine” but not Mindstorms, and need to. I agree Scratch challenges the traditional paradigm of learning in schools in many fundamental, and GOOD ways. I’ve used Scratch with my pre-service students at UNT last term and UCO this semester. It’s the best thing we learn… because, as you say, it’s not just about getting the right answer. It’s eye opening and perhaps a bit amusing to see how many students recoil against this. Many prefer spoon-fed, traditional instruction.

    I’ve created a page of Scratch resources and wonder if there’s anything else you’d add to this, based on your use and knowledge of Scratch? It’s on:

    http://wiki.wesfryer.com/t4t/resources/scratch

  4. gasstationwithoutpumps / Mar 26 2011 8:28 am

    I agree that Scratch provides a good tool for students to learn debugging skills, and that those skills apply to many other tasks than just programming. I’m not sure that Scratch should be used “in all subject areas” though. That sounds too much like “all I have is a hammer, so everything looks like a nail.”

    Be careful not to go too far in backing off from praising skill: already many smart kids have internalized that being smart is bad and they are backing off on showing their ability, lest they be shunned by peers and teachers.

    Both effort and achievement are worthy of praise. Rewarding one and not the other results in the undesirable avoidance of the other. We want students to put forth effort and achieve, not just the first.

Trackbacks

  1. DML 2012 « And Yet It Moves

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: