Three of my boys are huddled around a lap top in the corner of the classroom during my AP Computer Science A class. "I think we need to use conditional logic and the use the screen size as parameters to get the fish to move on the screen," says one of them.
"Yeah, but we need to screen to refresh. I bet we need a timer to call a function repeatedly, in a loop," another one of the boys says.
They continue to tap away at their computers.
To be clear, students haven't "learned" conditional logic, timers, or how to interact with the screen size yet - at least, they haven't learned it from me in my class.
So many of my students bring in previous experience into my computer science classes. They have a certain privilege from being in robotics club for years or from wanting to make their own video games. They were able to get access to these tools (and perhaps were socially encouraged to get access to these tools) when other students were not.
In someways it is awesome. These students with previous experience are not afraid to dive in. They have an intuition around problem solving with code that takes time to develop. They are so excited to be in class and push forward. They take risks and aren't afraid of failure.
Yet I cannot help but look at the other end of the spectrum. I have a fair number of students who wrote their first computer program on the first week of school. They were pumped to get "Hello World" to pop on their screen with code they had written.
But, then I started to pick up the pace with the class. Very quickly, we introduced the ideas of escape characters, variables, parameters, objects, public vs private variables and methods, return values, modular arithmetic, using different libraries and getting user input. That was the first 4 weeks of school.
The pace has been quick. For the students with previous experience, they are playing along. They take some of the challenge activities. They also seem more comfortable collaborating with other people to talk through problems like the boys at the start of this post did.
The students who came in as a blank slate feel the pace is quite quick. When these students overhear conversations like the group of boys were having, it is hard not to feel "behind" - even if they are right on pace. While we introduced methods and methods with parameters in one day. The syntax and the concept was new to them, whereas for other students, this was review. While it was an "easy" day for those with experience, it was a big cognitive lift for those who are still trying to understand when they need a semicolon or not.
Even in our class code alongs, privilege comes into play. During code alongs, we have a class dialogue about our goals of our program. We write out psuedocode in the comments to help guide our work. Students attack small problems individually or in groups for as I set a timer for a short amount of time. When the timer goes off, we talk through their code as I type up on the screen. I experienced the "code along" strategy while at PD at Upperline. It was a nice way to keep a group of people making forward progress while not being strictly lecture.
While this technique is supposed to support all students, I notice that some students struggle to keep up. Mainly, this is due to poor typing fluency. Students who are still typing with mainly two pointer fingers take longer to hunt and search for basic letters, never mind the semicolon key and the curly braces. The result is that the slower typers take all of the time we spend together writing code finding the right characters on the keyboard, whereas my more fluent typers have time to process what they are typing when they finish ahead of the students still searching for the forward slash key. As a result, although we might all have heard the same information and have the same code on the screen, some students had time to make sense of CS content whereas for others this was more of an exercise in typing. Naturally, when I refer back to a concept in our code along, it was "stickier" for the students who had the processing time than for those who were just trying to keep up with the typing. While I have started recording these code alongs for students to re-watch if they like, I know that puts more of a burden on my slower typers. They have to work harder than others.
These equity issues are in all classes - not just computer science classes. However for some reason these glimpses into privilege and the unequal results seems more apparent in my CS class. I see really bright and thoughtful students feel inadequate because of the previous experiences and privileged that other students bring into the classroom. It might be that I am unused to privilege effecting some of these groups of students. I realize that in itself is a problem.
I wonder how I would react as a student in my CSA class. I certainly think the students with previous background would alienate me from the field of CS. I just wouldn't be able to compete with them - if I were still trying to figure out how to use parameters to make a fish, and they were talking about moving a fish on a screen with vocabulary I had never heard, it would be hard for me to see myself "belonging" in that crowd.
Again, comparing this to a math class, I need to do two (and a half) things to address the inequities in the class.
#1) Assign competence
Look for what students are doing well and give them public props for that. I need to normalize the feeling of being in the "stretch zone" for learning. I also think I can do a better job of explaining that the people with previous experience are just trying things. They fail a ton - they don't get it right away. No student should expect to get the code right the first time. I have started to this with some students who are still confused what "static" means or why you would want a "private" method. These students are freaking out because they don't understand every word's purpose, whereas some of my experienced students, just ignore that fact until it becomes a problem for them. Wanting to understand everything is a great disposition to have. It will slow students down, but that is ok. I need to assign competence to those students who are making sense in multiple ways about what is going on in the classroom. Everyone can contribute in a positive way.
#2) Choose group worthy tasks
I need to continue to look for "low floor, high ceiling" types of labs for students to engage in. Due to the content we need to cover for the AP test, it can be difficult to find such tasks. Additionally, right now all the extensions I come up with require students to have some of that previous experience (like conditionals or loops). Thus, even for the students who are new to CS and enjoy it, they really cannot engage in the "extensions" without knowledge of these CS ideas. My hope is that as we get into some of these core topics, I will be able to develop more appropriate extensions for all students.
#2.5) Make group worthy routines
Along with #2, I think I could do more to support group work in general. It is clear that some of the students feel really comfortable working in groups, looking at one another's screens - even going to a different part of the room to do that. I want to work in peer programming and maybe even break out some of the large monitors to have students work collaboratively.
Bottom line, I am teaching this course because it is the right thing to do for students. One of my favorite lines for teaching is "teach for students who will be successful because of what you do, not despite what you do". While I fear that there might be a vocal backlash to introducing peer programming - research says it is good for students of all abilities in CS. I need to make sure that students are successful because of what I do. I need to be aware that when the loudest 30% of my class is ready to move on, I need to take a step back and consider why I am teaching the course - what is the right thing to do for 100% of the students.
No comments:
Post a Comment