Living Museum of Learning
Let the King Get More Motion
It was Tianjing’s first day of Grade 9.
At school, almost everything was new: more than ten girls in her class, almost all strangers, and English she could barely follow. She came home, however, with her confidence intact.
After Enning’s first hour of class, Tianjing had her own two-hour session with Donald.
The goal was simple: make the chess pieces in her Swift app draggable—and have them snap precisely into the cell where the finger or mouse was released.
It turned out not to be simple at all.
Donald asked:
“Do you have a rough algorithm how to find which cell to snap in?”
Tianjing said, “Not really.”
Going to the whiteboard, she opened AutoDraw and sketched four squares.
That was enough.
She used concrete numbers:
gridX = 3
side = 11
finger.x = 30 or 44
For 44, she reasoned:
44 - 11 × 2 - 3 = 19
Too large for the second cell.
Then:
44 - 11 × 3 - 3 = 8
That fits.
Cell 3.
The algorithm had essentially appeared.
Everything else was code.
Then came another revealing moment.
Tianjing was trying to express the range of x, and her Swift looked messy:
x == gridX + side > ...
At first, Donald thought her thinking might be unclear.
Then he realized:
She already knew exactly what she wanted to say.
She was trying to express:
x is somewhere from gridX to gridX + side.
The mathematics was already there. She simply didn't know the Swift syntax yet.
So Donald helped her translate her own thought:
// x: from gridX to gridX + side
// x >= gridX && x <= gridX + side
The difference was profound.
The problem wasn't her thinking.
The problem was expressing her thinking in a programming language.
The King
Near the end of the long class, while waiting for her Apple account to cooperate so the app could be loaded onto a device, they kept testing pieces in Xcode.
Donald suggested:
“Let's try a white piece.”
He didn't want her to keep testing the easiest cells in the top-left corner.
Tianjing immediately chose:
“Which white piece? King! Let him walk more.”
Donald burst out laughing.
It was very Tianjing.
She had once famously questioned the design of chess itself:
“If queen is the most powerful piece, since king is the most useless one, why not let queen come up?”
Now the slow-moving king was being ordered onto the board to get some motion.
The Bug
She tried to pick up the king.
Nothing.
She tried several cells around the king.
Still nothing.
So they went back to the code.
And then they discovered the problem:
She had actually picked up the bishop.
Tianjing looked surprised:
“I think I tried that???”
She genuinely believed she had tested the bishop beside the king.
But she hadn't.
It was a tiny example of a big programming habit:
We can remember what we intended to test instead of what we actually tested.
The program doesn't care what we think we did.
So they tested again.
Tianjing learned several things in one afternoon:
A visual sketch can reveal an algorithm.
Concrete numbers can make an abstract problem easy to see.
A programming language's syntax is not the same thing as the underlying idea.
Coordinates can be converted into grid cells and back again.
A piece can follow the finger and then snap exactly into place.
When debugging, check what actually happened rather than trusting your memory of what you tried.
But perhaps the most important lesson was invisible in the code.
Messy code does not necessarily mean messy thinking.
Sometimes a student already understands the idea and simply hasn't learned how to express it yet.
A beginner can discover an algorithm without knowing its final syntax.
Draw it. Make it concrete. Test it. Translate the idea into code. Then test the code against reality.
Because programming is not primarily about remembering syntax. It is about learning to turn your own ideas into something a machine can execute—and learning to notice when reality disagrees with your assumptions.