Facilitating a Classroom Discussion


As the news stories are presented, ask students:

Your status as a teacher gives you power that you will need to use and power you will want to relinquish. At first, you may need to be quite active to build participation and get students to discuss, both agreeing and disagreeing constructively, and with some system that keeps them from all talking at once or breaking into independent conversations. But, to get them to debate with each other, and not just to you, you need eventually not to be the person who responds to each student's statement before another student can chime in. The mid-path between running the show and allowing total chaos is tricky, as all of teaching is. You will find some practical ideas in chapter 6 of Making Sense of Algebra from Heinemann Publishers. Here are a few.

Sensible Norms for Classroom Discussion

The last suggestion was "Minimize rules that apply only to school and not to normal conversation," but this is a classroom with large numbers of people and so not quite a "normal" conversation. Some norms, all pretty obvious, are useful. Use or ignore the following ideas.

You may want to ask students periodically what they think might help the discussions.

Other Ways to Engage Students in Meaningful Discussion

This list was generated by some of our field test teachers in New York.

Engaging Students in Building Algorithms Offline

Periodically, the curriculum will ask students to develop an algorithm for a task and then build it in Snap!. Other times, you may opt to focus on building an algorithm offline before students dive into coding it Snap!. Either way, working through the process outside of Snap! supports algorithmic thinking and collaboration and also helps to prepare students both for the language that appears on the AP CSP Exam and for coding in other programming languages.

Note that we do not suggest teaching pseudocode. It can be useful to think about an algorithm in general terms, in plain English, but "pseudocode" tries to have it both ways, being both informal and sufficiently precise to translate directly to a programming language. For example, one step in the algorithm for Quicksort is to choose a value from among the values being sorted that you have reason to hope will be near the median, so that the two partitions you generate will be about the same size. (Don't get hung up on the details if you're not familiar with Quicksort.) Beginners especially will be tempted to write down "Find the median value," not realizing that you can't do that without having the data already sorted!

There's a reason why we don't program in English. In order to develop an algorithm in any detail, you have to pay attention to the "affordances" of a particular programming language: what's easy to do in that language. And the language doesn't let you handwave; good ones, for example, don't have the equivalent of pronouns, which create ambiguity in human speech.

For example, on the Unit 2 Lab 1 page, Developing a Number Guessing Game with Script Variables , you may choose to explore the concept of a binary search algorithm and to develop an algorithm offline before even opening Snap!. Some teachers have used this approach:

Having said that, bear in mind that this is nothing like how experienced programmers work. They do their thinking directly in a programming language. It's a little like learning a foreign language; at first you think in English (or whatever your native language is) and laboriously translate in your head before speaking. But there comes a point, maybe a year into immersion in the language, at which you find that you are suddenly thinking directly in the foreign language. This whole elaborate "design the algorithm in English" process is just for beginners.