Living Museum of Learning
The Middle Square Was an Average
Situation
Tianjing was making her Chinese Chess game understand how the Xiang moves.
At first, the logic seemed simple: the Xiang moves two squares diagonally.
But then came the important part—the blocking condition.
Tianjing started writing conditions such as:
if fromCol + 1 == toCol
Then she stopped and said:
“But there are many conditions like this.”
She was right.
There were many possible combinations if we tried to describe every situation separately.
Turning Point
I took her to the whiteboard.
I asked her to draw a number line.
We looked at the two ends of the Xiang's diagonal move and asked a much simpler question:
What is the coordinate exactly halfway between them?
Tianjing had to learn that the answer was not another special case.
It was the average:
(fromCol + toCol) / 2
and similarly for the row.
Suddenly, the “many conditions” became one condition:
else if pieceAt(
col: (fromCol + toCol) / 2,
row: (fromRow + toRow) / 2
) != nil {
canMove = false
}
The middle square had become mathematics.
Emergence
Her final canXiangMove() was surprisingly neat.
It first checks the four possible diagonal directions, then checks the river restriction, and finally checks whether the middle point is occupied.
No long list of special cases.
No guessing which square is in the middle.
Just a rule.
And then came another lesson.
Tianjing had also been working on dragging a chess piece with the finger. She had fixed all the known problems—until the piece mysteriously disappeared when the drag ended.
The code looked perfectly reasonable.
She reset:
fingerCol = -1000
fingerRow = -1000
and then called:
delegate?.movePiece(...)
The problem was the order.
By the time movePiece() was called, the original coordinates were already gone. The program was being asked to move a piece from (-1000, -1000)—where, unsurprisingly, there was no piece.
The fix was tiny.
But the idea was not tiny:
In programming, the order in which things happen is part of what the program means.
Learning
Tianjing is beginning to discover that programming is not mainly about writing more if statements.
Sometimes the right answer is to find the mathematical rule hiding underneath the cases.
Sometimes the code is almost completely correct, but one line happens a little too early.
A number line can lead to a clean algorithm.
And a misplaced line can make a chess piece disappear.
Theme
When the cases become too many, look for the rule.
When the code looks right, look at the order.
What Is Possible?
Can a child turn a geometry idea into a working chess rule?
How Does It Happen?
By drawing it, questioning the cases, finding the average, testing the code—and sometimes staring at a disappearing chess piece until the tiny mistake reveals itself.
Why Does It Matter?
Because programming is a way of learning to make our thinking precise.