Chapter 5 — Glitch and the Gentle Magnifying-Glass

Glitch is not an animal. It’s not a person, either. Glitch looks like a tiny magnifying glass. It floats over a line of code. A warm light glows under the glass. This light is soft and welcoming. It’s not a scary red alarm. Glitch shows you where a problem is. It says, “Come look at this gently.” It never says, “You broke it!”

This is super important. Glitch helps you find bugs. Bugs are problems in your code. Glitch makes sure you don’t feel bad. It reminds you: “There’s always a reason.” “Bugs are findable.” You don’t need to feel ashamed.

Sometimes, movies or games make bugs seem scary. They show a programmer who “broke” everything. Or they say someone “made a mistake.” They act like it’s a big failure. This can make kids afraid of bugs. Being scared makes it harder to fix things. You can’t think clearly when you’re worried. Glitch helps take away that bad feeling. Glitch shows you that bugs are just information. They are chances to learn more. Bugs are not about being bad. They are not about failing.

Loop was trying to make her game character, Pip, jump. Pip was a little pixelated frog. Loop typed in the code. She pressed the “Run” button. Pip was supposed to leap high. Instead, Pip just wiggled. He wiggled sadly on the ground. Loop sighed. “Oh, Pip,” she mumbled. “What did I do wrong?”

Suddenly, a tiny glow appeared. It floated right over a line of code. It was Glitch! The warm light pulsed softly. Glitch didn’t flash red. It didn’t make a loud noise. It just hovered there, gentle and curious.

Loop smiled a little. “Thanks, Glitch,” she said. “I forgot. There’s always a reason.”

She tapped her chin. “Okay, Pip. Let’s figure this out. Glitch helps us remember some important things.”

First, Loop said, “Every bug has a reason. Code always follows rules. It’s like a recipe. If the cake doesn’t rise, there’s a reason. Maybe you forgot the baking powder. Code is the same way. It doesn’t just break for no reason. We just need to find the logic.”

Loop looked at the screen. A small red message popped up. It said: TypeError: cannot multiply sequence by non-int of type 'float'.

“See that?” Loop pointed. “Glitch reminds us to read the error message carefully. These messages are super helpful hints. They tell you where the problem is. They also tell you what kind of problem it is. This one says ‘TypeError.’ That means I used the wrong kind of data. It also mentions ‘multiply sequence by non-int of type float.’ That’s a big clue!”

Loop scrolled through her code. She found the line Glitch was hovering over. It was where she calculated Pip’s jump height.

jump_power = "5" * jump_strength

“Aha!” Loop exclaimed. “I see it! I put quotes around the number five. That makes it text, not a number. You can’t multiply text like that. It’s like trying to say ‘hello’ five times using math. The computer gets confused.”

Loop quickly changed the line: jump_power = 5 * jump_strength. She ran the code. Pip still wiggled. But the error message was gone!

“Okay, new problem,” Loop said. “No error message this time. So, what’s next, Glitch?”

Glitch pulsed its warm light.

“Right!” Loop remembered. “Print debugging! This is a great way to see inside your code. You can make the computer tell you what’s happening. It’s like asking the code, ‘Hey, what number are you holding right now?’”

Loop added a new line of code. print(jump_power) she typed. She also added print(jump_strength). She wanted to see the values.

She ran the code again. In the console window, she saw: 50 10.0

“Hmm,” Loop thought. “Jump power is 50. Jump strength is 10. That seems okay. But Pip still isn’t jumping. Maybe the problem is later in the code.”

“Another cool trick is stepping through with a debugger,” Loop explained to Glitch. “It’s like pressing pause on a video game. You can stop the code. Then you look at everything. You can see what numbers are stored. You can move the code forward one tiny step at a time. It helps you watch the code’s journey. You see exactly when things go wrong.” Loop showed Glitch how to set a breakpoint. She clicked a spot next to a line of code. When she ran the program, it stopped there. She could see all the variables. She could click “next step” to move forward slowly.

“This is really good for tricky bugs,” she said. “But sometimes, you just need to talk it out.”

Loop reached for a small, green rubber duck on her desk. “Okay, Mr. Quackers,” she said to the duck. “Here’s the problem. Pip the frog isn’t jumping. My code says…”

Loop started explaining her code line-by-line. She talked about the jump_power variable. She talked about how Pip’s position was updated. As she explained, she suddenly stopped.

“Wait a minute!” she gasped. “I’m setting Pip’s y position to 0 after I add the jump power! That means he always lands back on the ground immediately!”

She had found the bug! This was rubber-duck debugging. Explaining the code out loud often helps you see your own mistakes. It’s like your brain hears it differently.

Loop quickly swapped two lines of code. She put the y position update before the jump_power calculation. She ran the game. This time, Pip leaped high! He did a perfect pixelated flip.

“Yes!” Loop cheered. “Good job, Pip! Good job, Mr. Quackers!”

Glitch’s light pulsed happily.

“Sometimes bugs are really hidden,” Loop said. “Then we use something called bisecting. It sounds fancy, but it’s simple. You comment out half your code. Then you run it. If the bug is gone, you know it was in the half you commented out. If the bug is still there, it’s in the other half. You keep cutting the code in half. You do this until you find the exact spot. It narrows down the bug location really fast.”

Loop pulled out a small notebook. It had “Bug Journal” written on the cover. “And finally,” she said, “I always keep a debugging journal. I write down what I tried. I write down what I learned. Sometimes, I find the same kind of bug again later. My journal helps me remember how I fixed it. It also helps me see patterns. It’s like a detective’s notebook for my code.”

Loop looked at Glitch. “So, remember, Glitch is the bug-finder. There’s always a reason for a bug. Read the error message. Inspect your variables. Use print statements. Step through your code. Talk to a rubber duck. Bisect your code to find the exact spot. Keep a journal. Find it gently. Bugs are information, not failures.”

She smiled. “Not hard. There’s always a reason. Find it gently.”