I give my students the first few minutes of today's class to put their finishing touches on yesterday's work. Many of them want to know the answer, once and for all, to yesterday's problem. I'm often tempted to give it away, but I don't. Later this week (or early next, depending on the class), I'll tie a bow on this problem by presenting a solution to the class. For now, I'm checking work more for process and for problem definition than for solutions, and I think that, given a little more time, students will figure it out. So the most I'll give is a little wink and a good-natured "hush" to anyone who has a great answer.
I circulate, greet students, admire their work, commend them on working hard, and make sure to make a last call for homework before the first five minutes of class are up.
I say how important I think it is for everyone to have an experience in computer programming, and that I'm excited for tomorrow. Kids are pretty excited too. Then, I connect today's work to that computer programming. "When you write a computer program, you have to solve a bunch of problems," I say. "But the computer doesn't tell you exactly what those problems are." I ask students if they have ever seen a computer shut down or close a program unexpectedly, or if they've ever tried to do something on a computer, but been unable to get it to work. When these things happen, it's usually not clear exactly why they happened.
"Today's problem is just like yesterday's problem," I say. "You have to figure out what the question is in the first place, and then do your best to solve it. That's a lot like making a computer work."
For the second consecutive day, we're going to work on one of James Tanton's "Math Without Words" problems. After trying this for the first time yesterday, my students and I will have a better idea of how to proceed. I hope to notice in all students a gain in their ability to engage and persevere in today's work.
To begin, I'll give a little pep talk about the idea of being frustrated. Frustration really is a productive thing - if no one was ever frustrated by a problem, then nothing new would ever be invented - but quitting is bad. I also connect this to tomorrow's Hour of Code, by saying that frustration is a key feeling in the development of any computer software.
After the pep talk, I distribute the problem. Today, we look at this one:
Like yesterday, I tell everyone I'm going to take questions in 5 minutes, but that I want everyone to start by seeing what they can do on their own. As students get started, I circulate and coach each student to try something. If I see a kid quitting or distracted, I call them on it. If I see a kid who is frustrated but demonstrating perseverance, I give them props.
When five minutes are up, I take questions. I write each question on the board. If anyone asks a question that is meant only to get me to give the answer, I try to rephrase it in a way that gets students to ask a more descriptive question. As a class, we look at the list of student questions, and use these to define vocabulary that will help us talk about the problem. We're digging into the idea that language is a tool that helps us solve problems. The more specifically-defined words we can make available to ourselves, the better we can discuss our ideas.
With vocabulary words defined, clarifying questions answered, and maybe a problem put to words, it's time for another round of work. Students may be working to solve the problem as they understand it, or they may need a little more help getting started. I circulate to see where everyone is at.
If anyone is really stuck, show them that the way to get started is color one dot. I scaffold the problem by coloring just one of the dots in the "5-family" then asking how many solutions have one dot colored. It's then pretty obvious to students that each dot could be the one that's colored. "So in addition to coloring no dots or one dot, what are some other number of dots we could color?" In one class, this line of questioning led us to develop this "family tree", which really helped that class come up with ideas for how to organize their solution.
If students think they've got the answer, I ask for proof. If I see that they have a correct and well-organized answer, I ask that they write a sentence or two about their solution, and I give them another of Mr. Tanton's problems. This student's work is well-organized and complete, and her next step is to explain how that organizational structure proves that the work is complete. In any class, at least a handful of student notice the pattern in the numbers (it's the Fibonacci Sequence, but we haven't yet named that), and that frames their work. If a student is missing just one solution, then that's a lot like a computer coding problem - how can we find that one little error to make the whole thing work?
This problem is hard for some students, but just engaging in defining the problem is a valuable experience for kids to have. Here is the work of a student who was very engaged in the process of defining the problem before running out of time to solve it. When we spoke two days later, she was excited to keep going, and it was easy to discuss the problem because she was comfortable with the words that we'd defined.
With about five minutes left in class, I return the index cards that served as yesterday's exit slips. On the other side of the same card, I ask students to write today's date and then to write the problem from today's work, as best they understand it. Some kids are already done solving the problem at this point, and others are still working. Either way, I tell everyone to try to use words that we've defined, or to define their own, and write the words that should go in front of the question marks on today's problem.
This is still the hardest part for almost all of my students, but today's work will make a great reference point as the year proceeds. Whenever we need to precisely define a vocabulary word, we'll be able to look to the work of the last two days as an example.