Most school "robotics" programs stop at a tablet. A student drags a few blocks together, a sprite moves across a screen, and everyone calls it coding. It's not nothing — but it's also not what most parents picture when they hear the word "robotics."
The gap shows up the first time a student has to make something real work. Block-coding gives instant, forgiving feedback: if the logic is wrong, the sprite just doesn't move, and you try again. A physical build doesn't forgive like that. A loose wire, a wrong polarity, a motor mounted a few degrees off — the robot doesn't move, and the student has to figure out why, with their hands, not just their eyes.
That's the skill we're actually after. Debugging a real circuit teaches patience and systematic thinking in a way that debugging a script on a screen doesn't quite match — because the causes are physical, and physical causes have to be found by touching, checking, and testing, not just re-reading code.
We still use block-coding at GNR Robotics — Scratch shows up in our Foundation Builders and Junior Innovator bands, and it's a genuinely good on-ramp to logic and sequencing. But it's a step, not the destination. By the time a student reaches our Junior Innovator band, they're wiring their own sensors and motors. By TechPreneurship, they're combining embedded systems, Python, and a pitch for what they built.
The point isn't that coding on a screen is wrong. It's that "robotics education" should include a robot — something with weight, wiring, and a chance to actually fail in front of you, so a student learns to fix it instead of just restarting the level.