Success

It's been a long couple of weeks; we're definitely into the fall weather with the rain and the gray and the outrageous behavior and the cranky. (That would be outrageous behavior on the part of the students, with me playing the part of Cranky, but you probably knew that.)

Two things happened in the last couple of days that made me feel great.

One, it feels good to know where to find what you need. A friend of mine is doing some teacher professional development. He's been looking for examples of great technology use across the curriculum, specifically looking for a high return on the time invested. I brainstormed a few ideas with him, but it's been a couple of years since I've really thought about this topic, so while I still find it fun to think about, I don't have a lot of great fresh ideas.

Last night I decided to invest an hour to see what I could find. I started with twitter, and thankfully, @dougpete had just posted the link to his daily links blog post. Even if I didn't already adore Doug, he's now my short-term personal hero because his blog, Off The Record, is a treasure trove of resources. I was able to compile a bunch of ideas for my friends just by stealing from Doug. (Thanks Doug!)

Incidentally, the very, very best thing I found was the Learning Science community. WOW. It is a collection - with annotation - of great resources for learning science. From tools like a huge stopwatch applet to online, video-enhanced games about stoichiometry to an interactive model ripple pool, it is awesome.

Second, it is fun to feel smart. Yesterday I briefly hosted a woman from Citizen Schools who wanted to know more about my school. The way it worked out, she observed part of my class rather than just getting the tour-and-discussion. The kids are working on digitizing color pictures, so she asked about it. I ended up explaining digitizing, run-length encoding, compression, and number systems to her. I feel kind of bad, because I should have been giving her an overview of what the school is about, which is not really run-length encoding, as you might guess. But I surprised myself with how much computer science I know. (Stop laughing.) It was fun. I think it was even fun for her.

Perception

Atul Gawande's article, "The Itch" is an interesting look at the mechanism of itching. My favorite part, though, is this:

A new scientific understanding of perception has emerged in the past few decades, and it has overturned classical, centuries-long beliefs about how our brains work—though it has apparently not penetrated the medical world yet. The old understanding of perception is what neuroscientists call “the naïve view,” and it is the view that most people, in or out of medicine, still have. We’re inclined to think that people normally perceive things in the world directly. We believe that the hardness of a rock, the coldness of an ice cube, the itchiness of a sweater are picked up by our nerve endings, transmitted through the spinal cord like a message through a wire, and decoded by the brain.

In a 1710 “Treatise Concerning the Principles of Human Knowledge,” the Irish philosopher George Berkeley objected to this view. We do not know the world of objects, he argued; we know only our mental ideas of objects. “Light and colours, heat and cold, extension and figures—in a word, the things we see and feel—what are they but so many sensations, notions, ideas?” Indeed, he concluded, the objects of the world are likely just inventions of the mind...

Although the article goes on to make it clear that this isn't complete, doesn't it sound like perception is just based on mental models?

I've been thinking a lot about simulations lately, and this article makes it seem like even fairly poor simulations could be surprisingly realistic if they abstract the right things or if people are able to get past the perception that what they're experiencing is a simulation:

The images in our mind are extraordinarily rich. We can tell if something is liquid or solid, heavy or light, dead or alive. But the information we work from is poor—a distorted, two-dimensional transmission with entire spots missing. So the mind fills in most of the picture. You can get a sense of this from brain-anatomy studies. If visual sensations were primarily received rather than constructed by the brain, you’d expect that most of the fibres going to the brain’s primary visual cortex would come from the retina. Instead, scientists have found that only twenty per cent do; eighty per cent come downward from regions of the brain governing functions like memory. Richard Gregory, a prominent British neuropsychologist, estimates that visual perception is more than ninety per cent memory and less than ten per cent sensory nerve signals...

The account of perception that’s starting to emerge is what we might call the “brain’s best guess” theory of perception: perception is the brain’s best guess about what is happening in the outside world. The mind integrates scattered, weak, rudimentary signals from a variety of sensory channels, information from past experiences, and hard-wired processes, and produces a sensory experience full of brain-provided color, sound, texture, and meaning. We see a friendly yellow Labrador bounding behind a picket fence not because that is the transmission we receive but because this is the perception our weaver-brain assembles as its best hypothesis of what is out there from the slivers of information we get. Perception is inference.

The article goes on to talk about the use of mirrors for phantom limb syndrome and other more interesting things. The idea is to reset the brain, so it stops thinking it is getting sensations that it isn't.

As always, I am thrilled when (a) computer science shows up in real life and (b) I guess right:

Researchers at the University of Manchester, in England, have gone a step beyond mirrors and fashioned an immersive virtual-reality system for treating patients with phantom-limb pain. Detectors transpose movement of real limbs into a virtual world where patients feel they are actually moving, stretching, even playing a ballgame. So far, five patients have tried the system, and they have all experienced a reduction in pain. Whether those results will last has yet to be established. But the approach raises the possibility of designing similar systems to help patients with other sensor syndromes. How, one wonders, would someone with chronic back pain fare in a virtual world? The Manchester study suggests that there may be many ways to fight our phantoms.

I wish the article was accessible to my students; it would be interesting to talk to them about perception and simulation. I might still try, or use the article for differentiation purposes.

Relinquishing tight control

The link to "Death to the Syllabus" is going around the twitterverse. I must admit that the first third of the essay did not fully engage me; though I'm not sure why I persevered to read the whole thing, I'm glad I did because the last third was excellent enough to comment on.

Mano Singham makes a case that the traditional college syllabus, full of specific rules and consequences for tiny infractions, is a Very Bad Idea. "The implicit message of the modern course syllabus is that the student will not do anything unless bribed by grades or forced by threats." He goes on to mention,

There is a vast research literature on the topic of motivation to learn, and one finding screams out loud and clear: controlling environments have been shown consistently to reduce people’s interest in whatever they are doing, even when they are doing things that would be highly motivating in other contexts.

He laments that there is a negative cycle between students and teachers, where teachers do not feel comfortable making judgements about students' performance and behavior, where they instead create new rules to handle each situation. He mentions that making individual judgement calls is time-consuming and that in our legalistic society, teachers may feel defensive about making individualized decisions.

In the final section, he describes an experiment he's been performing in his courses for the past several years, where he gives a very open-ended syllabus, develops a classroom culture, then asks the students to create their own policies. He finds that students entrust his judgement and for the most part decline to make many specific rules.

It should not be surprising that I feel validated and encouraged by this essay. Without grades at my school, we rely largely on rubric scoring. (I recently discovered that the word "rubric" can have many meanings, what I'm thinking of is pictured here.) My rubrics tend to be vague, when I even make them at all. I do give students the list of criteria I'm looking at - algorithmic complexity, creativity, good documentation, whatever. But I hate rubrics that are overly specific, mostly because I hate grading that way. An example:

On our website rubric, one of the things we look for is good writing. Some of that is web-appropriate writing, like shortish paragraphs and clear sentences. Some of it is just plain-old good writing: correct spelling, good grammar, that kind of thing. Example rubrics are "specific." 0-1 misspellings will get you an A. 2-3 misspellings will get you a B. 4-5 a C, and so forth. Can I tell you how interested I am in spending quality time hunting down every misspelled word in a website and counting them? For every student? And then there's a whole list of other criteria to look for. I have better things to do with my time than count misspelled words. Especially since I'll then have to cross-reference with the list of kids who have accommodations for learning differences and can't be expected to spell correctly. And the kids who write more - which usually means a better project - will be penalized because they have more opportunities for misspellings. (Oh look, I got started on this. Aren't you lucky?)

Instead of putting specific thresholds of how many misspelled words, I tell the kids that spelling and grammar count, and if the spelling and grammar are bad enough to interfere with the quality of the project, they get dinged. But the rubric looks like, "Excellent grammar and spelling", "Good grammar and spelling", "Poor grammar and spelling", not specific numbers.

On the one hand, I understand that the common thinking is that students want specific guidelines. And yet, so much of life is in vague judgements. The kids know what excellent grammar looks like. They know what poor grammar looks like. They know how to get from poor to good (find an editor, use software tools...) and I don't think that any of our lives are enhanced by suggesting that in a whole website the difference between an A project and a B project is one misspelled word.

I think that by being vague in this way, and then being willing to engage in discussions with the students if they disagree with our assessments, we help students develop their own judgements. They should have a sense of what good grammar looks like, one they can apply without a teacher telling them if they're right. (Oh right, I'm a computer science teacher, not an English teacher. They should have a sense of what a well-documented, neatly coded program looks like, how about that?) Being open to the discussion is an important corollary - students should be able to question, teachers should have reasons, and teachers should be open to being convinced, though not too open.

The place where I'm less secure, but unlikely to change, is that I - like Mano Singham, I think - have a holistic view of assessment. I know teachers who take the scores on the parts of the rubric and essentially average them into a score for the whole project. I don't do that. You can do very well on a bunch of parts of a project and still not have it gel into a cohesive excellent project. You can have a bunch of mediocre parts and still make something amazing, much greater than the parts. In life, we're graded on overall impression, not by whether we had two misspellings or three.

Define the problem

The ever-popular Seth Godin has a post about "shaving the bear", which he uses as a memorable analogy for the idea of solving the symptoms of a problem rather than addressing the root cause of the problem. (It's based on a PSA about shaving bears so they wouldn't overheat due to global warming.)

Possibly the best lesson I ever learned from the best manager I ever had was about articulating the problem, not the solution you want. (We'll call the manager TZ.) People tend to ask for the solution they want as though not having that solution is the problem. Sometimes that's true, but more often there are many solutions to the actual problem, and by articulating the true problem, many solutions become possible.

It came up because of this situation: TZ was working an event. A small group approached him and asked if he knew where a janitor was. The answer was no, but TZ stopped them and said, "why do you need a janitor?" Because they were out of toilet paper in the men's room, and a janitor would know where it was stored. TZ didn't know where a janitor could be found, but he turned to a nearby woman and asked if she could go into the women's room and bring a roll or two of toilet paper to one of the men and he could take it into the men's room. Actual problem solved. Requested solution unneeded.

The most memorable time I've applied it was in the process that resulted in my school becoming a 1:1 laptop school. It began with the teachers asking for a computer lab. The thing is, we already had a computer lab, but it was full all the time due to space constraints. Putting in another lab would only provide access to teachers who happened to already teach in that room - the space constraints would still be there. What teachers really wanted was more access to computing, access when they wanted it to enhance their teaching. A lab wasn't the best solution to that problem. A 1:1 laptop program, though oddly controversial, solve that and other problems, like inequitable home access. (Why did I find the controversy odd? We're in silicon valley, we'd be solving problems, and it wasn't going to cost any more than the previous solution.)

The first step of both the engineering design process and the scientific method are about defining the problem. Isn't it fun when life lessons are embedded in science? I wonder if it helps kids internalize lessons when we can show the same idea in many domains.

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.