Student-Centered Discussions in a CS Classroom

I’ve been iterating on a process to run student-centered discussions about code in my Computer Science classes. After a while I started recording them – you can listen to most of them here. I’ve gotten to the point where I like what’s happening and want to write about it before I forget how I got this whole thing started, so here we go:

The catalyst for this whole process was that I wanted to find a better warm up / closure routine for my classes when I teach coding & syntax. In the past, I would try to plan out bellwork in a similar way to when I was a math teacher: find some examples similar to what we did the day before, generate some questions about them, give students some work time, then go over the answers as a class. Here are a few examples of what I mean:

I tried this for a while as a computer science teacher but ultimately didn’t like it because:

  • Students who were absent had no way of catching up – looking at completely unfamiliar syntax out of context doesn’t really lend itself to an easy explanation of what we did the day before
  • At best, I felt I could only ask low-level questions about the code. And, since it takes a lot of mental real-estate to understand a sample program in the first place, I was basically asking the same type of low-level question over and over again.
  • Students didn’t have enough intuition yet to be able to accurately gauge their confidence. Some students would be 100% convinced they had correct answers when they didn’t, while other students felt such a lack of confidence that they don’t even know where to start and couldn’t formulate any type of answer. Which doesn’t help with the discussion I wanted to have afterwards.
  • I’m still bad at planning programming lessons – I still struggle predicting what things are ‘easy’ for students to understand and what things are ‘hard’. Which means, sometimes we’ll get partway through a lesson before I realize I’ve made a serious miscalculation about the difficulty of the concept and I have to abandon the rest of the lesson, which throws off the bellwork I planned for the next day and I have to re-do the bellwork the night before. Uuggghhhhh.
  • When we would discuss the bellwork and check-in, I was bad at monitoring the conversation so multiple students had a chance to contribute. Eventually, it would usually become the same small group of students discussing the code and answering my questions while everyone else sat back and watched. Which, in my mind, only further created this self-perceived gap of “those are the kids who can do this” vs “we’re the kids who can’t”. Which isn’t good for anybody.

That last point was really the biggest reason why I wanted to switch-up my routines. I needed a way to check-in and engage students at the start of class, but not have it divulge into the same group of students speaking up again and again. In my mind, the problem was that I wasn’t able to ask the types of higher-order, open-ended questions that I needed to be asking in order to have richer and more authentic discussions with more equitable contributions from my students.

But – then I read this post by Kelly Lougheed on Collaboration in a CS classroom, saw her note about Harkness discussions, did some Wikipediaing to learn a bit more and stumbled across this wealth of Harkness resources and have been using it in my class ever since. Here’s how that’s gone:

Setting Up the Discussion

I started by stealing an idea that I used a bit last year – I would end every class period by having students ask themselves a ‘quiz question’ based on the material they learned that day, then they would come into class the next day to answer someone else’s question from the day before. We spent a really short amount of time on these warm-up questions – their only real purpose was just to remind students about what we did yesterday so they’d have enough refreshed knowledge to engage in the class discussion and to help get absent students slightly caught-up and in the same frame-of-reference in preparation for the discussion we were about to have.

After this quick reminder of the day before, I would put up a segment of pre-made code that incorporated important concepts from yesterday’s lesson. I’d prompt students with a few leading questions, but basically I’m stealing some language from the math world and really just wanting them to notice and wonder something about the code on the board. Sometimes I’ll add a few more pointed questions, like: What do you think will happen when I run it? How will the user interact with it? Do different behaviors happen depending on the input? Are there mistakes? What is a possible real-world application to this code? I’d use these as seed questions, but really I told students that I just wanted them to talk about the code. I also tell them that there are 3-4 key features of the code that I want them to notice and that should come out in the conversation – that I’m listening for someone to notice these items and share them with the class.

Here’s an example:

When I designed this particular problem above, I had planned beforehand that I wanted students to notice that:

  • Clicking the buttons will change the image & play a sound, but all the names are messed up
  • “Platypus” will print to the screen only once when the program first runs (ie: it’s a bug)
  • Nothing will happen when you click the “Monkey” button because the id is messed up
  • Even if you did try to click that button, it would actually work with a mouseover event instead of a click event

When I displayed the code, I had students process it in stages. First I had them think about it individually for a minute (with a timer and all). That’s a lot of time, which (I hope) encouraged them to think critically and not just accept the first thought that popped into their head. It also gave them a chance to use scratch paper and try code-tracing some possible results. Next, I had them chat with the person next to them for two minutes about things they noticed and any questions they had. Then, after people have had some individual and paired processing time, we’d get into the full-group discussion

Facilitating the Discussion

The discussion itself was very Harkness-driven – I told students I would be taking a passive role and taking notes while I was actively listening for two broader behaviors: (1) I would be listening for multiple voices in the conversation and for the class to invite others into the conversation, and (2) I would be listening for certain key-aspects of the code that I hope they draw out and discuss (ie: the things I wrote about above).

Small Sidenote: the slide above is actually the 2nd version of the norms I would display to students before a discussion. In Version 1, I had language that said students needed to “correctly” describe the code and “come to an agreement” on what the code does. After a few discussions, I quickly removed that language because it created arbitrary conflicts and discouraged students from bringing up contrary opinions that were worth discussing. I realized it also sent an implicit message that I cared about correctness rather than the discussion, which was actually the opposite of what I was trying to do. In the end, I realized that those disagreements and conversations, even without resolution, were really powerful and I didn’t want the language in my directions to stifle that. End Sidenote

The first time we did this, it was… awkward. For both me and my students. I knew I wanted to try this type of discussion but wasn’t 100% sure how it would go and wasn’t really sure what my notes would end up looking like. They were thrown a bit by this brand new classroom routine in the middle of the semester and weren’t totally sure how to have the discussion. Which meant there was a lot of awkward pauses and a lot of looking in my direction with eyes that screamed “is this what you wanted? are we doing okay? we have no idea if we’re saying the right things or not”. These first few discussions aren’t even recorded because I knew it would be awkward the first few times through.

After a week of watching and listening, I started to identify behaviors that I liked and wanted to encourage, and behaviors that I didn’t like and wanted to discourage. I took all of those observations and reflections and created this Self-Evaluation Rubric for students to have during the discussion:

Self Evaluation Rubric v1

A lot of this came from the Harkness resources linked above along with my own comments based on what I was seeing in class. During the second week, I would hand this to students just before the discussion began and told them these were the types of behaviors I was looking for. I also told them that I did not want them to do all of these – that, for a good discussion to happen, it’s probably impossible for everyone to do all of these. Instead, I would have them circle 3 behaviors they wanted to focus on during the discussion. I tried to include actions that were both overt and covert – for example, someone could contribute by snapping in agreement if they didn’t feel comfortable sharing our loud.

After the discussion, I’d have students check off the actions they actually did and write down any notes about what they may still be confused by. This last part – listing confusions – was another adjustment I decided to make after the first few times. I realized that even though these discussions were meant to draw-out confusions and have students tease out those misconceptions on their own, I still didn’t have a way to check in with students to make sure things were actually sticking. Adding this last little box gave students an ‘out’ to let me know if they were still confused about something so I could check in with them later in the lesson.

While my students were discussion, I also had a job of my own. In true Harkness fashion, one aspect of my job was to try and stay out of the discussion as much as possible, resisting my own urges to push the discussion along or redirect certain behaviors (I didn’t always succeed, as you can tell when you hear me jump into the discussion in the audio clips). The other aspect of my job was to take notes on how the discussion was going. In the first few iterations of the discussion, I was really unsure of what that looked like. In the interest of just having a baseline of notes after the discussion, here’s the document I used for notes while the discussion was happening:

Teacher Discussion Notes v1

I don’t want to say much about the document above because I came up with a better one later on. In the earlier discussions, I would share some of my data with students in a non-judgemental manner which didn’t really do much in terms of feedback or knowing how students were doing at an individual level, but it did help communicate the culture of these discussions and the actions I valued. For example, hearing how many times students interrupted each other was an interesting moment for them. And also hearing how often there were male speakers versus female speakers sparked some interesting adjustments over the next few days. Just by my students knowing that these were things I was listening for made some subtle impacts in the discussions.

Again – most of the discussions we did are here. If you listen to some of the earlier ones in February, this is about where we were.


Overall, I liked it a lot. It wasn’t perfect, but it was definitely better than anything I had been doing before. I saw more students participating in discussions than I’d ever had during code-intensive units before. I saw more students asking questions and clarifying misconceptions than I’ve ever seen before. I saw students changing their opinions based on the discussions. And, since one of my goals was to help absent students get caught up, I saw absent students engaging in these discussions and learning the content from the day before in a meaningful and productive way. You can hear it in the discussions – students admitting they weren’t there the day before and being confused about something, then a peer stepping in to explain it to them. It was really exciting.

I also felt the quality of my questions changing. Before with my little paper bellworks, I was limited by simpler “right or wrong” prompts that lent themselves to just a single correct answer and very one-sided discussions. They had a very “either you know it or your don’t” quality to them that I wasn’t a fan of. But – with these new discussions around a chunk of code, I could prompt students to think much more critically and big-picture about the code than anything I had tried with my previous bellworks. Eventually I gave less and less direction with what I wanted them to focus on and just asked them to “talk about the code”, which led to discussions & dissections around nuances in the code that I wouldn’t have even thought to ask. It also gave me a lot of formative data – I could see what aspects of the code were still confusing based on how they discussed it. This was really helpful with those “oh no – I’m halfway through a lesson and I’ve underestimated how difficult this topic actually is for my novice students” moments. Listening to the quality of the discussion gave me some powerful formative data that I could use to adjust lessons on the fly or make predictions about how difficult certain upcoming concepts would be. Which, I think, ultimately improved my lessons.

I also learned that when I plan a class discussion, I need to make sure that my desired outcome is something that is tied to the learning from the previous day and can be discussed using techniques we’ve done before. For example, there are a few discussions during While loops that lasted around 15 minutes because my students had trouble tracing code through the loop – it was a particularly tough discussion for my students. In retrospect, I think this was because I hadn’t really modeled code tracing with arbitrary values the day before – basically, I had to suggest that as a problem-solving process during the discussion rather than having that as a tool in their toolbox from the day before. That experience helped narrow how I think about designing these code discussions to make sure it can be truly productive for the students and formative for me.

Lastly, I realized that even with my encouragement to diversify who was participating in these discussions, I hadn’t really provided any models for how to do that. There was certainly a more diverse group of students speaking than if I wasn’t doing this strategy, but there were still pockets of students who hadn’t spoken up in the full group even once. I wanted to find a way to get those students vocal in the conversation, and I wanted to find a way to empower my students to be the ones to invite them in.

Iterations & Improvements

As the discussions continued, I realized my students were limited by not having a common area to see each other’s scratch work. It’s difficult to code-trace without really ‘seeing’ what people are pointing to or talking about. If I had whiteboards, I could’ve incorporated those into the discussions, but my room isn’t setup for that. Instead, I tried having students connect to this newfangled thing called Google Jamboard. It markets itself as a shared digital whiteboard (and has a physical whiteboard component you can buy too), but I decided to try out just the digital version with my classes (you can see it in some of the later discussions where I point the phone at the computer). This helped students see each other’s work during the discussion, but added time to the discussions – time to setup, time to get connected, and time to walk through the work. Sometimes it was worth it, and sometimes it took more time than I would’ve liked.

I also realized I needed to give more direct guidance on how students could participate in a discussion especially in participating by asking questions. I took some of the Harkness resources above (specifically this one) and adapted them into this poster of Discussion Sentence-Stems that students could use:

Harkness Discussion Moves

After giving this as a resource to students, I immediately noticed an increase in the number of questions students were asking to draw in others to the conversation. I was especially happy that some of the students who had been doing the most talking had shifted into asking the most questions. This was really powerful to me since it seemed to suggest they also felt the desire to draw in their peers and didn’t want to be the only ones speaking but, until I gave them these tools, they didn’t know how to do that.

I also changed up how I was taking notes. I took a roster of the students in my class and laid them out in rows, then added columns for particular behaviors I was looking for (adapted from here and here):

Teacher Notes v2

Something that made this version really exciting was that I could show students the results of their discussions the next day in a way that had a lot more meaning & feedback than how I was previously taking notes:

What I Show Students

The blacked-out column would contain our student’s ID number, which is mostly private and unique to them, allowing them to find their individual row without publicizing their info to the rest of the class. They can also see the general trends of how the discussion went and we can talk, as a class, about ways to improve it which is really cool!

One thing I noticed after making these changes – both the discussion prompts and my new notes document – is more students started inviting each other into the conversation. This took the form of asking a direct question – “Hey ____ – what do you think about…” – but also in more passive ways involving attribution and acknowledgement – “When I was talking to ____, they told me…”. In the posted videos, I think it’s around late March where you can really hear this in the class discussions.

The last thing I adjusted to my routine was I tried to add some kind of post-discussion reflection / synthesis that my students could fill out. Eventually, I settled on this:

Post-Discussion Prompts v2

I only did this for a few days of the discussions, so I don’t have strong feelings yet on how beneficial or worthwhile these are. I like adding some sort of synthesis prompt to the end of the discussion, especially as something overt students can turn in, but it also takes time. And, with everything I’m doing with these discussions already, they’re starting to last a while into class. They’re totally worth it, but I still need to be time sensitive. I’m thinking I might just pick one of these prompts for people to complete when I do this again next year. Or, I might make this an option only for people who don’t want to participate more actively in the discussion – if you decide you don’t want to speak up, you’d have to do a few of these questions to show your participation in other ways. These are all just thoughts right now.

After these improvements, I was sooooo happy with how these discussions were going. They were shorter, they were more involved, and my students seemed to like them. I was getting positive feedback from students who said, once the initial surprise wore off, that they liked these more than any of the alternatives. They liked the freedom to be able to discuss & explore aspects of the code that they wanted to; they liked the “Ooooh!” moments they were able to create among their peers; and they liked hearing explanations from each other rather than the traditional teacher-centered environment (they didn’t use those words, but that’s what they were saying). I was really excited and decided to try using these discussions in another context…

AP Review & Final Reflections

The last section of these videos are all discussions based around different prompts related to the AP Exam. We did these in late March as a little mini-AP review week. I wanted my students to engage in meaningful review & recall of many of the topics we had covered in the first semester and I thought I’d try applying this discussion protocol towards this type of AP Review as well. You can listen to them in the link above – it’s like the conclusion of all the iterations I did on this process. I thought the discussions went really well.

But, thinking about next year and continuing this routine, the thing I’m most excited about is because my students were so well-versed in this protocol, I was challenged to come up with in-depth, higher-order questions worthy of discussion. This meant I had to really stretch my brain for rigorous multi-faceted prompts for my students to break-apart and analyze. If I came up with something too shallow, the discussion would be over too quickly and without any real nuance or substance. Instead, I needed questions with bite and conflict and subtlety and grey areas that might take a while for my students to parse through. And, in parsing through those questions, my students would really be able to interrogate their own understanding of the bigger concepts from my class. And all of that is really exciting.

The prompts we discussed during the AP Review are some of my favorite problems / prompts / thought experiments I’ve come up with while teaching this class. They were also the most challenging prompts for me to come up with since I’ve been teaching this class. I’m excited that by giving my students a framework to have higher-order discussions also means I’m challenged to find higher-order prompts to give them. It’s like a domino, cascading into how I develop questions for my students and keeping me on my toes, out of the realm of lower-order surface-level prompts.

And – watching / listening to my students break these prompts apart and apply their knowledge of the course through these discussions was really cool and exciting and I look forward to doing all of this again next year.


3 thoughts on “Student-Centered Discussions in a CS Classroom

Add yours

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

Up ↑

%d bloggers like this: