1.05: Fixing Instructions
Lesson Overview
In this lesson, learners will examine several examples of code and determine if they do what they are supposed to do. This examination often leads to finding mistakes, bugs, and fixing them, debugging.
Learners will be challenged to explain why a person might have made a mistake like this.
- Bug, Debug,
Content Sections
1.05: Fixing Instructions
Lesson Overview
In this lesson, learners will examine several examples of code and determine if they do what they are supposed to do. This examination often leads to finding mistakes, bugs, and fixing them, debugging.
Learners will be challenged to explain why a person might have made a mistake like this.
- Bug, Debug,
- Direction symbols; ordering instructions; repeat blocks
- iPad or Tablet with MartyBlocks Jr
- Editing
-
- Marty V2
- Device with MartyBlocks Jr
Learning Objectives
- I can find a mistake in someone's instructions.
- I can debug the instructions.
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.
Extensions & Support
Extend
Have learners create broken code for their peers. It will help for them to first properly create the instructions and then either change the order of 2 or 3 blocks or delete or add a block. Then have another group discuss, debug and test their solution.
Support
A key thing is to ask questions about what the bug, they have identified, is. Removing the pressure of writing about a bug should encourage them to engage with their peers and the code in the workbook.
Additional Reading
- Marty the Robot Educator Guide
- Educator FAQ
- Technologies: Computing Science
- Literacy & English: Listening and Talking
- Health and Wellbeing: Mental, Emotional, Social and Physical Wellbeing
- Numeracy: Number, Money and Measure
- Literacy & English: Reading
- Literacy & English: Writing
- Computing, Design and Technology: Design and Technology
- Computing, Design and Technology: Computing
- CSTA Education Standards
- Elementary Technology Applications: Grade 3 to Grade 5
- Digital Technologies, Design & technologies: Design & Technologies
- Digital Technologies, Design & technologies: Digital Technologies
- International Society for Technology in Education (ISTE)