Why is it important to give very clear instructions?
Have you ever been given unclear instructions and ended up doing the wrong thing?
Ideally this lesson should take place around a large grid such as:
An outside painted chess board.
Grids in your classroom carpet.
Making masking tape grids one the floor in your classroom.
Draw a chalk grid either in your classroom or outside.
Ask for two volunteers and give yourself and them the roles of:
Role 1: The Developer (who writes the program) - The teacher will model this initially.
Role 2: The Tester (who instructs the Bot and looks for bugs).
Role 3: The Bot (who runs the program).
Teacher: "I’m going to be the programmer, but I’m going to need your help. We are programming the Bot, not just remote controlling it, because ALL the instructions are written before the Bot can follow those instructions."
"It’s our job to write down clear instructions for the Bot, who is going to be (say the person’s name). (Student's name) will be the Tester and is going to give the instructions to the Bot. The Tester will be on the lookout for bugs."
"First of all we need to decide, what programming language are we are going to use for this? I’ve chosen arrows to represent move forward, turn left and turn right."
"Debugging is fun because you get a chance to change your program after it’s finished when you notice it’s not working how you thought it should."
There will be different ways to express the same instructions (such as drawing an arrow, writing "Forward", or using the printed arrows resource above), and the key is that we need to be consistent.
The choices about the exact format of the instructions is what leads to different programming languages, and it's fine that this happens, as long as we know the meaning for the particular language we're using at the moment.
If students aren't sure about the left and right direction, you can print the "left and right hand cards", and stick them to their shoes or have them hold them in their hands.
Have the Bot act out the individual instructions: forward means step one square forward, and left and right mean a 90 degree turn on the spot in the square (not moving to another square).
Teacher: "We’re going to write our own program that gets the Little Red Riding Hood to rescue her Grandma.
The goal is to get Little Red Riding Hood to the square that Grandma is in.
Let’s write the first two steps on the board together."
(Draw two forward arrows.)
To work it out students may initially need to see the program in action, so place the arrows within the grid to demonstrate what the Little Red Riding Hood will do.
It’s also a great technique to write the first few instructions of the code, test it and then add to it.
If you are putting arrows on the grid, the turning arrows will also need a forward arrow in the same box, or you can put the forward arrows on the line between boxes, which makes it clearer what it does.
"So let’s try that, and see what happens.
"Tester - could you please take these instructions and pass them onto the Bot.
Be ready to underline what doesn’t work when you see the Bot doing something that doesn’t look right, and hand the whiteboard back to me to figure out how to fix the bug."
A key point in this activity is that the instructions are all written before they are tested.
We don't allow anyone to give additional instructions to the Bot; they must follow exactly what is written (which can sometimes be humorous if they head off in the wrong direction.)
This is what happens when programming: you write instructions for a program, and when you run the program, they are all executed without the programmer intervening.
A programmer needs to visualise what would happen when they are writing the instructions; during testing they will find out if what they envisaged was correct!
Teacher: "Bot - please pick up Little Red Riding Hood and be ready to receive the instructions for the tester."
(The bot can carry a toy or token representing Little Red Riding Hood; or they can imagine that they are guiding her).
Tester then reads off the board: "move forward, move forward."
At this point you could question whether or not a "Stop" instruction is needed.
Students should be able to come up with the reasoning that the program stops automatically because there are no more instructions.
"Tester, did the program run as you expected it to?"
Depending on the Tester's response, if it did then carry on programming, otherwise fix what didn’t work and run that again.
In this example Little Red Riding Hood should be in the square diagonally below Grandma’s house.
Now let’s add to it.
What would we program next?
Point to where the next piece of code needs to be added and add a move forward and turn left, turn left.
(This is deliberately incorrect.)
I think it’s ready to test now.
"Tester, please test my program" (the Programmer hands the program on the whiteboard to the Tester and the Bot should return to the starting square ready to rerun the program).
Teacher: "Remember Tester, it’s your job to find any 'bugs' in my program.
A bug is when my program isn’t doing what was expected.
Your job is to draw a line under the piece of code where you notice the instructions seem to be going wrong.
You can stop the Bot at the point that you think there is a bug."
Tester then reads the instructions in the program off the board and the Bot executes them as they are read.
The Tester should underline under the second 'Turn left' because Little Red Riding Hood will have turned around twice on the spot rather than turning once and going forward again (Which is what is needed to get to Grandma's house).
Teacher: "Excellent, you found a bug! I love finding bugs, so I can start solving them.
Now class, let’s work through this together to find my bug.
Tester, you’ve done a great job finding it, but it’s the Programmer’s job to find and fix the bug."
If the class can’t identify how the program needs debugging then talk through each step and model it with Little Red Riding Hood.
Did move forward make sense?
Did move forward a second time make sense?
Did move forward a third time make sense?
Did turn left make sense?
What about turn left again?
Okay I think we found our bug.
Let’s draw a line under that and think about what we would change it to?
Let’s test it.
Once the bug has been identified then ask the Tester to test it again; ask the Bot to pick up Little Red Riding Hood and go back to the start position, then the Tester reads them the instructions.
Did we successfully program Little Red Riding Hood to rescue Grandma?
How do we know?
We successfully programmed Little Red Riding Hood to rescue Grandma because Little Red Riding Hood and Grandma are in the same square.
Are there other ways we could have programmed Little Red Riding Hood to get to Grandma's?
(There will be lots of ways; for example, Left, Forward, Right, Forward, Forward, Forward will work.)
Discuss the programming options and test each one.
What if we want Little Red Riding Hood to get to Grandma’s, and then bring them back to safety?
In programming, there are numerous ways to program the same thing.
Some might be more efficient than others, but all are correct if they achieve the desired result.
For example a student might program Little Red Riding Hood to go around the outside of the grid and then go and get Grandma.
This is a correct solution, but there’s a lot of extra code that’s not necessary.
More commonly, two programmers might come up with programs that take a similar amount of time to achieve the same result (for example, "Forward, Left, Forward, Right" and "Left, Forward, Right, Forward" get the Bot to the same place and orientation; both are good answers).
An important concept in programming is that there can be multiple good answers; there is rarely a single solution that is the best one, and this means that if a student's work looks different to a model answer that might be available, it isn't necessarily wrong.
If it achieves the intended outcome, but gets there in a different way it is still correct.
Either set up your students to be working around the outside of your large grid, or you can use a smaller grid like a chessboard or the back of a 100s board (or print the one provided with this lesson), in which case the Bot moves a counter on the board instead of walking around the grid.
If you have multiple small grids, students can work independently in groups of three (Programmer, Tester, Bot).
If you are using a large grid, one group of students can work on their program while another tests theirs.
Each group gets to try their program once, and then the next group has a turn while the previous one starts working on debugging their program.
Have the students choose their own two toys (one to be rescued, the other to be the hero) have them practise this task, as follows.
Place the toy on a square on the edge of the grid, facing inwards.
Place the toy that is going to be rescued inside the grid.
The Programmer writes down the program on a whiteboard.
The Tester then takes the whiteboard and a different coloured whiteboard pen.
The Tester tells the Bot each instruction in the program.
The Tester puts a tick next to the code that is correct and underlines when the code is different to what the Bot should be doing.
If this happens the Tester says “Stop” and the Bot stops and goes back to the start.
The Tester gives the whiteboard to the Programmer, who then debugs the code, and gives the Tester a revised version.
Repeat step 4 until the program is free of bugs and works as intended.
Change roles and move the Bot toy and the toy that needs rescuing until everyone has had a turn.
If you notice that your students need support to visualise how to write the instructions you could use the arrows (cards) provided on the ground, or for a small desktop grid, use a whiteboard marker or small arrows.
This supports students to visualise what they want to program.
The next challenge
Add barriers to the grid so that the path is more complex because it needs to avoid the barriers.
This could be the Big Bad Wolf and other animals, or you could invent a new scenario for the grid.
Have groups program the rescue without using the left hand turn (i.e. the only instructions are forward and right turn).
Scaffold the students to realise that a left hand turn can be achieved by doing three right turn instructions.
Then challenge them to program with a left turn but no right turn.
Ask if they can write programs with only the right and left turn instructions (i.e. no forward instruction)?
(This isn't possible, as you would only be able to turn around on one square.)
Eliminating one of the turn instructions highlights that different instruction sets can achieve the same thing, although some may be more convenient than others (for example, there are many different programming languages, but they can all do essentially the same kind of computation; it's just that some are better suited to some purposes than others.)
Implementing fewer instructions simplifies building a computer, and this can make it either faster or cheaper.
For example, a very simple computer might have an addition instruction, but no multiply instruction; but if you need to do multiplication it can be achieved by doing lots of additions.
Many common processors these days tend to have a small number of simple instructions (they are called Reduced Instruction Set Computers, or RISC) because it's more efficient than having lots of instructions (Complex Instruction Set Computers, or CISC).
Applying what we have just learnt
It’s quite common to think that programming is some kind of special talent that people either have or don’t have, but this isn't so!
Like all skills, programming is something you learn through practise, making mistakes, and learning from them.
An important skill that programmers need is to be able to communicate with others, especially when they are working out what the program should do; they also need to be persistent when finding and fixing bugs.
Bugs happen all the time in programming, so being able to identify where the bug occurs and problem solving how to fix it is incredibly important.
It doesn’t matter how experienced you are at programming, there will always be bugs that need to be found, and fixed.
That’s why the word “debugging” is so important to programmers.
Simple robotic toys like the "Bee-Bot" have a very similar set of commands, and can be used to follow up.
Now that you have experienced being a programmer, what did you think was the most challenging part of being a programmer?
Seeing the Computational Thinking connections
Throughout the lessons there are links to computational thinking. Below we've noted some general links that apply to this content.
Teaching computational thinking through CSUnplugged activities supports students to learn how to describe a problem, identify what are the important details they need to solve this problem, and break it down into small, logical steps so that they can then create a process which solves the problem, and then evaluate this process. These skills are transferable to any other curriculum area, but are particularly relevant to developing digital systems and solving problems using the capabilities of computers.
These Computational Thinking concepts are all connected to each other and support each other, but it’s important to note that not all aspects of Computational Thinking happen in every unit or lesson. We’ve highlighted the important connections for you to observe your students in action. For more background information on what our definition of Computational Thinking is see our notes about computational thinking.
Creating a sequence of instructions for this lesson exercises algorithmic problem solving, as it requires students to create an algorithm to accomplish a task.
Computational algorithms are based on input, output, storage, sequence, selection and iteration.
This exercise focuses on sequencing instructions.
Examples of what you could look for:
Are students able to see what the result will be of their program before it is executed?
Did students successfully create a set of step by step instructions for the robot to follow?
In this lesson we have abstracted out writing a program and using a programming language to very basic instructions of move forward, turn left or turn right.
Students write these instructions down in familiar words or symbols and give the instructions to the Bot verbally, which removes the need to know how to use a programming language and implement this on a computer.
This supports students to understand how sequence works in programming, without being overwhelmed with technical terminology and tools.
Examples of what you could look for:
Can students see the stages of programming (designing the program, testing it, and debugging it), even though the environment is removed from physical devices?
In our everyday lives we don’t often give instructions as specifically as saying “Turn right, take a step forward, take another step forward, turn right”, and it seems much more straightforward to simply say “please go over there”.
But when we program we have to be very specific because we have to tell computers exactly how to do each thing and limit ourselves to the few instructions that they can follow.
Students need to work on taking something they are familiar with, like “go to that square” and identifying the simplest individual steps that need to happen for someone to accomplish this.
Also, programs can be written incrementally; instead of trying to solve the whole problem, students were encouraged to write a few steps first, test these, and then add to them.
Breaking a program down into smaller components makes the task less overwhelming.
Examples of what you could look for:
Do students work on the problem incrementally?
Can they take the action of “going to the left” and break it down further to the instructions “turn left, move forward”?
Generalising and patterns
Many different patterns are likely to emerge when students write their programs, and when students recognise these patterns they can reuse some of them multiple times, rather than having to figure out each step again.
For example, students may recognise that if they want to turn around 180° they can repeat “left” or “right” twice, and they can repeat this same sequence whenever they need to do this movement.
Or if they need to move diagonally across the grid they can take the group of instructions “left, go forward, right, go forward” (right and left swapped depending on which way you’re going) and repeat this as many times as they need to cross the board.
Examples of what you could look for:
When students recognise patterns in their programs and in how they move the bot do they also see that they can reuse these instruction sets whenever they need the bot to make the same movement?
There is a clear way for students to evaluate their programs in this activity, which is simply to ask themselves “did it work?”.
By testing their programs they can evaluate whether their instructions accomplish the task.
There are multiple programs students could write that will get the Bot to the goal square, but some of these are probably more efficient than others.
This could be measure be either the number of instructions, or the amount of time used.
Examples of what you could look for:
Did students recognise that multiple solutions (many different sets of instructions) are possible?
Were they able to compare some and evaluate which ones use fewer commands and are the fastest?
Are they able to see that measuring the time taken is a practical measure of the performance of a program, but counting the number of instructions is more consistent? (As it doesn't depend on who has the Bot and Tester roles).
When students encounter bugs in their programs they will need to logically step through their instructions one by one to locate the bug.
They will need to think about what they expect to happen when each instruction is followed, and if they do not get the result they expected they will need to identify what went wrong, why it went wrong, and how to fix it.
This requires students to apply their logical thinking skills.
Examples of what you could look for:
Do students go through their instructions and predict what will happen each time one is executed?
When they debug their instructions do they use a logical method to do this?
Such as stepping through each instruction one by one and checking if what they expected to happen does happen, or comparing their program to previous version which didn’t seem to contain a bug?
This definition is not available in English, sorry!