Warm Up (15 min)

Introduction

One of the most important parts of learning to program is learning to debug. Ask the class if they have ever learned a new skill and faced failure.

For example:

• Learning to ride a bike and falling down
• Learning to bake and burning the food
• Learning to play a sport and not winning a game

Facing failure is very common when learning new things. Have students discuss past failures and how they overcame them.

In programming, computer scientists often run into "bugs" in their code.

• Bug: Part of a program that does not work correctly.

A bug can really mess up the program, so it's important to learn to "debug" your code.

• Debug: Finding and fixing problems in your algorithm or program.

Continue the conversation if you think your class needs more of an introduction, but leave time for one of the bridging activities.

Bridging Activities - Debugging (15 min)

This activity will help bring the unplugged concepts from "Debugging Unplugged: Relay Programming" into the online world that the students are moving into. Choose one of the following to do with your class:

Unplugged Activity with Paper Blocks

Break your class up into teams of 3-5 and go to a large space. This space could be in a gym or outside. Queue up these teams like in "Relay Programming". Pick a semi-difficult design from Relay Programming - Activity Packet. Display this design at the end of a long distance between each team. Along with the display, provide each team with enough paper blocks from Unplugged Blocks (Courses C-F) - Manipulatives. Each team will need plenty of fill 1 and move ___ blocks. The move ___ blocks can either be filled in ahead of time, or filled in during the game. Either way, make sure these blocks are properly defined when the game is playing out.

Once all the teams are lined up, display or read out the following rules:

• The first student in line gets to run over to the image, review it, and place the first code block in the program to reproduce that image.
• The first student then runs back and tags the next person in line, then goes to the back of the queue.
• The next person in line dashes to the image, reviews the image, reviews the program that has already been written, then either debugs the program by taking out an incorrect code block, or adds a new block in. That student then dashes back to tag the next person, and the process continues until one group has finished their program.

Make sure the students are only using the fill 1 or move ___ blocks, and only placing one down per turn. The first team to correctly write out the code for their image wins.

Preview of Online Puzzles as a Class

Group the students into teams of 3. Choose a puzzle from the Course D Online Puzzles - Website associated with this lesson. We recommend the third puzzle. Have the students in each team sit at a computer with the puzzle displayed. Each team only gets one computer and only one student can be looking at the screen. Display or read the following rules:

• Only one student in each team can look at the screen.
• This person can only delete or add one block at a time. Once that person has added or removed a block, they can tap the shoulder of the next person.
• The next person can proceed to play out their turn.
• No turns can be skipped or repeated, everyone must play an equal amount.

The first team to finish the puzzle correctly wins!

Main Activity (30 min)

Course D Online Puzzles - Website

It might be helpful for students to sit with their teams from the bridging activities. Every student should work on these puzzles individually or in pairs, but having a closely knit group to ask and answer questions with can help develop confidence and understanding with the subject matter.

Wrap Up (15 min)

Journaling

Having students write about what they learned, why it’s useful, and how they feel about it can help solidify any knowledge they obtained today and build a review sheet for them to look to in the future.

Journal Prompts:

• What was today’s lesson about?
• How did you feel during today’s lesson?
• What is a bug? How do you know there is a bug in your program?
• What does it mean to debug code? How do you debug a program?