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.
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.
Posts
7 comments:
Such a great story, and such great lessons. I really appreciate you sharing these, and I'm going to try hard to remember them in my classroom.
Interesting how learning programming can expose the little child in all of us.
Charming story. Lucent observations that are dead on.
I love your narrative style.
What language were you learning?
This was a great story from a student perspective. As a student, I've experienced these during some classes and it really does eat away at you, in that class and every class after it too. More teachers need to understand this type of thing, especially the teachers who teach higher-level-classes, particularly, AP and IB teachers.
Thanks again.
You probably should have tried to talk with the instructor after class, he or she at least could have pointed you to some other resources or folks to talk to.
Just like you said get over the fear of the difficulty topic, get over the fear of the difficulty of admitting you need some help or the fear of asking questions or the fear of talking to someone.
Sounds like me in Abstract Algebra. Without Ted I would be on my 4th or 5th attempt to pass that course. Whenever I start breezing along and the kids get the "huh?" look I think back to to that class. I have found that really smart people are really bad teachers. They simply do not understand the meaning of absolute, brain dead confusion. Happenings like this keep us humble.
Hi, I just came to this blog as a link from the CSTA blog site. Great story!
From your description, I think I know what workshop you were attending. I was at the same one.
One of the takeaways I got was to never, ever tell my students that something is "hard" anymore. When you do that, it sets them up for failure. I don't tell them it's easy, either. It just is.
When I introduce recursion, I don't tell them it's recursion (until later) and I don't tell them it's hard. I love watching their reactions as their mental model of how the computer worked just got shattered. Then the light bulbs start to turn on as I let it sink in. The brighter students explain it to the ones who don't get it yet. By the end of the class, they accept that it works and that it wasn't hard. I love it.
Post a Comment