With a goal defined, students' starting points known, and connections to their experience in mind, the next decision is what students will actually do. Computing education research offers a set of strategies for this, and many of them can be arranged along a single path: from studying a finished program, to reading and arranging code, to changing a working program, to building something entirely one's own. Moving along that path, the student produces more and the teacher supplies less, so the general idea under all of it, scaffolding, is described first. The section then follows the path from its supported end to its independent end, and closes with two choices that apply at any point along it: how students work together, and which medium they work in, from no computer at all to blocks to text.

Scaffolding and cognitive load#

Learning to program is demanding because a novice has to hold many things in mind at once: the problem, the syntax, the meaning of each statement, and the error messages. Cognitive load is the demand a task places on working memory, and many of the strategies in this section work by reducing the load that isn't central to the current goal, so that students can attend to what is. Scaffolding provides temporary supports for this purpose, such as starter code, sentence frames, and checklists, which are removed gradually as students gain independence. The key word is temporary. Scaffolds that never fade leave students unable to start on their own: a class that always receives a template has had no practice in starting without one. A good scaffold guides the process while students still do the work. A checklist of debugging steps that students work through is a scaffold, while handing a struggling student a corrected program does the work for them. Scaffolds also support the language of computing. A sentence frame such as "This loop repeats until ___." helps a student explain code in writing, while exempting a multilingual learner from written explanations removes the opportunity to learn to explain code at all.

Studying complete programs#

At the most supported end of the path, students study code someone else has written. Worked examples show complete solutions with explanations of each step. They reduce cognitive load, since novices can focus on a solution's structure without having to search for one, and they model how an expert reasons through a problem. Their value increases when students are prompted to explain the example to themselves, a practice called self-explanation: a prompt such as "Explain why the loop starts at 0, and what would change if it started at 1" deepens learning in a way that simply running the program, which confirms its output without asking why, doesn't. Worked examples don't remove the need for practice, though, and they should fade as skill grows, in favor of more independent problem solving.

Live coding shows not only a finished solution but the process of reaching it. The teacher writes code in front of the class, thinking aloud, making real errors, and showing how to read error messages and fix them. Because students watch an expert encounter and handle errors, live coding normalizes debugging as an ordinary part of programming instead of a sign of failure.

Reading and arranging code#

The next step asks students to work with code actively, still without writing it from a blank file. PRIMM sequences a programming lesson in five stages: predict, run, investigate, modify, make. Students first predict what a short program will do, then run it to check their prediction. A mismatch between a prediction and the result exposes how students think code works, giving the class something to investigate. In the investigate stage, students examine how the program works, for example by tracing how a variable total changes and explaining the role of each statement. They then modify the program, changing parts of it, before making one of their own. The sequence moves from reading code to writing it, and reading first reduces the cognitive load of learning to write, since students focus on how programs work before producing their own. The modify stage bridges the two.

Parsons problems ask students to arrange given lines of code into a working order. Because the lines are provided, students practice syntax and logic with less cognitive load than a blank file imposes. A Parsons problem differs from a worked example, which shows the solution already in order, and from copying or tracing code, neither of which asks students to construct anything. Some Parsons problems include distractor lines, extra lines that contain common errors, so that students must discriminate between correct code and a likely mistake; the extra lines add some load, which is the trade-off for that benefit. Parsons problems suit students who are beginning to combine constructs and need focused practice. Students must already have some sense of what the lines do, and advanced students need more open tasks. When an online tool checks each arrangement automatically, students can guess their way to a solution, so limiting the number of checks and asking students to explain the order makes them reason about the structure.

Modifying working programs#

Use-modify-create describes the middle of the path as a progression of its own. Students first use an existing program, then modify it, then create their own, which gradually transfers ownership of the program from the teacher to the student. In a game unit, students might play a provided game, then change its speed and rules, then design an original game. The stages differ in what students change: in the use stage, they change nothing; in the modify stage, they change an existing program in limited ways; and in the create stage, they build the structure themselves. Starting with code that runs gives students a safe entry and lowers the initial risk of failure, and the sequence leads to writing code, without replacing it. The stages can also be revisited. When a student faces a blank file and can't begin, returning to a working example the student can change and build on gets the student moving while keeping the student's own work.

Building one's own#

At the independent end of the path, students build things of their own design. Constructionism, a theory associated with Seymour Papert, holds that learners build knowledge especially well when they are making shareable, personally meaningful artifacts, such as a game, an animation, or a data story.¹ Both qualities matter. An assignment in which students create a data story on a question they care about and present it to others fits the theory, while an assigned chart submitted only to the teacher is neither personal nor shared. Sharing is part of the idea, and posting works in progress lets students learn from one another's designs, while grading every project against a single model works against personal meaning. The learning comes through the student's own building, not merely having an artifact, so if a teacher fixes a student's project so thoroughly that the teacher's work takes the place of the student's, the student's learning remains in doubt even though the artifact is finished. This is the theory behind the personally meaningful projects described under 0005.c.

Working together: pair programming#

The strategies above can be done alone or with others. Pair programming is a structured way for two students to work on one program. They share one computer, with one student as the driver, who types, and the other as the navigator, who reviews each line and thinks ahead, and they switch roles regularly. Shared attention and discussion are the point, so instructions such as "Share one screen, talk through decisions, and trade roles when the timer sounds" capture the practice, while dividing the program into halves means that partners no longer work on the same code together. Pair programming supports learning and persistence, since partners help each other through difficulty and share problem solving when one of them gets stuck. Its benefits depend on equitable participation, which doesn't happen on its own. Confident students tend to take the keyboard and the decisions, and leaving roles to students can make existing imbalances worse. Teachers make pairing equitable by pairing students thoughtfully, using a timer so that partners regularly exchange roles, monitoring the dynamics, and adjusting when one student dominates. Separating the partners removes the benefit of working together, and asking a silent partner to write a report doesn't involve that student in programming.

Choosing a medium#

The last choice is the medium students work in, and the options range from no computer at all to professional programming languages. Unplugged activities teach computing concepts without computers, often through physical movement or cards. Students can model routing by passing labeled message cards through classmates who act as routers, which involves every student at once, unlike watching an animation of routing in turns, which leaves most students idle. Students can model binary with cards showing 1, 2, 4, 8, and 16 dots, turning cards face up or down to make a number. Unplugged activities work well when they connect explicitly to later programming or to how computers actually work. If students learn the concepts through cards but struggle when they reach code, the bridge to code wasn't built. A question such as "How could a computer use on and off states to store the number 11?" makes the connection, whereas simply finding the cards for 11 uses the model without linking it to computers, and repeating an activity doesn't make the link either.

Once students are at computers, the main choice is between block-based and text-based languages. Block-based tools such as Scratch, in which students snap together visual blocks, offer a low floor, meaning that beginners can make something working quickly, and they prevent syntax errors, though not logic errors.¹ Text-based languages offer greater power, such as libraries for working with data. Blocks are real programming: they use the same core constructs as text, including loops and conditionals, and conceptual learning transfers from one to the other. The choice should fit students' goals and context. For novices making interactive stories in two weeks, a block-based tool suits the goal, while students who already have experience with text and want to analyze large data sets need a text-based language with data libraries. Text-based tools designed for beginners, such as Unfold Studio for interactive storytelling, offer an alternative to blocks.² When students move from blocks to text, showing block and text versions of the same program side by side eases the transition, because students can see familiar ideas in the new notation. A teacher who chooses a strategy should be able to say why it fits the goal, and 0005.e describes how to make that case.

• cognitive load: the demand a task places on working memory
• scaffolding: temporary supports, such as starter code, sentence frames, and checklists, removed gradually as students gain independence
• worked example: a complete solution with explanations
• self-explanation: students explaining to themselves why each step of an example works
• live coding: writing code in front of students while thinking aloud and handling errors
• PRIMM: predict, run, investigate, modify, make
• Parsons problem: arranging given lines of code into a working order
• distractor line: an extra line in a Parsons problem that contains a common error
• use-modify-create: moving from using a program, to modifying it, to creating one's own
• constructionism: the theory that learners build knowledge especially well when making shareable, personally meaningful artifacts
• pair programming: two students sharing one computer as driver and navigator, switching roles regularly
• driver: the partner who types
• navigator: the partner who reviews and thinks ahead
• unplugged activity: teaching computing concepts without computers
• low floor: the ease with which beginners can start making something
• block-based language: a language, such as Scratch, in which programs are built from visual blocks

Practice: practice questions for 0005.d

1. LAI 516, Media: Scratch: constructionist design, low floor, events, and blocks. ↩ ↩2

2. LAI 516, Unfold Studio: text-based interactive storytelling as an alternative to blocks. ↩