I’m wrapping up a summer full of PD with lots of ideas in my head. Here’s a list of new teaching strategies (in no particular order) I plan to implement this year based on what I’ve been looking into:
Call & Response
Source: AVID & Microsoft TEALS at CSTA2018
As I’ve drifted between different pedagogy resources this summer, I’ve been trying to find strategies that are explicitly designed to bring out student voices and increase their sense of belonging. Strategies that effect the culture of my room and how students perceive themselves while they’re in it. I’ve learned enough about Call and Response to convince myself that it’s worth trying to see what effects it has on my students, even if I had to write an entire other blog post as I try to figure out exactly how I want to use it in my room.
Keeping an Error Tally
I attended a weeklong PD session to learn more about Upperline’s flavor of CS instruction, and lots of what they do hit home in trying to create a classroom environment where students feel comfortable and empowered. One strategy I’m going to steal is keeping an Error Tally throughout the year – everytime someone (student, me, etc) makes a mistake, we celebrate it and add it to a running tally in a public, visible place. The idea is to normalize error and acknowledge that making mistakes is just part of the learning process, especially in the realm of learning new syntax and debugging code.
I’m going to try and keep a separate tally for each class on one of my class boards. I also want to create ways for students to add to the tally as their own errors happen, maybe by tying a pen to a string and having it dangle from the wall so any student can walk up and add their own error.
Getting students to play certain improv games is a big part of Upperline’s philosophical approach to getting students to feel comfortable with each other, create a forward-thinking & uplifting environment, and (again) normalize mistakes in the classroom. I also saw this on display at the Google CS First session at CSTA – here’s a game I played in both places called Best of One:
Everyone spontaneously finds a partner and plays a game of Rock, Paper, Scissors. Whoever loses that game then becomes the cheerleader / hyper person for the winner of that game. That hyper person will follow the winner around as they play someone else, who will also have their own hype person. As more people play, the losers always continue interacting by becoming the hyper-team for the winner. Eventually, as more rounds are played, it’s just two people playing for the “championship”, but the rest of the class is cheering for their person to win. Ideally, it would look like the class is split down the middle with each side cheering on their champion.
I was impressed how Upperline had lots of games like this, and also with the intentionality with which they choose their games. This particular game has an effect of forcing students to ‘build up’ other students and where even the ‘losers’ of the game are given an important job in the overall scheme of the game. At both Upperline and the Google CS First session, this game took place before we participated in a brainstorming session and I don’t think that was an accident – in priming students to be supportive of each other and take different roles in working as a team, it helps them navigate the sometimes emotionally difficult and vulnerable steps of brainstorming project ideas and compromising when your idea isn’t the ‘winner’.
I need to think some more about where and how I want to implement these in my year-long classroom. Both Upperline & Google CS First exist in spaces outside the regular school day (after-school or summer classes) where there can be more freedom around what we ask our students to do. I feel like if I want to use these throughout the year, I need to do a few early in the year so it’s an established part of my classroom, and I need to use them very intentionally and quickly.
I want to make Pair Programming more of a core part of my classroom. I did it in pieces last year when I taught the Code.org curricula, but only when the lesson plans explicitly told me to and I didn’t do it at all in my AP Computer Science A course. I want to be a lot more explicit and intentional about it this year – having more projects and assignments be done in pairs rather than in isolation.
I’m already predicting that I want to start the year by having students create ‘Partner Groups’. I’ve seen this called Clock Partners or Compass Partners – I’m sure there are an infinite number of names for this with a huge number of Pinterest boards showing different variations – but the idea is to have students have a pre-made list of different partners that they can work with for different activities. I can use these to get some variety for who my students work with while pair programming.
I also need to play for really clear structures for how students interact in their pairs. I’m already thinking I’ll make some posters for the roles: the Driver touches the computer and thinks of the immediate next moves; the Navigator asks the driver questions, makes sure there aren’t any mistakes, and thinks about the ‘big picture’ of where the program is going. As always, the driver and navigator need to communicate.
This actually isn’t so much a teaching strategy, but rather a curricular / scaffolding strategy that I want to bring out in my classroom. Greg Wilson’s Teaching Tech Together has a section about giving categories and names to certain types of variables to help novice programmers understand their use and purpose within their program. It’s something I had kind of stumbled onto on my own – I would explicitly call out “counter” variables or “state” variables – but the list in his book (and on the Roles for Variables website) is much more complete and developed with more intentionality than what I was doing.
I’m imagining using these specific phrases when introducing variables to my students for the first time, and a poster that we add to with the different variable types as we’re introduced to them. I think that by explicitly acknowledging that programmers use variables with different purposes and intents can help clarify some of the choices we make when developing our own programs.
Sidenote: Teaching Tech Together has a ton of other really awesome curricular & pedagogical insights into teaching CS that I hope I’ll get to write more about.
Snaps for Agreement
This is a super small thing we did this summer at my Upperline workshop – BUT, ever since then, I can’t stop doing it anywhere I am. Basically whenever you hear something that you want to give props to or that resonates with something you’re also thinking: you give some soft low-key snaps to that person or idea. For example:
- If someone makes a really good point in a discussion: snaps
- If someone asks a question that was also on your mind: snaps
- If someone makes a particularly vulnerable or reflective statement that you want to encourage or validate: snaps
I really like this strategy from a student perspective and a teacher perspective. This strategy empowers students to validate each other and build each other up without overpowering the speaker, which I think is a really hard balance to find. I think it’s really easy for anyone (myself included) to hear someone say something you were also thinking and say “Yah! I was thinking that too! In fact…” – but now I’ve overpowered the conversation and hijacked that person’s idea. Not cool. Instead, snaps lets those students make it known they also had that idea without hijacking the conversation or the speaker.
From a teacher perspective, I also like that it’s a very low-stakes formative assessment on what’s happening in my classroom. If someone asks a question and I hear lots of snaps, I know that lots of people had that question and I should really focus on answering it. Or, if someone shares a really good idea during a discussion and lots of people snap for it, I know that the group either also had that good idea or understands why that idea is really worthwhile and meaningful.
I’m really looking forward to doing this in my classroom. It’s such a low-stakes thing to implement but I think the results can be really powerful.
Sending My Own Letter of Introduction
Source: Microsoft TEALS at CSTA2018
This is a smaller item that, in retrospect, seems like a no-brainer. I already have a survey that I ask students to complete at the start of the year to learn some things about my students – but, my session with TEALS at CSTA made me realize that this is a very one-directional interaction between my students and I. I’m asking them to reveal things to me about themselves without revealing much about myself to them. Kind of an imbalanced activity.
So, this year I’m going to write a little letter to send home with students on the first day describing me and the class and the goals of my courses, along with a few questions for students and parents to fill out together. I like this as something separate from my course syllabus, which I might send separately with more of the ‘rules’ and ‘contract’ for my classroom; I’d rather start with something a little more personal and low-stakes that sets the stage for my students to complete their survey the next day.
Using Slack & GitHib (as opposed to Remind & Google Classroom)
One of Upperline’s curricular focuses is to empower students with skills and tools that are already being used in the software development world, which also means it has students using project management and workflow tools that are authentic to real-world job experiences. Specifically: Slack & GitHub.
I’m planning on using these with my advanced students who have been with me for at least 2 years. If they’re sticking around with me into their junior and senior year, then they’re probably seriously considering a career in computer science and software development (and maybe interested in internships), so it makes sense to introduce them to these tools early on. I imagine using Slack as a replacement for Remind: both are ways to communicate with students; and I imagine using GitHub as a replacement for Google Classroom: both are ways to disseminate and collect student work.