Lost in syntax part 2 (or: OMG I'm going to cry in front of all these people)

So as I said, Tuesday afternoon and Wednesday were okay. I was kind of learning some things, but I was also getting frustrated because I didn’t feel like I understood what was going on. I take excellent, copious notes, but I felt like I was being given plug-and-chug code. They’d give code examples in lecture, pointing at parts and saying, “this part does this thing” and then we’d go to the lab and face a very similar question. Simple substitution, figure out what operator to put where, and Bob’s your uncle, you’ve got working code. I kept trying to say (mostly to my peers, not to the teacher) that I didn’t feel like I understood the big picture, but I didn’t know what to ask and I had working code, so what’s the problem? I did ask the teacher some questions, but they were usually pretty specific and definitely not of the “I don’t think I understand anything that’s going on” variety. Especially since I clearly DID understand some of what was going on, I just couldn’t generalize it. I felt like I didn’t ‘get it’ but other than saying that I felt like I had no context, I couldn’t articulate what I meant.

OBJECT LESSON 5: Your students won’t necessarily come to you for help, even when they should.

OBJECT LESSON 6: Some of your students are inductive learners and some are deductive learners. It’s a good idea to try to present material in multiple ways, since some of them probably won’t understand what you’re talking about the first way you say it.

Thursday morning, we started working on stuff where a lot of people in the room had significant prior experience, while I have almost none. So we went from “you’re all experienced programmers” to “you all know this” when for me, that was completely false. Now, I wasn’t alone, and some people were asking questions, but mostly I just wrote everything down and figured when I got to lab, I could plug-and-chug the code like I’d been doing, since that seemed to be how this all works.

The key with plug-and-chug is that you either need some idea of what you’re plugging or you have to have truly perfect notes. I had neither. I had typos, I had things I’d missed copying. Syntax error after error after error, none of which mean anything to me. Also, the TAs for the course were largely busy, and instead of needing an occasional pointer, I needed someone to sit next to me and debug my code. Even going and asking my friend only made things worse – he was really nice about explaining it, but the overwhelm had shut me down again.

Indeed, I figured out much later that I actually DO have some experience with what we were being asked to do, but in my panic, I forgot all of it, or that I even should know it.

OBJECT LESSON 7: Just because your students have successfully done something in the past doesn’t mean they’re going to be able to do it right now, without extra support. (Note: sometimes they’re being lazy – in the bad way – so choose your response with care.)

Example: I talked to the parents of an 8-month-old who recently learned to sit up. The problem is, when she learned to sit up, she forgot that she knew how to lie down, so she would sit up, want to not sit up anymore, and start wailing because she didn’t know what else to do. They’re hoping she re-learns how to lie down again before they lose their minds from lack of sleep.

After lunch on Thursday, my friend and I ended up in some conversation about the material and my understanding or lack thereof. Suffice it to say that he finally figured out that I had absolutely no conceptual understanding of the material. The conversation was mockable. He wanted me to describe linguistically how to solve some of the programs I’d coded. I would say, “well, in [language]…” and he’d respond, “not in [language]. How would you DO it?” I had no idea how to describe what I’d programmed.

OBJECT LESSON 8: Just because your students can do something, it doesn’t mean they understand what they’re doing. I’ve had lots of students say, “I don’t understand” and my response was, “but look, you can DO it!” Doing isn’t the important part, understanding is. Doing is important in the workplace. Understanding is important in school. If they understand, then likely they’ll be able to do at some point.

In 15 minutes, my friend explained the big picture, the most fundamental concept relating to everything we’d learned, using quasi-programming examples. It was concrete, it was clear, and I got it.

OBJECT LESSON 9: It’s important to explain the big picture and talk about why some of the language constructs are the way they are. Hopefully you’ve chosen the language you have because it does the things you’re trying to do well. Why is that? How should students be thinking about the problems they’re trying to solve with their code? What’s the context for the code?

My friend, consummate teacher he is, kept quizzing me for the rest of the workshop, even on things that were hard, and once I got it, I was able to keep getting it. I started going back to re-do the exercises, understanding what’s happening without fear. I still probably won’t switch languages, but I’m willing to try some things and continue giving it a chance.

My friend would want me to give you the final object lesson:

OBJECT LESSON 10: Stop thinking it’s hard. My friend is convinced that a major barrier to my understanding is I’d been told how hard these concepts are and what a hard time I’d have understanding them. He’s convinced that my fear got in the way of learning. How often do we transmit to students that things are hard and they’ll probably have trouble? Self-fulfilling prophecies can be profound barriers to learning.

One thing I’m going to do is describe this experience to my students at the beginning of the year. I know that some of them get overwhelmed like I did, I know some of them end up feeling much more stupid than they are, and I suspect some of them end up feeling bad about CS when really they’re just not ready or I’m not teaching it the right way to them. If nothing else, I hope that telling them this story will let them know how much empathy I have for them.

Lost in syntax part 1 (or: OMG I'm going to cry in front of all these people)

I’ve spent the week at a workshop, learning a programming language. It’s been quite an instructive experience, full of object lessons on what computer science is like for some of my students. (I want to note that the workshop teachers and organizers were lovely and in general I do not blame them for what happened.)

The first day was great. This language has some terrific features, particularly for thinking about math. I could see how it would be a better fit for certain applications than anything else I’ve seen. I could feel my brain starting to think in interesting new ways that will make me a better programmer in any language. I felt really optimistic.

The first night, I got in a huge fight with my husband. This is relevant because it meant that I started Tuesday in a not-good place emotionally, which had nothing to do with the workshop. Think your student’s personal lives don’t affect their performance in your class? HA.

OBJECT LESSON 1: Students bring their lives into the room with them. Their experience can vary dramatically from day to day for reasons that have nothing to do with you, but will affect their performance and behavior when they’re with you.

Tuesday started okay. The material was getting more complex, but I was keeping up. There was a little recursion, but they don’t call it recursion, the instructor just said “you’re experienced programmers, you know what that is” and I wondered what it was, until someone else called it recursion and I could see it. Oh, okay. I’ve never actually programmed recursion, but I was still feeling like I could figure it out.

Then she used a construct she had used the day before, in a way that the mental model I’d created of what that construct meant didn’t work. And everyone nodded. And I didn’t know what it meant. And for a minute or two, that was okay, because hey, I was sure I could figure that out too. Only she kept using it. First, I was distracted, because I kept trying to figure out what the code meant. Second, you can’t do recursion without this thing. And I was still not figuring out what it means. I started realizing that if her use of this thing makes sense (and I trust it does) and I can’t fit it into my mental model of this construct, then my mental model must be wrong. Which means I didn’t actually understand anything yesterday, and in fact haven’t understood anything after the first hour.

At which point my brain completely shut down. Oh, I kept taking notes, in between trying hard not to cry, because oh my god, I really am as dumb as I have ever feared.

OBJECT LESSON 2: A student who gets upset stops thinking. The more upset they are, the less thinking they can do. While they’re coping with all these overwhelming emotions, if you’re moving on, they might as well be absent.

THOUGHT EXERCISE 1: On students walking out of class. This is only the second time in my life that I’ve almost walked out of a class because what was happening in the room was so terrible for me that I couldn’t cope. I don’t leave because I find it unacceptably rude to the lecturer. I know some teachers who disagree and freely allow students to come and go when they need a break.

At the break I went and asked the teacher about my original point of confusion, and we worked out an explanation I could accept. Why didn’t I ask during the lecture? Because everyone else seemed to get it and no one else was asking any questions. I usually ask even in those situations, but it was compounded by the fact that she kept telling us how experienced we were, and I kept feeling like a fraud because I don’t consider myself an experienced programmer at all. (Can you say “imposter syndrome”?)

OBJECT LESSON 3: Just because many students appear to understand the material, doesn’t mean they all do. Make sure your class culture encourages student questions and not just student answers. Imagine how much faster I would have recovered if I had just asked what that word meant right away.

OBJECT LESSON 4: What you think is a complement (“you’re an experienced programmer”) isn’t necessarily heard positively. The best complements are direct, specific, and personal. In this case, I think she was using “you’re experienced programmers” to mean “I’m not going to teach you something important here” which would have been easier for me to hear.

At lunch, I spent a while talking to a friend who further clarified the material, while carefully standing far enough away that if I started crying he wouldn’t get wet. (It isn’t an object lesson, but if a colleague is on the verge of tears, it is okay to give them a hug. Or maybe that’s only true at the hippy-dippy school where I work, but I’ve literally provided a shoulder to cry on more than once.)

By the end of lunch, I felt better. Tuesday afternoon and Wednesday went back to being okay. I felt pretty confident that the storm had passed, though things weren’t quite sunny yet.

In fact, Wednesday night I went out to dinner with a long-time friend who has nothing to do with CS Ed, we spent four hours catching up and gossiping, and I felt so happy and glad to be out of thinking about CS for a while. I was sure Thursday was going to be the opposite of Tuesday. But that is fodder for a second post...

Subvert the dominant paradigm

Earlier this week, Alfred Thompson posed the question, "what would you do if the lights (and power) went out in your computer science classroom?" At nearly the same time, I was interviewed about "computer science tools" as part of someone's dissertation research. One of the questions was, "if you had to choose only one tool to work with and couldn't have any others, which would you choose?"

Both Robb Cutler and Chad Clites have the best answer: use pencil and paper.

I am saddened to admit this was not my first answer.

The dominant paradigm of computing education is to teach technology. In the APCS course, are we really teaching the major concepts of computer science? Or are we really teaching Java, and using some of those concepts along the way? It's endemic in the way we talk about our curriculum. We teach "programming with Alice" or "simulations with Flash". If we're teaching simulation-building, why does it matter what tool we use? But we get caught up in the tools, partly because we tend to love them, and the concepts and ideas become, at best, co-equal, and more often subsumed in importance.

The reality is that my current curriculum would not move forward without power. I've faced this problem repeatedly over the last three years and it hasn't been pretty. Last year I spent the first week of school without access to my classroom, having to teach outside. So instead of starting the "real" curriculum (animation with Flash), I did CS Unplugged activities. Sure, I think my students got something out of learning about sorting and searching. But the reality is that the lessons were totally disconnected from the curriculum. The ideas weren't reinforced throughout the year, the concepts weren't connected to anything else they learned, and I suspect that few of them remember anything about it.

We need a new kind of curriculum, that is concept-centered, more like math and science curricula, that sends implicit and explicit messages to the students about what is important, and where what is important is the concepts, not the technology. In the same way that experiments are the implementation of science, but what we teach is scientific thinking and important concepts and knowledge, we need to have programming and computing be the implementation of computer science, but teach computational thinking and important concepts and knowledge. The computer needs to be a tool, not the center of the program.