Bug Hunt Workshop
This lesson is different. There is no new concept to introduce, no new vocabulary to define. This is where you practice everything from the past eight lessons under one roof. You will encounter bugs, describe them, form hypotheses, ask for help effectively, verify fixes, and take ownership of the result. The skills only become real when you use them together.
Your Toolkit for This Workshop
Here is a summary of every skill you have developed so far in this module: From Lesson 1: Approach bugs with curiosity. They are gaps, not failures. From Lesson 2: Read the full error message — type, message, line number, stack trace. From Lesson 3: Describe the bug with three parts — expected, actual, already tried. From Lesson 4: Build fix requests with four elements — context, bug, code, clear ask. From Lesson 5: Verify the fix — understand it, apply it, test the broken scenario, test nearby behavior. From Lesson 6: Change one thing at a time. Keep a hypothesis log. From Lesson 7: Verify the goal, not just the error. A confident AI can be wrong. From Lesson 8: Own what you ship. Explain the fix in your own words before moving on. These eight skills, used in sequence, constitute a complete debugging workflow. The workshop is your chance to run that workflow from start to finish.
Read the error. Describe the bug. Build the fix request. Apply one change. Test the goal. Verify the fix. Own the code. This is the sequence you will use in every project for the rest of your life as a builder.
Put the debugging workflow steps in order by matching each step to its number.
Terms
Definitions
Drag terms onto their definitions, or click a term then click a definition to match.
Workshop Scenarios
The following three scenarios are the practice bugs for this workshop. Your teacher may assign them individually, in pairs, or as a class. For each scenario, run the complete debugging workflow and document each step in your notes. Scenario 1 — The Silent Form: A contact form collects a name and message. When the user clicks Send, nothing happens — no confirmation, no error, no network request. Where do you start? Scenario 2 — The Wrong Count: A leaderboard shows scores, but one player's score is always off by one. The calculation looks right at first glance. The error does not appear in the console. What is your hypothesis? Scenario 3 — The Vanishing List: Items added to a to-do list appear for a second, then disappear. Refreshing the page shows an empty list. The console shows no error. What mechanism might cause data to vanish? For each scenario, write out: your bug description, your AI fix request (as if you were sending it), and the hypothesis you would test first.
Write down each hypothesis, change, and result as you work through a scenario. A debugging log is not just good practice — it is the evidence that shows your thinking, and it will help you spot patterns in your own mistakes over time.
In the full debugging workflow, why does 'own the code' come last, after verifying the fix?
In Scenario 2 (the score off by one), the calculation looks correct and there is no console error. What is your best first step?
Full Workflow Bug Hunt
- Choose one of the three workshop scenarios from this lesson (or use a real bug from your own project).
- Complete and document all eight steps:
- 1. Read the error (or note that there is no error and why that matters).
- 2. Write the three-part bug description.
- 3. Write the full AI fix request.
- 4. State your first hypothesis.
- 5. Describe the one change you would make first.
- 6. Describe how you would test it.
- 7. Describe how you would verify the goal, not just the symptom.
- 8. In two sentences, explain the fix in plain English as if you are owning the code.
- Present your workflow documentation to your class or partner. The goal is not to have the right answer — it is to show a complete, reasoned debugging process.