Living Museum of Learning
Tianjing Stops Talking About Programming and Starts Thinking
Situation
Tianjing is only six weeks into programming, starting from absolute nothing.
Just days ago, moving between Python, p5.js, and Swift could still be confusing. Curly braces sometimes seemed to belong to another universe, especially the mysterious closing }. Today, however, she was working inside a real Swift Chinese-chess project with a long sequence of conditional branches.
The first half of the class was Python.
We were writing a program to determine whether a number is prime. I deliberately chose the small, friendly number 37.
“Imagine we want to check if this number is prime. What do we do?”
“I knew it from memory.”
“Imagine we don't know it's a prime. What do you do?”
“I knew it from memory. I don't know what I will do.”
The problem was not Python. Her brain already knew the answer, so it resisted pretending not to know.
I changed the number to 331.
Suddenly:
“Ah... I can do 37...”
And the algorithm began.
37 % 2
37 % 3
37 % 4
...
Then Tianjing noticed something.
She could stop checking every integer. She began looking at the relevant divisors instead:
37 % 2
37 % 3
37 % 5 != 0
37 % 7 != 0
37 % 11 != 0
37 % 13 != 0
37 % 17 != 0
37 % 19 != 0
She couldn't initially explain why she felt she could stop around halfway. I deliberately didn't give her the answer.
Instead, we tested the feeling.
She changed the loop from r to r // 2, then worried about integer division and added + 1. We tested it with 33333331, the largest prime number she had ever encountered.
There was still a noticeable delay.
Good.
The computer had just made the invisible cost of the algorithm visible.
Before leaving this part, I gave her a question to carry with her:
Can we stop even earlier?
At the first step?
The second?
The third?
When?
Turning Point
Then we moved back to Swift.
The code contained many branches like:
if p.color == 0 && p.rank == 0 {
bJiang?.draw(in: ...)
} else if p.color == 0 && p.rank == 1 {
bChe?.draw(in: ...)
} else if p.color == 0 && p.rank == 2 {
...
}
Tianjing immediately offered:
“It can be improved by using a for loop.”
I stopped her.
“No. It has nothing to do with a for loop. We are handling this if block, these conditions, these branches. Focus on the problem itself.”
She had recognized familiar programming vocabulary, but she hadn't yet identified the actual structure.
So we slowed down.
I asked her to introduce:
let a = bJiang
and then use:
a?.draw(in: ...)
inside the branch.
The point was tiny but important.
What changes?
The image object changes.
What stays the same?
The drawing operation.
She separated those two things.
Then I asked:
“What is the connection between these two if lines?”
Her language hesitated.
I nudged her.
“They are the same piece (rank) with different colors.”
Exactly.
“Could you group the pairs together? Write new code without touching the existing code.”
And suddenly we arrived at something familiar: the five-line if ... else structure.
Then we reviewed the ternary expression.
I asked her to rewrite the single-line ternary several times until she memorized it.
The second attempt missed the p. in p.color.
So she did it again.
The third time, she got it.
Emergence
Then something happened that I almost missed.
Tianjing began deleting the old if blocks.
“No, don't touch it. Write the new code,” I said.
I hadn't understood what she was doing.
She added one new ternary line.
Then she carefully removed the two old branches that the new line replaced.
She highlighted the exact two blocks. Not a tiny mistake. Nothing else was disturbed.
“I am changing code this way ...”
I suddenly understood.
“Oh! That's actually a great way!”
She had independently adopted a safe refactoring process:
write the new code → verify it → remove the old code it replaces.
For a beginner, it was an unexpectedly professional gesture.
And she didn't break a single curly brace.
Just days earlier, Python, p5.js, and Swift could still feel like separate worlds, and even remembering where a closing } belonged could be difficult.
Today, the braces were no longer the problem.
Her attention had moved upward.
She was thinking about the structure of the program.
Learning
This class contained two apparently unrelated problems.
In Python:
Can the computer do less work?
In Swift:
Can I write less repeated code?
But underneath, they were the same lesson.
Don't reach for a programming word because you recognize it.
Look at the problem.
Find what changes.
Find what stays the same.
Then change the code.
Tianjing is only six weeks into programming, but today she experienced several ideas that cannot be learned merely by memorizing syntax.
She learned that a vague feeling about an algorithm can be tested.
She learned that special cases are only special when the normal case cannot handle them.
She learned quit() because the logic demanded an early exit.
She learned that two branches can represent the same rank with different colors.
She learned to separate the changing object from the operation that stays constant.
And she learned that code can be refactored safely, one small verified step at a time.
At the end, I reminded her:
“This is our second round refactoring this kind of thing. The first round was on our chess project. If we meet another similar project in the future, can you handle it?”
Her answer was wonderfully Tianjing:
“应该可以吧。”
“Should be able to, I guess.”
Maybe that's exactly the right answer.
She doesn't need to know everything yet.
She needs to recognize the next problem when it arrives—and know that she has learned how to think her way through it.
Theme
Learning = playful creation
A six-week beginner doesn't need more programming vocabulary.
She needs opportunities to discover what the vocabulary is actually for.
What Is Possible
A beginner starting from absolute zero can begin developing professional programming habits surprisingly early.
How Does It Happen
By refusing to accept borrowed words as understanding, slowing down to inspect the actual structure of the problem, and letting the learner discover the pattern.
Why Does It Matter
Because programming eventually becomes less about remembering syntax and more about seeing structure, reducing unnecessary work, and changing complex systems safely.