Computer Science Grade 3 Sequencing and Debugging Finding Mistakes

Grade 3 Computer Science Study Guide: Sequencing and Debugging – Finding Mistakes

1. The Driving Question

"If you tell your friend to make a peanut butter sandwich by saying ‘put the peanut butter on the bread’ but they smear it on the counter instead, whose fault is it—yours or theirs? And how do you fix the instructions so the sandwich turns out right?" This is the same problem computers have: if a program doesn’t do what you want, is the mistake in the order of the steps (sequencing) or in the details of the steps (debugging)? How do you find and fix it without starting over?

2. The Core Idea – Built, Not Listed

Imagine you’re teaching a robot to tie its shoelaces. You write down the steps: 1. Hold one lace in each hand.
2. Cross the laces.
3. Tuck one under the other.
4. Pull tight.

But when the robot tries, it crosses the laces, then drops them, then picks up a crayon instead. The problem isn’t that the robot is "bad at tying"—it’s that your instructions were missing steps (like "don’t let go of the laces") or had them in the wrong order (like pulling tight before tucking). Sequencing means putting steps in the right order so the whole task works. Debugging means finding and fixing mistakes in those steps—like a detective looking for clues in what went wrong.

Here’s how this works in real code: - A program is like a recipe: a list of steps a computer follows.
- A bug is a mistake in the recipe that makes the computer do something silly or wrong.
- Debugging is the process of finding and fixing bugs, like rewriting a step in the recipe so the cake doesn’t burn.

Key Vocabulary:
- Algorithm: A step-by-step set of instructions to complete a task.
Example: The steps to brush your teeth (wet toothbrush, add toothpaste, brush for 2 minutes) are an algorithm.
- Sequence: The order in which steps happen in an algorithm.
Example: In a dance routine, doing a spin before a jump is a different sequence than jumping first.
- Bug: A mistake in a program that makes it work incorrectly.
Example: If a video game character walks through a wall instead of stopping, that’s a bug.
- Debugging: Finding and fixing bugs in a program.
Example: If your toy car rolls backward when you press "forward," debugging might mean checking if the wheels are on backward.

3. Assessment Translation (Grade 3 Classroom Focus)

How this appears in class:
- Unplugged activities: Teachers give students a set of picture cards (e.g., "wake up," "brush teeth," "put on shoes") and ask them to arrange them in the correct sequence to get ready for school. Then, the teacher introduces a "bug" (e.g., "put on shoes" comes before "put on socks") and asks students to debug the order.
- Coding games: Platforms like ScratchJr or Code.org use block-based coding where students drag and drop commands (e.g., "move forward," "turn left"). A proficient student will: - Notice when their character doesn’t reach the goal (e.g., walks into a wall).
- Check the sequence of blocks to see if they’re in the right order.
- Debug by removing or rearranging blocks to fix the path.
- Exit tickets: Short written or drawn responses, like: "Draw the path your robot took to get to the treasure. Circle the step where it went wrong and show how you fixed it."

Proficient vs. Developing Responses:
| Proficient | Developing | |----------------|----------------| | "My robot went forward, then turned left, but it hit a wall. I fixed it by moving the ‘turn left’ block before the ‘forward’ block." | "My robot didn’t work. I changed some blocks." | | Shows the original sequence, identifies the bug, and explains the fix. | Vague; doesn’t specify what was wrong or how it was fixed. | | Uses terms like "sequence" or "bug" correctly. | Doesn’t use key vocabulary. |

Model Proficient Response (Exit Ticket):
"My code said: [Move Forward] → [Move Forward] → [Turn Right]. My robot went straight into a tree! The bug was that I needed to turn before the second ‘Move Forward.’ I fixed it by moving the ‘Turn Right’ block to the middle: [Move Forward] → [Turn Right] → [Move Forward]. Now it goes around the tree!"

4. Mistake Taxonomy

Mistake 1: Ignoring the Sequence
- Prompt: "Your friend’s robot is supposed to draw a square, but it draws a zigzag instead. What’s wrong with this code? [Move Forward] → [Turn Left] → [Move Forward] → [Turn Right] → [Move Forward] → [Turn Left] → [Move Forward]" - Common Wrong Response: "The robot is broken. I’d tell my friend to get a new one." - Why It Loses Credit: The student doesn’t analyze the sequence or suggest a fix. The teacher looks for evidence that they checked the order of steps.
- Correct Approach: 1. A square has 4 equal sides and 4 right turns (90 degrees).
2. The code has 4 "Move Forward" blocks but mixed-up turns (left, right, left).
3. Fix: Replace all turns with "Turn Right" to make 4 equal turns.

Mistake 2: Fixing the Wrong Bug
- Prompt: "Your game character is supposed to jump over a rock, but it jumps onto the rock instead. The code says: [Move Forward] → [Jump] → [Move Forward]. What’s the bug?" - Common Wrong Response: "The ‘Jump’ block is broken. I’d delete it and add a ‘Fly’ block." - Why It Loses Credit: The student assumes the block itself is wrong, not the sequence. The teacher wants to see if they consider the order of actions.
- Correct Approach: 1. The character jumps after moving forward, so it lands on the rock.
2. The bug is that "Jump" should come before "Move Forward." 3. Fix: Rearrange to [Jump] → [Move Forward].

Mistake 3: Giving Up on Debugging
- Prompt: "You’re coding a dance for your robot: [Spin] → [Clap] → [Spin]. But the robot only spins once. What’s the bug, and how do you fix it?" - Common Wrong Response: "I don’t know. Maybe the robot doesn’t like dancing." - Why It Loses Credit: The student doesn’t test the code or look for patterns. The teacher expects them to try small changes.
- Correct Approach: 1. The code has two "Spin" blocks, but the robot only spins once—maybe the second "Spin" is missing.
2. Check: Is there a second "Spin" block? (No, the third block is "Spin" but it’s the same as the first.) 3. Fix: Add a second "Spin" block or change the third block to something else (e.g., [Spin] → [Clap] → [Jump]).

5. Connection Layer

1. Within Computer Science → Loops: Sequencing is the foundation for loops (repeating steps). If you can’t put steps in order, you can’t tell a computer how many times to repeat them.
   Example: A dance routine with [Spin] → [Clap] → [Spin] → [Clap] is easier to code as "Repeat [Spin] → [Clap] 2 times."

2. Across Subjects → Writing a Story (ELA): Debugging is like editing a story. If your character’s actions don’t make sense (e.g., "She opened the door, then walked into the room, then turned the doorknob"), you have to rearrange the sequence of sentences to fix the "bug."

3. Outside School → Following a Board Game’s Rules: When a board game says, "Roll the dice, move your piece, then draw a card," but your little brother draws the card before moving, the game breaks—just like a bug in code. Debugging is figuring out which rule was skipped or done out of order.

6. The Stretch Question

"If you debug a program by changing one step, but then a different part of the program breaks, is that still a bug? How do you decide which mistake to fix first?"

Pointer Toward the Answer:
This is like untangling headphones: fixing one knot can make another part tighter. In coding, some bugs are dependencies—one step relies on another being correct. A good debugger: 1. Tests the program after each change to see what breaks.
2. Asks: "Did this fix make the problem better or worse?" 3. Starts with the earliest step in the sequence, because mistakes there can mess up everything after.

(Example: If your robot’s "Turn Left" block is actually turning right, every turn after that will be wrong—so you’d fix the "Turn Left" block first.)