Living Museum of Learning
The Kid Who Didn’t Ask What % Meant
Situation
Leo had only had one Python class with Donald.
One week later, before starting the second class, Donald asked him to review what they had learned and make sure he could independently open a Python file and run it.
But before teaching anything new, Donald wanted to know something more fundamental:
How does Leo think when nobody tells him how to solve the problem?
So the second class began with a 20-minute, 20-problem thinking test that Donald had used for years.
Donald watched Leo carefully.
He didn't blink.
There were three mathematical problems among them, and Leo worked through them with the same quiet directness Donald had already noticed when Leo solved three 24-point problems in his first class.
Leo eventually got 18 of the 20 problems correct.
Two were wrong.
One of the errors particularly surprised Donald. Leo had essentially arrived at the correct answer, but his mind jumped to a related calculation — the answer was 2, but he somehow connected it with 10 - 2 and wrote 8 instead.
It looked much more like a thinking/output slip than a failure to understand the underlying problem.
And even after reviewing his work, Leo didn't immediately catch it.
That tiny mistake became interesting precisely because Donald had been watching how he thought, not merely counting correct answers.
Then the test ended.
Python began.
Turning Point
Donald didn't start by teaching Python syntax.
He gave Leo a tiny mystery:
a = a number
b = a number
print(a % b)
And said:
“Run it and play with it until you figure out what % does.”
That's it.
No definition.
No explanation of the modulo operator.
No example showing the answer.
Leo tried about ten different pairs of numbers.
Donald waited.
Leo didn't immediately announce a guess.
He didn't ask for the answer.
He simply experimented.
Finally Donald asked him what % did.
Leo answered:
“The remainder of a divided by b.”
Exactly.
Then Leo tried something else:
a / 0
The program crashed.
He had no idea what all the compiler/runtime output meant.
But that was fine.
Donald was there.
The computer had just told Leo:
“You have discovered one of my boundaries.”
And the class continued.
Emergence
Now the mystery of % could become useful.
Donald asked Leo to use it to distinguish even and odd numbers.
The abstract operator suddenly had a purpose:
if n % 2 == 0:
print("even")
else:
print("odd")
Leo was gradually acquiring Python vocabulary — if, else, %, input(), int(), loops, lists — but Donald wasn't presenting these as vocabulary to memorize.
Each piece appeared because Leo needed it to make the computer do something.
Then came lists.
arr = []
arr.append(3)
arr.append(5)
arr.append(10)
arr.append(2)
arr.append(7)
arr.append(8)
arr.append(15)
He learned that:
arr[0]
means the first element.
And then Donald posed the real problem:
Find the largest number without using Python's max().
Leo built the algorithm himself:
a = arr[0]
for i in range(1, 7):
if a < arr[i]:
a = arr[i]
print(a)
There it was.
A little algorithm had emerged from a completely ordinary list of numbers.
Start with a candidate.
Look at the next number.
If it is bigger, replace the candidate.
Continue.
The computer was no longer simply executing Python commands.
Leo had taught it how to think through a problem.
And now his homework was waiting:
Can you modify the algorithm to find the second-largest number?
Learning
Leo's second class was nominally about Python.
But the deeper lesson was about how to learn.
When presented with %, Leo didn't immediately demand an explanation. He experimented until he could explain it himself.
When he encountered division by zero, he wasn't protected from the error. He discovered that programs have boundaries, and Donald helped him understand what happened.
When asked to find the largest element, he wasn't given the algorithm. He constructed it.
And the next challenge — second largest — follows naturally from his own algorithm.
This is a very different relationship with programming:
Don't memorize what % means.
Run it.
Change the numbers.
Observe.
Make a hypothesis.
Try again.
Figure it out.
The code becomes a place where thinking can be tested.
And perhaps that is why the 20-minute test mattered so much.
Donald wasn't simply measuring what Leo already knew.
He was watching what Leo did when he didn't know.
Theme
Curiosity before instruction.
What Is Possible
A child with only two Python classes can already move from:
numbers → experiments → conditions → lists → loops → algorithms.
Programming doesn't have to begin with a curriculum of syntax.
It can begin with a mystery.
How Does It Happen
Give the student something small enough to experiment with, but mysterious enough that the answer isn't obvious.
Then resist the temptation to explain.
Let the student poke the machine.
Let it fail.
Let the student discover.
And when the student finally asks for help, be there.
Why Does It Matter
The most valuable programming skill may not be knowing Python.
It may be developing the instinct:
“I don't know what this does yet. Let me try it.”
That instinct can travel far beyond programming.
The little detail I especially love
It began with Donald watching a kid think.
And it ended with the kid writing an algorithm.