Choosing one of the strategies in 0005.d is half the work, and the other half is being able to explain why it will help students reach the goal, in a lesson plan, to a colleague, or to an administrator. A strong explanation of this kind has four parts, each answering a different question. The first says what students will do and which part of the objective it develops. The second explains the mechanism, how the activity produces learning. The third names a misconception the activity is designed to expose and correct. The fourth shows how support is withdrawn so that students can perform the skill independently by the end. Together these form a chain from activity to independent performance, and a weak explanation usually has a broken link somewhere along it.

Linking the activity to the objective#

The first link connects what students do to what they are supposed to learn. A strong explanation states what students will do during an activity and which part of the objective it develops, instead of simply describing the activity. For an objective about writing loops that accumulate a total, "Partners trace a total through each iteration and then write the loop" improves on "Students will do a partner activity on loops," because it names the action and shows that it develops the skill in the objective. For an objective about how data sets can underrepresent groups, an activity in which students compare two data sets on a topic, identify who is underrepresented, and explain the effect has students directly practice the skill the objective names. A single sentence can make this link explicit: "Comparing the two versions helps students see how parameters allow reuse, which is the objective." Appeals to enjoyment don't make the link. "Students will like it because it is fun" may be true, and engagement can help, but it doesn't show how the activity develops the objective.

Explaining the mechanism#

The second link explains how the activity works, and this is where knowledge of how students learn shows. A rationale should explain the mechanism by which a strategy helps. Tracing code before writing it builds a mental model of how code runs while lowering the cognitive load of producing syntax, which is why it suits novices. Explaining code aloud to a partner surfaces gaps and misconceptions, because saying one's reasoning makes its flaws audible to oneself and others. For a Parsons problem, a good rationale might say, "It lets students focus on logic and order instead of syntax, which is the current goal," explaining how easing one demand supports another. Sketching a flowchart before coding works the same way, since planning the flow of decisions on paper separates logic from syntax and lets students manage one demand at a time. Debugging in pairs asks students to state a hypothesis about the fault, which brings mistaken ideas about the code to the surface. Appeals to popularity, to tradition ("this is how I was taught"), or to slogans don't explain a mechanism. "Students learn by doing" is a slogan: it doesn't say which doing, or how the doing develops the specific skill in the objective.

Addressing an anticipated misconception#

The third link shows that the teacher knows where students are likely to go wrong. A clear rationale can name a common misconception in advance and explain how the activity exposes and addresses it. Naming the specific misconception is what allows the activity to target it: "Students may think that a loop's body runs only once, so the activity has them trace three iterations" is stronger than "The activity addresses misconceptions about loops." The most effective activities create a confrontation between the misconception and evidence. If students predict and then trace x = x + 1, a student who reads = as mathematical equality, the misconception described under 0005.b, will find the statement impossible, since no number equals itself plus one. Discussing why it isn't an equation, and watching the value of x change, confronts the idea directly. In the same way, asking students to predict which values a list holds at particular positions and then running the code lets a wrong prediction do the teaching. Students revise their ideas when they confront evidence that contradicts them, more reliably than when they are simply told the right answer, so the best response to a student's misconception is often to ask the student to test the idea and explain why the result differs from what they expected.

Showing the progression to independence#

The last link connects the activity to the end of the lesson, when students should be able to show the skill without help. A strong explanation shows how supports are reduced during the lesson, typically moving from teacher modeling, through guided practice, in which students work in pairs with teacher feedback, to independent work. Guided practice is the bridge between the two ends: students do the work themselves, but with support close at hand. The independent task should ask students to apply the skill to a new situation, such as writing a short conditional for a situation they haven't seen, without hints, since repeating the modeled example shows recall more than skill. The explanation should also include evidence of individual performance. Group products alone may not show what each student can do, so a lesson in which students work only in groups needs some way, such as an individual exit task, for each student to demonstrate the skill. That evidence is assessment, the subject of 0005.f.

• rationale: an explanation of how an activity supports a learning goal
• mechanism: the way a strategy produces learning, such as lowering cognitive load or surfacing misconceptions
• anticipated misconception: a specific mistaken idea named in advance, which an activity is designed to expose
• guided practice: students doing the work with feedback and support close at hand
• independent practice: students performing the skill on their own, on a new situation

Practice: practice questions for 0005.e