Living Museum of Learning
7 Lines of Code, 1.5 Hours
Enning's three-hour class on the last day of August began normally.
We started by refactoring her existing P5JS WEBGL project. Her space was already becoming surprisingly rich: planets, toruses, orbiting objects, and a large field of stars. We worked on reusing functions so that one function could draw different spheres, and another could draw different rings. We also adjusted the stars to make them lighter.
Then Enning had a great idea:
Make the stars flicker.
This was her idea. The problem was not assigned to her.
And that made the next part especially interesting.
Enning's first instinct was to search her memory for something she had used before.
She imagined making the stars move from left to right, then dragging them back again.
It was a perfectly reasonable technique—if the problem were about movement.
But the stars did not need to move.
They only needed to alternate:
white → black → white → black
Or, even more simply:
show → hide → show → hide
I told her:
“It can be simpler. Use a flag to show and hide, or show white and black.”
She got the idea.
And that was when our famous seven-line story began.
The final piece was only seven lines:
if(showStars == true) {
stroke(0);
showStars = false;
} else {
stroke(255);
showStars = true;
}
Seven lines.
One and a half hours.
She erased and rewrote those lines at least five times before I finally let her go. LOL.
The real difficulty was not the seven lines.
It was the thinking habit behind them.
Enning has accumulated many programming techniques over the past weeks. When she sees a new problem, her mind naturally searches for something she has already learned and used before.
That can be useful.
But it can also become a trap.
A student may start thinking:
“What technique do I remember?”
instead of:
“What does the problem actually require?”
Imagine an extreme example.
Yesterday, Enning learned division.
Today:
1 + 3 = ?
Her brain immediately says:
“÷!”
LOL.
She knows addition. She knows division. The problem is not knowledge.
The problem is which direction her thinking starts from.
A rote-driven approach begins with the toolbox:
“What tool have I learned that might fit?”
A stronger problem-solving approach begins with the problem:
“What is actually happening here?”
For the flickering stars, the answer was extremely simple.
They did not need to travel.
They did not need to be dragged.
They did not need a complicated animation.
They only needed two states.
Visible.
Invisible.
The flag simply remembers which state comes next.
This is why the seven-line episode is worth preserving.
We were not primarily learning if, else, true, false, or stroke(255).
Those were the materials.
The real lesson was how to approach an unfamiliar problem.
First understand the requirement at the simplest possible level.
Then look for the smallest mechanism that can produce it.
Only after that should we reach into the toolbox for techniques.
This is also why the 30+ minutes she spent repeatedly examining stroke(255); mattered.
She had already used that line dozens of times.
The goal was not to teach her that she had never understood it.
The goal was to make her slow down and examine what she was actually doing, rather than continuously guessing from familiar patterns.
Carefulness, in this sense, is not “being slow.”
It is being willing to stop, look at the problem, and choose deliberately.
And there was another beautiful part of this class.
The stars were not the assignment.
The flickering was not the assignment.
Enning invented the idea herself.
Her imagination created the problem.
Then, for 1.5 hours, she had to learn how to solve a problem created by her own imagination.
The final space looked beautiful.
But the more valuable thing was happening behind the stars.
She was beginning to practice a different sequence:
observe → analyze → simplify → solve
rather than:
remember → imitate → try