First Programs, Sequences and Debugging

You can tell a robot what to do with a command. One command gives one instruction, such as "move forward". A list of commands for a robot or computer is a program.

Make a plan, then write code

An algorithm is a plan made of steps for a job. Think about brushing your teeth. You put toothpaste on the brush before you brush. Each step has a place in the plan.

A program is a plan written in commands a computer understands. Those commands are called code. Writing them is coding, or programming. Your robot may understand "forward" but have no command called "visit the door". You must break that job into commands it knows.

Put the commands in order

The order of commands is a sequence. In these programs, the robot follows one command, then the next. It starts with the first and works toward the last.

Imagine a robot facing away from you. Compare these programs:

The commands are the same, but their order changes the stop square. The robot cannot guess that you meant the other route.

Sometimes a swap keeps the same result. On a number track, start at 0. Move forward 3, then forward 2: you stop at 5. Start at 0 again. Move forward 2, then forward 3: you also stop at 5. Trace the moves to check a swap.

Play the robot game

Lay command cards in a row. One person reads the cards. Another acts as the robot, following each card exactly. Use "step forward", "turn left", and "turn right" on a clear path. If the route misses the target, look at the cards. The person acting as the robot should not guess a better route.

People write programs for tablet games, washing machines, microwaves, and traffic lights. The commands make different things happen, but their order still matters.

A floor robot follows commands you enter with its buttons. On a mat made for that robot, one move takes it one square. First choose a start square and the way its front will face.

Know what each button does

To reach the square on its right, use turn right, forward.

Left and right belong to the robot. If it faces you, its right is on your left. Stand behind it, or face the same way with your own body. Now your right matches the robot’s right.

Count the moves to the cheese

The cheese is 2 squares ahead, then 1 square right. Trace that path with a finger. Count each new square you enter. Do not count the start square as a move.

1. forward: move onto the first square ahead.
2. forward: move onto the second square ahead.
3. turn right: stay on that square and face right.
4. forward: move onto the cheese.

The full program is forward, forward, turn right, forward.

Write arrows before pressing buttons

You can use arrows to record the commands:

• ↑ means forward.
• ↓ means backward.
• ↰ means turn left.
• ↱ means turn right.

The cheese program is ↑ ↑ ↱ ↑. The forward arrow means "follow the robot’s front". After a turn, it does not mean "go toward the top of the paper".

Get ready to run

On many floor robots, button presses stay in memory. New presses join the old commands. Press Clear before entering a new program on these robots. Then press the command buttons in the order you wrote.

Put the robot on Start, facing the planned way. Press Go to run the whole program. If the robot misses the target, check its start square and facing as well as the commands.

A sprite is a character or object you can control on a screen. It could be a cat, a car, or a ball. Select the sprite you want to program, then drag blocks into its code area.

Snap the blocks together

Connected blocks make a sequence. Some apps read left to right. Others read top to bottom. Follow the direction your app uses. A loose block does not run with the connected program.

Put a start block such as "when green flag clicked" first. Pressing the green flag starts the attached blocks. Each sprite has its own code, so check that you selected the right character.

Choose what happens

Motion blocks move or turn your sprite. Many have a number you can change. In an app that counts grid squares, "move right 3" moves three squares. It reaches the same place as three "move right 1" blocks.

Read the command words carefully. A screen command called "move right" can move toward the screen’s right side, whichever way the sprite faces. A floor robot’s forward command follows its front.

Looks blocks can show words, change size, hide, or show the sprite. Sound blocks play sounds. They belong in the sequence too.

Help the cat reach a ball

The ball is 4 grid squares to the cat’s right. You want the cat to reach it before speaking.

1. Start with "when green flag clicked".
2. Snap on "move right 4".
3. Snap on "say Got it!".

Press the flag. The cat moves first, then says "Got it!". Swapping the last two blocks makes it speak before moving.

Play notes in order

Sound order changes a tune. "Do, re, mi, do" begins "Are You Sleeping, Brother John?". "Mi, re, do, do" has a different order. In apps with both sound choices, "play sound until done" waits for a sound to finish. "Start sound" lets the next block begin straight away, so sounds can overlap.

Give each test the same start

Place a "go home" or position block just after the start block. It puts the sprite back in its start place. A position reset sets only its place. If your program changes its facing, size, or whether it shows, add blocks to set those back too. A hidden sprite needs "show"; moving it home alone will not make it visible.

Before you run a program, predict what it will do. A prediction says what you think will happen. You can work it out by tracing: follow the code one command at a time.

Give your counter a front

Put a counter on the start square. Draw a small arrow on it to show its front. Point to the first command and act it out. Then point to the next command.

Keep track of two things: the square and the facing. A forward or backward changes the square. A turn changes the facing. Keep the counter on the same square while it turns.

Follow a route with two turns

Start facing toward the top of the mat. Trace this program:

forward, forward, turn left, forward, turn left, forward

1. The first forward takes you one square ahead of Start.
2. The next forward takes you two squares ahead of Start.
3. Turn left on that square. Your front now points left.
4. Move one square left.
5. Turn left again. Your front now points toward the bottom.
6. Move one square toward the bottom.

You finish one square ahead of Start and one square left. You face the bottom of the mat. Count the moves after each turn in the new facing direction.

Leave a trail on paper

For a longer program, write a short note after each command. For the first three steps above, your notes could be "1 ahead", "2 ahead", and "2 ahead, facing left". The last note tells you the final square and facing.

A turn takes a step in your list, but no step across the mat. If you move onto a new square during a turn, your trace will put every later move in the wrong place.

Trace a sprite too

Read "when green flag clicked", "move right 2", "move up 1", "say Hi!". The flag starts the code. The sprite moves two grid squares right, then one up. Only then does it say "Hi!".

Now run the program and watch each action. If the result differs from your prediction, read the commands again. You may have traced a move wrongly, or the code may need a fix. Find the step where your trace and the run first part ways.

A prediction is stronger when you can say why. Logical reasoning means using what you know about each command to work out what happens. You might say, "It reaches the flower because three forward moves cover the three squares."

Compare two routes

Start with a robot facing ahead. A star is one square ahead and two squares right. Trace each program from the same start.

• Program A: forward, turn right, forward, forward.
• Program B: turn right, forward, forward, forward.

Program A moves one ahead, then two right. It reaches the star. Program B turns before moving. It travels three squares right along the start row, so it misses.

There is another route to the star: turn right, forward, forward, turn left, forward. It goes right first, then ahead. Both that route and Program A reach the target. The paths differ, and their final facing differs too.

Think about one change

If "forward 3" becomes "forward 2", that move ends one square sooner. The next command begins from the new place. Trace the rest to see where the whole program ends.

Changing a left turn to a right turn changes the facing at that point. Later forward moves follow that new direction. Do not change only the turn in your drawing and leave the later path untouched.

Spot commands that undo each other

A right turn followed by a left turn puts the front back where it was. Both turns happen on the same square. So forward, turn right, turn left, forward ends where forward, forward does, with the same facing.

Use a miss as a clue

A robot stops short of a flower. First check its start square and facing. Then trace the code. On a straight path from the right start, a missing forward move may explain the miss. A wrong turn or number can also cause a miss. Look at the actual steps before choosing a fix.

If a prediction was wrong, ask, "Which step surprised me?" Act out that command. Its meaning helps you explain what happened.

A bug is a mistake in code that stops the program doing what you wanted. Debugging means finding and fixing bugs. Even expert programmers need to do it.

Look at the kind of mistake

These clues help you choose what to inspect. Check them against your goal and your route.

Compare code with the job

The cheese is two squares ahead and one right. The robot starts facing ahead. The program is forward, turn right, forward, forward. It goes only one ahead before turning, then two right. All four needed commands are there. The order is wrong. Use forward, forward, turn right, forward.

A flower three squares straight ahead needs three forward moves. A list with two forwards has a missing command. A list with four forwards has an extra command and goes past the flower.

A left turn in place of a needed right turn is a wrong command. A sprite’s "move right 5" goes past a ball four squares right. Its number should be 4.

Listen for a sound bug

In some apps, "start sound" begins a sound and moves straight on. Two of these blocks can start sounds that overlap. If you want one sound to finish before the next begins, use "play sound until done" blocks. The wrong sound-block type can make your tune run together.

Check more than the code

The robot may begin on the wrong square or face the wrong way. On a robot that keeps commands, an old list may remain because Clear was missed. Check these before changing a correct route.

A program can have a bug even when it runs to the end. Watch what it does and compare that with your goal. Finishing a list is not the same as reaching the target or playing the sounds in order.

Finding a bug is easier when you know what you expected. Say the goal and the result: "I wanted the robot on the ball. It stopped on the other side."

Watch where the route first changes

Start facing ahead. The ball is one square ahead and two left. Your code says forward, turn right, forward, forward.

The first forward matches your plan. At the second command, the robot faces right. Your plan needs it facing left. This is the first wrong step, even though it has not left the square yet. The right turn is the bug.

Later moves may follow their commands correctly but still start from the wrong facing. Work from the first difference so you do not try to repair every later square separately.

Step through slowly

Point to one command at a time. Act it out with a counter, then compare it with the drawn route. Keep the arrow cards next to the mat so you can check both together.

Stop when a command differs from the plan. A needed command might also be missing just before that point. If your plan needs a turn but the next command is forward, check for the missing turn.

Make a fast program easier to watch

A sprite can move so quickly that you only see its last place. Put a "wait" block between actions to slow the run. Now you can notice whether it spoke too early or moved too far.

You can also test just the first few commands. Start from the planned start and run that part. If it reaches the right square and facing, look later in the code. When you test a longer part, begin from the same start again.

Talk through the blocks

Tell a partner what each block does. You can even tell a toy: "First it moves ahead. Next it turns right." Speaking the turn’s name may help you hear that it should be left. A partner can check the route while you point to the code.

If nothing starts, check the starting things. Is a start block attached? Are the blocks on the right sprite? For a floor robot, check Start, facing, and cleared memory before looking for a wrong move.

Once you find the bug, change the part that is wrong. Keep the parts that already do their jobs. You might swap commands, add one, remove one, or change a command or number.

Fix the turn

The ball is one square ahead and two left. The robot starts facing ahead. You found the wrong turn in forward, turn right, forward, forward.

Change just turn right to turn left. Your new program is forward, turn left, forward, forward. The first move still takes the robot one square ahead. The new turn faces it left. The last two moves take it to the ball.

Changing the first forward would not fix that wrong turn. Match your change to the clue you found.

Test one change at a time

Make one change, then test. If you change the turn and remove a forward together, the result changes in two ways. You will not know which change helped.

Use the same starting things for the test:

1. Put the robot back on Start.
2. Face it the planned way.
3. Clear stored commands and enter the fixed program.
4. Press Go and watch the whole route.

For a sprite, reset the starting place and any changed facing, size, or showing. Then press the green flag.

Check the whole job

A fix might let the robot get farther and reveal another bug. It could make the right turn but still stop short. Check all the steps, including the last move, words, and sounds. Keep finding and fixing bugs until the whole program meets your goal.

If your change did not help, change it back and trace again. Look for the first difference between the plan and the run. You do not need to start a completely new program each time.

You can say, "I haven’t fixed it yet." A test tells you what to look at next. When you spot the next bug, make another small change and try again.

Choose what you want your program to do. Say the goal in plain words, such as "The car drives to the garage and beeps." Decide where it starts and where it should finish.

Draw or tell the plan

Trace a route with your finger, or draw it on a grid. For a story, sketch the actions like pictures in a comic strip. Say what happens first, next, and last.

This plan is your algorithm. You can change it before spending time snapping blocks or pressing buttons.

Break a big step into small commands

A floor robot does not have a button called "visit the garage". Look at the route and use commands it knows.

The garage is two squares ahead and one left. The robot begins facing ahead. Your plan says, "Go two squares, turn toward the garage, then go one square."

Build the code step by step:

1. Two squares ahead needs forward, forward.
2. Facing the garage needs turn left.
3. The last square needs forward.

Write ↑ ↑ ↰ ↑, then trace it to check. The turn is on the second square ahead, before the last move.

Plan a sprite’s story

A cat walks in, says "Hello!", then jumps. In a grid app, you could use "move right 3", "say Hello!", then "hop" after the start and reset blocks. The speech belongs between walking and hopping because that is the story you planned.

Select the character before giving it blocks. Each sprite has its own code. Get one character working before building another character’s part.

Check both the plan and the code

Lay the code next to the drawn path or story pictures. Does each planned step have commands? Are they in the right places?

If the code follows the plan but still misses the goal, check the plan too. You may have counted the route wrongly. If the plan is right and a block differs, fix the block.

More than one program can reach a goal. A shorter one is often easier to read, but it must still do every part of the job. Check the route and the finish before choosing it.

Testing means running your program to check that it does what you wanted. You can test before the whole program is finished. A bug is easier to find in a few new blocks than in a long untested list.

Add one small part

Build the first few commands. Predict what they do, run them, and check the result. Fix any bug before adding the next part.

For a car that should reach a garage and beep, first get the journey working. Check the stop square. Then add the beep and check that it happens after the journey. Each new part has a clear job you can test.

Let the goal guide your test

Look for every part of the goal. A robot might reach the right square but face the wrong way. A sprite might reach its place but say the wrong words. Watch and listen to the whole run.

Ask a friend to test too. Tell them the goal and let them say what they saw. Kind feedback names something that works and something to fix: "The car reaches the garage. The beep needs to come after the move."

Make code easier to read

Look for commands that undo each other. A right turn followed straight away by a left turn leaves the robot on the same square, facing the same way. If your goal only needs that route and finish, you can remove both turns.

In a grid app that allows numbers in move blocks, four "move right 1" blocks can become one "move right 4" block. The sprite reaches the same place. Check that your goal does not need separate actions between those moves.

Test again from the start after tidying. A shorter list is useful only if it still does the job.

Share what you learned

Show a partner each part of your code and say what it does. Tell them about one bug you fixed. You might say, "I counted Start as a move. Now I count only the squares the robot enters."

Use that lesson on your next program. If left and right were tricky, check from behind the robot before entering its turns. If a block was loose, check the joins as you build.