Why there’s no such thing as an ‘F’ in computer science: The Fear Factor in CS (and other things we learn)

February 2, 2015 at 8:19 am 13 comments

Nice article by my colleague Ayanna Howard and Oracle’s Alison Derbenwick Miller. I’m teaching Media Computation again this semester, and it seems to me that the biggest barrier for my students is simply fear. They don’t type code because they’re afraid of failure. They don’t try to understand the code because they’re afraid they can’t.

It’s not just CS, of course. At my last ukulele meetup, I sat next to a woman who brought her ukulele, but wouldn’t take it out of the case. She just sang the songs along with us. When I encouraged her to bring it out, she said, “I’m just a beginner. I’ll learn to play it first, then I’ll play along.” That gets the process wrong — it’s playing along that leads to learning to play it. But I was struck by her body language and voice when she made the statement. She was deeply frightened — of making mistakes and being ridiculed for it, I guess.

I get that. I did my first public performance singing and playing the ukulele in December. (Christmas carols are pretty easy, and are completely acceptable at a December open mic night.) I was so frightened. I finished one song (“Silent Night”), then invited my daughters up to sing with me (“Jingle Bells”) to help me get through it (thanks to them for the support!), but still couldn’t get past one verse. My legs and arms were shaking so badly I didn’t think I could go on. Fear is powerful.

Ayanna and Alison point out something important and real that we have to help students get past.

They will give you myriad reasons, among them that the work just isn’t interesting, that the cool kids don’t do it, and fear – fear it’s too hard, fear they’ll be ridiculed as “nerds,” fear of being exposed as an intellectual fraud, or ironically, as the “too smart kid,” fear of failure.

Fear is an awful thing. It’s a four-letter “f” word that holds incredible power – power to keep us from doing what is good, what is right. Power to stop us from taking risks. Power to maintain the status quo, to stop disruption, to inhibit change. Power to stymie innovation, and to limit opportunity.

Fear is bad. Fear stands between us and a better world. It stands between us and our better selves.

via Why there’s no such thing as an ‘F’ in computer science | The Hechinger Report.

Entry filed under: Uncategorized. Tags: , .

GenderIT Conference at Penn: Papers due Feb 20 Could our CS enrollment boom and bust cycle be the result of inability to manage the boom?

13 Comments Add your own

  • 1. Michael Lee  |  February 2, 2015 at 8:49 am

    Great post! We also have to remember that fear doesn’t only affect novices, but also those who might be quite experienced and successful. If you haven’t already, check out Mark’s other post about She++ here: https://computinged.wordpress.com/2013/08/02/she-the-documentary-and-the-audience/

    And another good read of a first-hand account from a successful computer scientist feeling the imposter syndrome: https://medium.com/the-year-of-the-looking-glass/the-imposter-syndrome-9e23e2326d88

    Reply
  • 2. Moti Ben-Ari  |  February 3, 2015 at 1:58 am

    I like the following passage in the article: “But the immediate evidence of failure is likely much higher. A program runs, or it doesn’t.” Educational theories like constructivism support “negotiation of meaning” between the students and the teacher. Since you can’t negotiate with a compiler🙂, CS is profoundly different from other subjects. Even in math, you can negotiate the adequacy of a proof, and get partial credit on an exercise if your method is correct but you make a simple arithmetic error. It follows that dealing with “failure” must be a central subject of introductory CS. Cf. the currently running MOOC on edX “MITx: 6.00.1x Introduction to Computer Science and Programming Using Python,” where the entire “Lecture 7” is devoted to debugging.
    Moti

    Reply
    • 3. Mark Guzdial  |  February 3, 2015 at 8:52 am

      I disagree from a couple of perspectives, Moti. For one, we don’t have to have “failure” as starkly as you describe. Mike Lee and Andy Ko have a fabulous paper from ICER a couple of years ago where changing the personification of the compiler significantly improved novice learning. Instead of complaining “Unrecognized token,” the compiler apologized for not being able to understand the program. In MediaComp, we rarely have “failure.” Instead, the effect is different than what we wanted. It does become a negotiation process, more bricoleur than top-down planner (in Turkle and Papert terms).

      Second, I’m not sure that we can teach debugging mid-CS1. DuBoulay told us a long time ago (and Juha Sorva repeated it just a few years ago) that the main goal of CS1 is to develop a notional machine that one can run mental models of the program on. Until you have a notional machine, you can’t learn to debug.

      Reply
      • 4. gflint  |  February 3, 2015 at 11:02 am

        Looks like we need a concrete definition of “debug”. To me teaching debugging is one of the primary goals of programming. Debugging is part of the problem solving loop. Knowing to throw in a few Print statements to trace the flow, using the IDE debugger (if there is one), writing the program in such a manner that it is easy to debug (good variable and sub procedure names, using sub procedures, encapsulation) I consider part of debugging.

        Reply
        • 5. Mark Guzdial  |  February 3, 2015 at 1:05 pm

          I teach the same techniques, but the goal is to understand the system. When the system doesn’t behave as you expected (or desired), the reaction I want to encourage is, “Huh — I wonder why it’s doing that.” It’s about having a learning goal versus a performance goal (see discussion here).

          The language we use matters. All of my doctoral training was in a learning and cognitive science tradition, but for the last ten years, I’ve focused much more on motivation. The framing we use, the objectives we encourage, and the context we wrap around what we teach matters. Teaching “coding to spec” and “debugging” is a traditional software engineering framing. My students don’t aim to be software engineers. Most of our students in intro CS are not particularly interested in a software engineering context.

          Seymour Papert would say that it’s not a bug. It’s an opportunity to learn.

          Moti, you wrote:

          For example, the attempt to develop a notional machine for variables based upon boxes leads to students thinking that a variable can contain multiple values.

          Do we have evidence of that?

          Reply
          • 6. gflint  |  February 3, 2015 at 4:38 pm

            Makes sense. I love it when the kids get bugs in their program. They have to think instead of code. The hair pulling, gentle cursing,and throwing of small objects all leads to the learning goal. I saw a quote the other day “Four hours of coding can save 15 minutes of planning”. It address exactly how the kids want to operate. A bug puts the brakes on them and makes them step back and look at what they are doing or have done.

            Reply
            • 7. motibenari  |  February 4, 2015 at 11:02 am

              I love the quote “Four … planning” and I’d like to use it in a lecture. Do you have a reference for it so that I can give proper attribution?

              Reply
              • 8. gflint  |  February 4, 2015 at 1:49 pm

                I picked it off a blog somewhere. No idea where.

                Reply
          • 9. motibenari  |  February 4, 2015 at 10:58 am

            I asked Ronit Ben-Bassat Levy. She says that she has frequently encountered this misconception in her teaching. Empirical evidence can possibly be found in an MSc thesis by Dalit Levy at the Technion: Metaphors in Computer-Science Teaching, but that’s from 1992 and I couldn’t find a copy online.

            Reply
            • 10. Mark Guzdial  |  February 4, 2015 at 11:19 am

              Thanks! Juha Sorva has a wonderful appendix in his thesis where he lists misconceptions identified in the literature. He lists the “A variable can hold multiple values at a time” misconception, but doesn’t associate it with the “variable is a box” explanation.

              Reply
          • 11. Bri Morrison  |  February 17, 2015 at 12:38 pm

            I’m not sure there’s “evidence” of when the box metaphor breaks down, but I believe it was first identified by duBoulay.

            Reply
      • 12. motibenari  |  February 3, 2015 at 12:05 pm

        Hi Mark,

        “the effect is different than what we wanted”. This is precisely how I would define a “bug”!! As someone once said: The only difference between a bug and a feature is that the latter is documented. You can solve a bug by changing either the program or the specification, but a bug is still a bug.

        Yifat found that high-school students were not particularly bothered by the existence of bugs (see: Y. Ben-David Kolikant, M. Ben-Ari. Fertile zones of cultural encounter. Journal of the Learning Sciences 17(1), 2008, 1–32), but I don’t think that professionals and educators can agree.

        As to your second point: the notional machine has to “faithfully” represent the actual machine and the mental model of the notional machine has to be “viable”. If either of these conditions is not fulfilled the notional machine / mental model must be debugged. For example, the attempt to develop a notional machine for variables based upon boxes leads to students thinking that a variable can contain multiple values. This is clearly a bug in the notional machine. If personification helps, that is great, but a bug is still a bug.

        Reply
      • 13. KDecker  |  February 4, 2015 at 9:54 am

        Just another example of rejecting stark “failure”: the Program by Design (HTDP) approach explicitly gives intermediate, objectively gradable outputs (from the Design Recipe) between a problem statement and a final running program. So there are very objective amounts of partial credit available. I always tell my intro CS students they can barely pass my course without ever writing a fully working program. [Conversely, you might also barely pass if you DONT do the intermediate steps and ONLY give us a working program]

        That might be shocking, but IN PRACTICE it doesn’t happen: students who understand the intermediate gradable steps quickly see that the final working program is (usually) a trivial jump from the last step.

        Reply

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

Trackback this post  |  Subscribe to the comments via RSS Feed


Recent Posts

February 2015
M T W T F S S
« Jan   Mar »
 1
2345678
9101112131415
16171819202122
232425262728  

Feeds

Blog Stats

  • 1,293,462 hits

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 4,598 other followers

CS Teaching Tips


%d bloggers like this: