The $1M Screenshot
For three consecutive days, Enning had scored exactly 25/30 on Khan Academy's Grade 4 and 5 Math Course Challenges.
This morning, August 25, Donald connected with her through Slack and noticed something encouraging: Enning was already six problems into the second round of the same Grade 5 challenge.
She had not given up after three identical scores.
Then she finally broke through:
25 → 25 → 25 → 28
She got 28/30.
But the score was not the most interesting thing that happened that morning.
During a Khan problem asking her to estimate 92 × 543, Donald heard Enning quietly murmur:
“take 8…”
Donald had heard those words before.
In an earlier addition problem, Enning had discovered a clever way to move 8 from one number to another:
92 + 10 = 100 + 2 = 102
That is perfectly legitimate. The total doesn't change when 8 is taken from one addend and given to the other.
But this time the problem was multiplication.
Donald immediately recognized the danger:
This is NOT addition. Alarm! Huge!
Later, Enning's own written work made the misconception visible:
92 × 10 = 920
100 × 2 = 200
92 + 10 = 102
100 + 2 = 102
She had apparently generalized the “move 8” idea from addition to multiplication.
The screenshot became the perfect artifact of the moment.
It was not merely evidence of a wrong answer.
It was evidence of how she was thinking.
And that made it worth $1M.
The mathematics mistake led Donald to an even bigger discovery.
The previous day, Donald had repeatedly told Enning:
Rebuild. Don't recopy. Don't do things by rote.
Enning had been working on her Gomoku iOS project and had produced quite gorgeous code.
But Donald discovered that she did not actually understand all of it.
So he created an extremely small test.
Not “finish Gomoku.”
Not “rewrite the whole program.”
Just:
Open a new Snake iOS project and draw a single line.
That should require only the basic drawing sequence:
create a pen → move the pen → add a line → stroke it.
She failed.
She couldn't remember that she needed a UIBezierPath, that the pen had to be created first, that move(to:) and addLine(to:) defined the line, and that stroke() was what actually rendered it.
The gorgeous Gomoku code had been there.
The understanding was not.
This was the same learning problem appearing in a different language.
In mathematics:
“Take 8” had become a memorized maneuver detached from the reason it worked.
In programming:
“pen → move → line → stroke” had become a memorized sequence detached from the underlying process.
The blank Snake project exposed the gap immediately.
Donald therefore changed the homework:
Same as yesterday, but in Snake iOS project. 😉
The challenge was no longer to reproduce yesterday's code.
It was to rebuild the idea in a new environment.
He also told Enning:
不急不躁,开动脑筋
Don't rush. Don't become anxious. Think.
Enning replied:
ok
Donald then made sure there was no practical obstacle hiding behind the learning problem.
He asked whether she had enough computer time for Xcode. The family has one powerful Mac shared by Enning, Tianjing, and their dad, and that particular Mac is important because it has the setup for their remote classes, including Slack and Xcode.
Tianjing would be doing something else over the following days, however, so she would not need the Mac except during class time.
Enning replied:
“ok I'll spend more time on the computer.”
Donald then opened the machine to a much wider learning world:
The older Mac should be able to install and run Python, P5JS, Khan, DMOJ, etc. Let me know if anything doesn't work as expected.
So the obstacle was removed.
The computer was available.
The software was available.
Questions were welcome.
Now the challenge was hers:
Can she rebuild rather than recopy?
And tomorrow morning's single-line Snake test would tell Donald much more than another polished rewrite of yesterday's Gomoku code.
This episode exposed a fundamental difference between looking like you know something and actually knowing it.
A student can spend hours reviewing and rewriting her own beautiful code.
She can recognize every line.
She can reproduce the whole program.
She can become increasingly fluent with the appearance of the solution.
Yet when the old code disappears and she faces a blank project, she may not be able to draw one single line.
Likewise, a student can discover a useful mathematical transformation and then apply it mechanically to a different operation where it no longer works.
The real learning test is therefore not:
Can you recognize or reproduce yesterday's answer?
It is:
Can you reconstruct the idea when the surface form changes?
For addition, moving 8 works because the total is preserved:
92 + 10 = 100 + 2
For multiplication, changing both factors does not preserve the product:
92 × 10 ≠ 100 × 2
The important lesson is not merely “don't make this mistake.”
It is:
Understand why a method works before carrying it into a new situation.
And that is exactly the lesson Donald is trying to establish in programming too.
The student should eventually be able to close yesterday's code, open a blank file, and think:
What am I trying to make happen? What tools do I need? What is the sequence of actions?
Then rebuild it.
Not recopy it.
A student stuck at 25/30 for three consecutive days can keep working, break through to 28/30, and begin to solve problems more independently.
By exposing the difference between recognition and reconstruction: listen for the student's actual thinking, capture misconceptions in her own handwriting, remove the old code, give her a blank environment, and ask her to rebuild something tiny from first principles.
Because education is not about producing beautiful answers that can be copied again tomorrow. It is about developing a mind that can reconstruct, generalize correctly, detect when a familiar trick no longer applies, and figure things out when the template disappears.