A New Take on Equity in CSA

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.

Day 3 PD reflections: What story am I telling?

A few things have me thinking about the idea of story - a colleague and I had a little conversation about this during the school year, KSTF has us talking about the power of teacher stories, and what I am learning at Upperline PD has me thinking about the story each lesson tells while teachers are teaching their sample lessons.

Now I am wondering, how does each unit I have tell a story?  How do my lessons weave together a content story for students?  Is there a story arch throughout the year I can hang units and lessons on?

More recently, I have been thinking of the role of stories and learning targets in different types of lessons.

Traditional Instruction

When talking about traditional instruction, I think the story still needs to be there and learning targets provide key pointers at the beginning of the lesson to tell people where we are going.  For example, the move "The Breakup" is about, and results in, a break up.  You can still tell a good story if you know the ending.

In my upperline PD, I realized that if a teacher was teaching in a traditional way, I wanted to know exactly where we were going in their story.  I saw it needing to know the key checkpoints along the way.  It was somewhat like peeking ahead to the titles of future chapters in a book so I could see the story come together.

In traditional instruction, the teacher is the story teller.  Every student gets the exact same story from the same deliverer. Some teachers tell stories better than others here and I think there are some tricks to make the story still compelling for students.

• I have noticed when ever I am super excited about the content (even if in reality I am not super jazzed about it), students engage more.  Seeing story tellers excited about the story is one way to get buy-in from students.  
• Making the story feature key characters that are interesting to students gets a giggle from kids.  Including references to fidget spinners, Shakira, whatever is trendy or and inside joke at the moment includes students in on the story.

I get that some days even the most constructivst teacher needs to go to traditional methods of teaching.  That's OK.  That's not an excuse to forget about the story you want to tell or to skip a good hook. 

I wonder how else strong traditional instruction teachers are able to engage students in their classrooms.


Discovery/Inquiry Based Instruction

Inquiry based learning puts the student at the center of the story.  It also means that you might have 36 different stories being constructed in the classroom during a lesson.  Thus, it is the teacher's role to weave these stories together to make the picture clearer for all learners.

I truly believe that to give students the learning target at the beginning of an inquiry based learning lesson, you give away the punch line.  It's less fun to explore if you know how the story ends.  In fact, why explore, why take risks if you know the ending.

In discovery based learning, the storyline of a class is revealed by students and through students work.   However, I think we have all read something where the story wonders for too long (perhaps this blog post is one of them).  That's why the teacher is the ultimate architect of the story in these classrooms.  Being able to predict student questions and responses and guiding them to the "a-ha" moments takes a different set of skills.

What does a good CS class look like?

This question came up in a meeting I had with someone from the Upperline School in NY.  Really it is what I have continued to struggle with since transitioning to teach more CS than math.

When I think about teaching math, I know what a good math lesson looks like.  It has all students collaboratively solving problems.  But when it comes to CS, I haven't necessarily seen a lot of "WOW! that was a good CS lesson" in other classes - in fact, I've only observed one other person's CS class, and it seemed like an average class.  Nothing I was dying to replicate in my own class.

In my class, so much of the programming tasks are pretty individual - people working by them selves to learn a new aspect of programming.  They talk to one another when they run into problems, but I don't see students wrestling with content the same way I see students in math wrestle with content.

Our class-code-alongs provide a bit of a glimpse into that, but still there is this awkward timing thing that I don't have quite down.

Where I did see collaborative problem solving in my CS class recently was when we did the brainstorming for our Simon game.   I think that can be expanded on to give students a task and see what they come up with.

Next, I want to give students a challenge to make another game - maybe 2048 the game, or a memory game?  I think this could be a fun, collaborative, and rigorous challenge for students.  I could even create my own code to give students who need a bit more scaffolding after they struggle a bit.

I keep coming back to the question of "who is learning in my class, when, and how do I know?"  Here's  how I have identified my "learners" in my class thus far:

• I have a few students who are constantly asking questions - it shows that they are thinking about processing what they are taking in and making sense of it.  
• My students who "go rogue" and decide to do their own projects are other students I would identify as my "learners" also - they are creatively arriving at solutions.
• My students who can look at someone elses' code and troubleshoot it.
• My students who create things they are proud of... you can see it on their face - they are happy and satisfied with their work.
• Students who see the need to define the problem - again, they are asking questions and keeping the big picture and the small picture in mind.
• My students who re-read their code before asking me - have looked at the errors and tried to make sense of them.  I have noticed a gap between students who know how to read code and those who don't.  This was especially true when we took a break from programming and then came back to it.  Some students were writing some funky things like if (x = 6 or 7) - logically I know what they were trying to do, but they were pretty far off the mark from a syntax perspective.  I suppose this is much like PEMDAS in math - they might be capable of thinking about a problem from a big picture, but when it comes to computation, it can be rough.  

When looking at this list, I am noticing that a lot of these things are happening when we do projects - not just the little stages in CodeStudio.  It is so hard to see the learning when they are "plugged" in to the computer...  obviously there is a time and a space for this type of learning, but I am wondering if I need to move to peer programming models or replace it with some more open ended-esque projects.

I really wish there was someone out there doing CS education research much like Jo Boaler is doing maths education research.