For this entire lesson, Marty should be on the ground, not on a table.

Warm up

Share with learners the objectives and success criteria for today's lesson, from the presentation.

Play the game telephone, with your class:

• Have learners sit or stand in a circle.
• The first player thinks of a message, maybe an advertising slogan, a catchphrase from a character they know or a known saying. It may help to have that person whisper it to you as well so not one forgets it.
• The player whispers it to their neighbor, who whispers to theirs, around the whole circle.
• The last person to have the message whispered to them says it aloud, or writes it down.
• The initial message person shares what they said.
• Chances are the initial message and the final one will not be the same.

You could say that there was a bug somewhere because the message is not what it was supposed to be. Tell learners, this is very similar with computers and robots and the instructions that are written for them. A person, called a programmer, knows what they want to do so they create a plan for their instructions. Sometimes the computer, or robot, doesn't understand the instructions the way they are written and we could call this a bug. The programmers job changes from writing the instructions to debugging what they write to fix the mistake.

Read the story text from the lesson. The presentation will contain video to support the day's learning.

Below is a video describing how the term debug came to be, it is located in the presentation as part of the narrative. The video in the presentation is set to stop at 68 seconds and will stop automatically. If you wish, feel free to show more about Grace Hopper by clicking the YouTube logo while the video is playing.

Get Learning

Learners will have seen the video of Marty trying to paint the wall and step back for more paint from the presentation, it is inserted below.

Ask learners what they think the problem with the instructions might be. Learners might suggest he walked too many steps, he didn't move to the side, he didn't turn, he didn't stop quickly enough, he took too long to step back.

Share with learners the buggy painting code, in the presentation. Ask them to put on their detective hats to see what it was that Marty did that was incorrect. Learners can consult the workbook to debug the code, it is suggested they program Marty with this code in order to try and debug it.

Bring learners back to talk about what may have caused the bugs and how they decided to approach fixing the problem. The likelihood is that there are a number of potential solutions to the bug they identified, largely depending on what they decided they wanted Marty to do. There is no one correct answer, each answer depends on the goal they had identified for Marty that was not achieved with the initial code. One idea is suggested in the teacher guide. The video in the presentation shows this.

Time for Practice

In the workbook, there are other examples of 'buggy' code. Beside each snippet, there is a description of what the programmer wanted Marty to do. In each instance, Marty did not manage to achieve the goal due to one or more mistakes. Have learners discuss, in their groups, what they can see in the code that looks wrong. Once they have had the time to work through this, have them recreate the code in the app to see how Marty reacts; encourage learners to go slow: start with the event block and the next command; have them click to run this. If Marty looks good so far, add the next command and run that. This physical debugging process aims to support the abstract nature of the code: once learners see the mistake through Marty's movement, they should be able to identify where the bug exists, in the code.

There is a space for learners to comment on the buggy code, they might use the boxes to tick or cross the good / buggy code or write a brief comment to describe what was wrong and how they fixed it depending on their writing ability. Ideally, learners should recreate and fix the buggy code on their own devices and show this to you as evidence of work complete, allowing them to explain their thinking while you are there.

Cool Down

Bring learners back together to discuss the challenges they faced and overcame. Have groups model their creations and explain what was wrong and how they fixed it. Different groups may have identified different routes to solve the same bug; celebrate this diversity. Encourage other groups to ask about the work of other groups so that the questioner and the ones being questioned can develop their understanding.

Suggested questions you might ask:

• How easy was it to detect the bugs?
• Did everyone in your group agree about the best way to fix the bugs? If they didn't, how did you solve the disagreement?
• Were there any solutions you are particularly proud of?

Carry out any end of lesson routines.

Log off devices and clear everything away.