Living Museum of Learning
The Shaky Fingers and the Tiger
Situation
Enning came to class with an existing Chinese chess program.
Donald didn't want to teach her another isolated programming technique.
“Let's improve your Chinese chess board code.”
The code worked, but some of the line() statements had become very long, filled with repeated coordinate calculations.
Enning's first idea was simple:
Make the names shorter.
She thought about replacing col with a.
Donald stopped her.
Shorter is not automatically better.
A variable name should help a future reader understand the code, not merely save a few characters.
So they looked again.
Turning Point
Enning found a better opportunity.
Two functions contained the same kinds of coordinate calculations again and again.
She began pulling repeated calculations into intermediate variables.
Then Donald challenged her again.
When she wanted to apply exactly the same refactoring to another function, he asked:
“Can we find a different way this time?”
She thought again.
And she did.
The code became cleaner not because she had learned one magic refactoring recipe, but because she was beginning to see the geometry inside the code.
Then they encountered a much bigger idea.
There were many long line() statements throughout the Chinese chess board. The only thing that really changed was the logical position of the two endpoints.
Donald suggested:
“We can create a small tool of our own to draw lines using those small integers.”
Enning wrote her first version of:
function drawLine(firstCol, firstRow, secondCol, secondRow) {
line(gridX + firstCol * side, gridY + firstRow * side,
gridX + secondCol * side, gridY + secondRow * side);
}
She wanted to put another line() inside the function.
Donald stopped her again.
This tool was for one line.
It should be flexible enough to be used many times.
The ugly coordinate calculations could stay hidden inside the tool. The rest of the Chinese chess program could simply talk in logical coordinates.
Enning then began replacing the old line() calls one by one.
The Tiger
Everything was going well until she reached a for loop.
for(let i = 0; i < 9; i++) {
drawLine(i, 0, i, 4)
}
The loop was a tiger. 🐯
Enning wasn't afraid of drawLine() anymore.
But she hesitated when she had to put the loop variable i into her own function.
Her fingers became shaky.
Then she wrote:
drawLine(0 + i, 0, 0 + i, 4)
and said:
“I'm not sure if it works. Let me try.”
That sentence was more important than the code.
She was unsure.
She was afraid it might be wrong.
And she tried it anyway.
It worked.
When the Brain Disappeared
Later, Donald asked her to explain what the four parameters of drawLine() meant.
Suddenly, Enning started speaking as if her brain had temporarily left the room. 😂
Donald stopped her:
“If you can't speak, write it down.”
She wrote:
first column
first row
second column
second row
Her brain came back.
The only remaining problem was getting the names into valid JavaScript identifiers:
first col ❌
firstCol ✅
😂
A Different Kind of Mathematics
A few hours later, Enning sent Donald a screenshot of three school mathematics problems she couldn't understand.
The first involved powers:
2^2(2^120 × 5^120)
3^2(5 + 6^2)
3^2(5 × 6^2)
2^3 × 2^5
3^2 × 5^2
She wasn't simply missing calculations.
She was learning to see the structure hidden inside them.
The second problem was more entertaining.
She had 25 eggs, 17.5 were used, and she multiplied the two numbers.
Donald asked:
“You have more than 200 eggs?”
Enning immediately realized:
“Oh, I need a minus first...”
Sometimes mathematics needs a calculator.
Sometimes it needs common sense. 😂
Then came the beautiful one.
An English-school geometry problem involved a pentagram and a given area relationship of 6/7.
Enning had already worked through most of the problem.
Donald gave her only a tiny hint.
She suddenly shouted:
“1/7 + 2/5!”
Emergence
In one day, Enning moved through several layers of thinking:
Shorter code
→ meaningful code
→ recognizing repetition
→ creating an abstraction
→ using the abstraction inside loops
→ testing an idea she wasn't sure about
→ explaining what she had built
→ seeing mathematical structure
→ solving a geometry problem from a tiny hint
The Chinese chess board was only the playground.
The real lesson was learning to look beneath the surface.
A long line of code can hide a simple idea.
A complicated mathematical expression can hide a simple pattern.
A frightening for loop can hide a perfectly ordinary variable.
And a difficult geometry problem can sometimes collapse into:
1/7 + 2/5!
Learning
Enning did not become fearless today.
Something better happened.
She became willing to continue while uncertain.
“I'm not sure if it works. Let me try.”
That may be one of the most valuable sentences a learner can say.
Programming and mathematics both reward the same habit:
Don't panic when you don't know.
Look for structure.
Try something.
See what happens.
Theme
From shortening code to seeing structure.
What Is Possible?
A learner can turn repeated implementation details into a tool of her own.
How Does It Happen?
Question the first idea. Look for another way. Make the hidden structure visible. Test it.
Why Does It Matter?
Because programming and mathematics are not primarily about remembering rules.
They are about learning to see.
And sometimes the biggest step is simply having the courage to type the uncertain thing and say:
“Let me try.”
