Debugging is the skill, not the obstacle
Most of a robotics session is spent with something not working. That is not the friction around the learning. It is the learning.
Ask an adult what they remember from a science class and you will usually get a demonstration that worked. Ask an engineer what taught them the most and you will get a week they spent finding out why something didn't.
Robotics is unusual among school subjects because the feedback is immediate and impossible to argue with. The robot either turns left or it doesn't. There is no partial credit from a machine.
The instinct we are trying to replace
The untrained response to a robot that misbehaves is to change something and try again. Sometimes that works, which is precisely the problem: it teaches that fixing things is a matter of luck and persistence rather than reasoning.
The habit we want instead is narrowing. Before touching anything, decide which half of the system the fault is in, then halve it again.
What we teach learners to ask, in order
- 01Is it getting power? Check at the source, not at the symptom.
- 02Is the signal arriving? Print the sensor value before blaming the code that reads it.
- 03Does the value mean what I think it means? A distance sensor reading 0 usually means nothing is in range, not that something is touching.
- 04Did the last change cause this? If yes, undo it before adding a second change on top.
- 05Can I make it fail on purpose? A fault you can reproduce is a fault you can fix.
A learner who can reproduce a bug deliberately has already done the hard half of the work.
Why instructors resist letting it happen
It is genuinely uncomfortable to watch a twelve-year-old stare at a robot that will not move when you can see the loose connector from across the room. Fixing it takes four seconds and buys visible progress.
It also removes the entire lesson. Our instructors are trained to answer a stuck learner with a question that narrows the search ("which part of this are you sure about?") rather than with the answer. The robot gets fixed a few minutes later, by the person who needed to fix it.
Where it goes after robotics
Narrowing a fault is not a robotics skill. It is how you find an error in a spreadsheet, a fault in an argument, or the reason a piece of code you wrote last month has stopped working. Robotics is just the fastest place we know to teach it, because the feedback loop is measured in seconds and the failure is physical enough to be interesting.
- Method
- Learning
- Engineering
