Introduction

We’ve covered what computer science is, how it is learned, and have seen some teaching approaches and tools to help manage cognitive load. Building on that knowledge, in this chapter we’ll look at how to design or modify computer science lessons for our students.

Embedded CT

Before we delve into specific strategies for selecting and structuring lesson activities, let’s first discuss more broadly what those activities should be. Many Computer Science curriculums focus on the development of algorithms and data structures (a fact reflected in the name of one of the best classic textbooks in the field, Nickolas Wirth’s Data Structures + Algorithms = Programs). We can see this in the CS Unplugged curriculums’ focus on sorting algorithms and tree data structures, as well as many other curriculums.

While these topics are important, writing code to sort data or define data structures only appeals to a subset of our students. It also paints a somewhat unrealistic picture of what a computer science career would be for our students. The truth is, while it was once common practice, today very few programmers are actually writing sorting algorithms and data structures by hand. Instead, they are utilizing pre-built libraries that provide this functionality. While it is important to understand what these libraries are doing and how they structure data, it is not as important as many curriculums make it out to be.

Remember, computational thinking is all about problem solving, and the problems we want to solve come from all domains. Consider how real computer scientists and intellectual workers are using the tools of programming and computational thinking:

• A computer scientist working for an online media company revises their recommendation algorithm to do a better job of helping users find videos they will enjoy
• A social activist uses public databases and algorithms to reveal gerrymandering in a state’s proposed redistricting
• An insurance actuary uses algorithms drawing on their company’s historical claims data to determine appropriate insurance rates for teen drivers
• A computational geneticist uses big databases and algorithms to search for patterns in genomes to discover the root cause of a disease
• A artist programs Raspberry Pis to cause elements of an interactive art exhibit to respond to patrons
• A computational physicist builds a simulation to test a theory of how our moon formed
• A DJ uses programming to help remix music from multiple tracks on the fly during a performance
• An advertiser uses profile data collected online to provide highly targeted ads to people most likely to be interested in the products being sold

Building or selecting lessons that reflect this breadth of the use and impact of computer science can help students see that they can use the tools of computer science to support their interests. Research has shown that this approach also appeals to students who would never have thought computer science was something they would be interested in.

CSSC Instructional Continuum

Now let’s turn our attention to thinking about approaches for delivering computer science lessons. A handy way to consider the cognitive load is the the Computer Science Student-Centred Instructional Continuum¹, which represents a range of potential instructional approaches:

The continuum ranges from highly scaffolded (right side) to no scaffolding (left side). Based on the learning theory from the prior chapter, we want to start our students with activities with more scaffolding, and gradually reduce that scaffolding. Note that this applies for all new subjects - as we introduce them, we again want to have an appropriate level of scaffolding in place!

The continuum’s activities are:

• Copy Code - students are giving step-by-step instructions to follow. This can be part of a Live Coding exercise, a recorded tutorial, or a worksheet to copy.
• Targeted Tasks - students are given a short task, i.e. completing a method, fixing buggy code, transcribing music into a program, or Parsons problems.
• Shared Coding - the teacher writes code, explaining their thought process (sometimes called demonstration coding, live coding, or apprenticeship). Students may be asked to write the same program at the same time.
• Project Based - students are given a project with a goal - i.e. adapt a play to be presented by sprites in Scratch
• Inquiry Based - students consider a question and attempt to develop a solution, i.e. use simulation to evaluate catapult designs
• Tinkering - completely student-led programming efforts.

This continuum can be helpful in evaluating existing curriculum materials; for example, most Code.org lessons start with copy code activities using multimedia explanations of what that code does, and gradually shift to targeted tasks. Likewise, Scratch’s built-in tutorials also start with copy code activities. Once a student has developed comfort with this level of programming, you can introduce less tightly guided activities.

Use - Modify - Create

The Use → Modify → Create learning progression is a good example of a lesson design strategy that incorporates activities that progressively move from left to right on the instructional continuum. Students are introduced to an exemplar program that does something similar to the ultimate challenge you have in mind for them. They run the program and learn how to use it effectively. Then they are tasked with modifying the program in a way that allows them to tackle a different (but similar problem). Finally, they use what they hae learned to create an entirely new program¹.

In addition to providing a gradual removal of scaffolding when teaching computer science, the Use-Modify-Create approach also encourages students to develop a growing sense of ownership over the code they author. This progression can be repeated to introduce new syntax, algorithms, or data models. Later projects can also be designed to challenge students to combine the approaches they have previously learned separately.

TIPP & SEE

TIPP & SEE is an adaption of the Use → Modify → Create → learning progression developed specifically for working with Scratch¹. The name is an acronym for a multi-step process of interacting with Scratch projects. Scratch offers a website where programmers can publish and share their projects, and other programmers can remix them.

Remixing in Scratch means taking an existing project and modifying it, often to build in more functionality or to change its aesthetics. This parallels the professional open-source community, where professional programs write and distribute programs online using sites like GitHub for others to use and modify. This also means that the Scratch website can serve as a rich source of exemplar programs to share with your students.

TIPP stands for Title, Instructions, Purpose, and Play, and describes examining the surface level of a Scratch project - reading its title, instructions, trying to determine the purpose of the project, and then running it to see what it does. SEE stands for Sprites, Events, and Explore, and describes examining the actual code of the project.

The Block Model

The Block Model is an educational model for describing how students come to understand a program as they read it ¹. It is expressed as a table that covers three dimensions in four levels. Each cell represents one aspect of understanding.

The three dimensions are the text surface (the actual text of the program), the program execution (the order in which the program commands happen, and how data is manipulated), and goals (what the program is meant to do). Text surface and program execution are further grouped into structure (the actual expression of code) and function (its intended purpose).

The levels are atoms (individual elements of the language, i.e. keywords and statements), blocks (groupings of code lines that work together, i.e. a loop that sums all the values in a collection), relations (the connections between the bocks), and macro (the overall program).

The block model has a direct relationship with the epistemology of programming and the development of schema. Beginning programmers are still learning the atoms of a language (mastering these reflects achieving the preoperational stage). The first schema programmers develop are to reason about the patterns found in the blocks, and further schema help to reason about the relationships between these blocks (Concrete operational stage). Finally, students learn to see how all the pieces of a program come together at the macro level (Formal operational stage).

The block model can therefore help us reason about how our students are able to engage with a program (novices read programs bottom-up, reflecting the order of the table), while more experienced programmers often read top-down, sussing out the purpose of code by the names of functions, classes, etc. and by recognizing the purpose of blocks of code without needing to use code tracing.

PRIMM

PRIMM is also an instructional approach building off the Use → Modify → Create strategy and the Block Model. Much like TIPP & SEE, it emphasizes reading and understanding code before writing. PRIMM is also an acronym for the stages that it structures learning activities in: Predict, Run, Investigate, Modify, Make.

Predict We start by presenting students with a prepared program, and the students try to predict what it will do. This works well as a think-pair-share or small groups activity, as discussion between students can enhance learning.

Run Then the students test their predictions by executing the program. Discussion can be used to help students verbalize the results and compare it with their predicted expectations.

Investigate The investigation stage is based on the Block Model, and can include activities like code tracing, explaining, annotating, debugging, etc.

Modify This stage is very similar to the Modify stage of Use - Modify - Create, and involves modifying the code they have just investigated to accomplish a related task. During this stage, the scaffolding support is gradually removed.

Make In this stage, learners are given a new problem to solve that uses the same ideas and skills introduced in earlier stages.

Summary

In this chapter we explored pedagogical techniques for evaluating and developing computer science lessons. We discussed embedding our lessons in the problem spaces of other disciplines, and how this can help students understand better how computer science fits into the world.

We also saw how the Student-Centered Computer Science Instructional Continuum can be used to help think about scaffolding to control cognitive load in our lessons. Then we saw a number of instructional models for developing CS lessons, including Use-Modify-Create, TIPP & SEE, the Block Model, and PRIMM.