Teaching EV3 Robotics to Underprivileged Students
I keep coming back to one moment.
A fourteen-year-old, ten minutes into trying to make an EV3 line-following robot turn left, stopped poking at the colour sensor and asked: "so it's not the sensor, it's the brain?"
That is a five-word reframing of an entire computational worldview. The sensor is reporting the truth. The decision about what to do with that truth lives somewhere else. When she asked the question, she had stopped trying to fix the wrong thing.
The whole point of mentoring, I think, is to engineer more of those moments.
What I do, and don't do
When I facilitate a workshop, I am trying not to give answers. The temptation is enormous — the build is wrong, the wiring is off, the program logic is inverted, and I can fix it in twenty seconds. Twenty seconds of fixing produces a working robot and a student who has learned nothing.
So I ask three kinds of question, in order.
"What did you expect to happen?" This forces the student to articulate a hypothesis. Often it is the first time they have explicitly stated one.
"What did happen?" This forces them to observe — not to extrapolate from a vague feeling that "it didn't work" but to describe the actual behaviour. Did the robot stop? Pivot? Drift? Reverse?
"Where in the program would the difference live?" This is the move. This is the moment where they stop debugging the world and start debugging their model of the world.
Most of my facilitation time is spent finding the right pace for those three questions. Too fast and the student feels interrogated. Too slow and they lose patience and ask for the answer.
What surprised me
The students were not the problem. They were rarely confused for long, almost never angry at the robot, and frequently sharper at observation than I had been at their age. The thing they lacked was practice with patience — specifically, the patience to sit with a wrong result for ninety seconds before deciding the result was the question.
Patience is teachable. It is taught by the facilitator modelling it. If I cannot wait ninety seconds before suggesting a fix, neither can they.
What they said afterwards
I keep the feedback forms because they are more honest than my own memory of a session.
One good thing: "(I was) focused." · "New to programming, (I am) excited." · "Liked the lego element." And from a volunteer: "They were good at tech, faster to learn."
One thing to improve: "Real programming, not block based" — that came from a youth who already codes, and he was right. "More people." "Improve my focus."
Would you recommend this to a friend: all of them said yes.
The small group size is what made the session work — individual guidance is only possible when there are few enough people to reach. "More people" and "individual guidance" are in direct tension, and I have not solved it. I ran these through Impart, and later ran a version for ACCESS youths and alumni.
The point of any of this
Building things matters. Building things with people matters more. The students I worked with last year are now running their own EV3 sessions for younger students, which is the only metric of teaching I trust.