Living Museum of Learning
先混个脸熟 — Let Her Meet Abstraction Again
Situation
A few days ago, Tianjing and I refactored her chess project together.
She had a large amount of repetitive code, and I guided her toward a much more professional structure: instead of writing separate code for every chess piece, we could let the data describe the pieces and let one piece of code serve them all.
She became fluent with many other parts of programming.
But I noticed something important:
This particular idea had not become hers yet.
She had seen the face of abstraction.
She just hadn't become familiar enough with it.
So today, in a different Chinese chess project, I decided to give her some room.
Turning Point
At the beginning, Tianjing had only two if blocks handling the chess pieces.
There were fourteen kinds of Chinese chess pieces.
She was getting lost already.
I could have stopped her and immediately rebuilt the professional solution.
Instead, I asked her to remove the other pieces from the pieces array.
Leave only one.
“Forget about the 2nd piece in the pieces box, and the 3rd one. Serve this first and only one first. It can be any piece anywhere.”
One piece.
Anywhere.
First make that one work.
She was getting closer and closer to the “I got it” moment, but not quite there.
So I gave her another little nudge:
“Your 2 if blocks handle just 2 pieces. There are another 12.”
And then the long journey began.
Emergence
Tianjing started building the remaining twelve cases.
Copy.
Paste.
Modify.
Copy.
Paste.
Modify.
Fourteen huge if / else if blocks.
And that was only the beginning.
The entire fourteen-piece structure was then being repeated for pieces[0], pieces[1], pieces[2]...
Potentially all the way to pieces[31].
😂
This was no longer ordinary duplication.
It was becoming a monster of duplication.
And I let her continue.
A few days earlier, I had already shown her what professional abstraction could do.
Today, I didn't want to rescue her from the problem before she had experienced the problem.
Sometimes refactoring too much, too quickly, slows understanding down.
The Crash
Then came another small experiment.
We removed the third piece from the pieces array.
Tianjing's code still tried to access that piece.
And the program crashed:
Index Out of Bounds.
This time, she understood why.
There was no third piece in the container anymore.
The code was asking for something that wasn't there.
Then she asked the important question:
“But what can we do then?”
She wasn't sure.
Perfect.
That was a good place to stop.
The Door Left Open
I didn't answer.
Instead, before we disconnected, I said:
“Think about that. Then take a look at your chess code. You'll get your Ah Ha moment.”
Because she has already seen the answer.
A few days ago.
In another project.
With another set of pieces.
She just hasn't connected the two experiences yet.
Learning
This is the second time Tianjing will face essentially the same architectural problem.
The first time, Donald helped her refactor it.
The second time, she will have much less help.
And this time the scale is almost absurd:
nearly 100:1.
A giant pile of duplicated code may eventually collapse into a small amount of general code.
But the important transformation isn't the code.
It's the transformation in her head.
The first encounter says:
“Here is another way to write this.”
The second encounter asks:
“Why am I writing the same thing again?”
That question is much more valuable.
先混个脸熟
I often tell my students:
先混个脸熟。
Don't worry if you don't fully understand something the first time.
Just get familiar with its face.
You may meet it again.
And again.
In geometry, a forgotten idea such as perpendicularity can come back through a completely different problem.
In programming, an abstraction can first appear as something Donald insists is “professional code.”
Then, several days later, the learner can find herself buried under fourteen copies of the same thing.
And suddenly that old face may look familiar.
“Wait... I've seen this before.”
That is the Ah Ha moment.
Not because Donald explained it better the second time.
Because Tianjing has finally encountered the problem that makes the solution necessary.
Theme
Sometimes the best time to teach refactoring is after the learner has created something worth refactoring.
And sometimes the teacher's job is not to stop the duplication.
It is to let the learner discover why duplication hurts.