Living Museum of Learning
Enning Graduates from Newton’s University
Enning wanted to draw a bicycle in p5.js WEBGL.
Her first instinct was not to make a simple 2D sketch. She jumped straight into a much harder 3D mindset.
“You can draw a 2D one simply,” I said.
Even that sounded difficult to her.
So I changed the question.
“Do you ride a bicycle?”
“Yes.”
“A little boy on the street asks you: ‘Big sister, I've never seen a bike. Could you show me how it looks like?’”
Then:
“Do you have a bike at home?”
She looked at the bicycle in the room.
And suddenly she could draw a pretty good one.
“I am looking at the bike in the room.”
Of course. 😂
The same pattern continued when we started modeling the bicycle.
“What will you use to model tires?”
“Circle.”
She had already used a torus several times, but had forgotten it.
When she finally put a torus on the 3D canvas, we needed room for the second wheel.
Her hands moved much faster than her brain again.
She translated the first wheel along all three axes with arbitrary values.
I asked:
“We want to give room for the 2nd tire we will add shortly. Is there any easy way to move this first one?”
She moved it along Z.
So I asked:
“How could the pair of wheels work together if you moved that way?”
Finally, she moved the first wheel in positive X and the second in negative X—on her own.
Then came the spoke.
She agreed that a cylinder would serve the purpose.
But the cylinder became a little floating cake inside the torus.
Instead of changing the cylinder into a long, thin bar, she adjusted its arguments until the cake became thinner.
I asked:
“Does your bike look like that?”
😂
Again, reality became the debugger.
And then class ended.
That should have been the end of the lesson.
But hours later, Enning submitted her homework.
She had added spokes to the wheels.
Not by drawing ten cylinders one by one.
She had independently written a for loop:
for(let i = 0; i < 10; i++) {
rotateZ(40)
cylinder(0, 60)
}
And then she used the same idea for the other wheel.
That was the moment everything became different.
Nobody had told her:
“Now put your spokes in a loop.”
Nobody had asked:
“Can you do the second wheel too?”
She had recognized the pattern herself:
one spoke → repeated spokes → same rule → another wheel.
The result was not merely a better bicycle.
It was evidence that something had happened inside her thinking after the class was over.
Enning's biggest challenge is not that she cannot produce results.
Quite the opposite.
She is extremely good at rushing toward a result.
Her hands often arrive before her head.
A tire becomes a tire through parameter tweaking.
A spoke becomes a cake and then a thinner cake.
A wheel moves somewhere before she has thought about the relationship between the two wheels.
So the secret weapon is simple:
Slow her down.
Not to make her slower.
To give her brain time to catch up with her hands.
Again and again, the question was not:
“What code should you write?”
It was:
“Is your tire like this?”
“Does your bike look like that?”
“How could the pair of wheels work together?”
Those questions forced her to compare the computer model with the thing she was actually trying to model.
And then, after class, something wonderful happened.
She did not merely remember an instruction.
She found a rule.
A student who often rushes toward results can gradually learn to pause, observe, and discover the structure behind those results.
Slow the process down. Ask questions that reconnect code with reality. Let the student discover relationships rather than supplying them.
The most important learning may happen after the lesson ends—when the student takes an idea, transforms it, and uses it independently.
