Living Museum of Learning
Eight Lines That Wouldn't Let Go
Enning had written these eight lines only one or two days earlier:
let a = width;
let b = 8 * side;
let t = (a - b)/2
gridX = t
a = height;
b = 9 * side;
t = (a - b)/2
gridY = t
They were her own code.
Yet when we returned to them, they looked strangely familiar and unfamiliar at the same time.
We had originally started the session with something innocent: making the board margin a little smaller before taking a homework screenshot.
Enning changed side from 41 to 50. It worked. The whole board changed almost like magic.
She tried 48.
“I think this looks the best.”
The happy moment lasted a few seconds.
“Now try to modify the 2nd line to see what happens,” I said.
Then the nightmare began.
She modified gridX.
Nothing happened.
Now she had to find out why.
Where in the 83 lines of code was gridX actually being used? What did those eight lines have to do with the visible board? What was a? What was b? Why 8 * side? Why divide by 2? How had she arrived at all of this only a couple of days earlier?
At one point she said:
“Oops, I might have deleted let.”
She added let to the second half.
Everything broke.
LOL.
What looked like an extra hour became an unusually valuable hour of relearning.
Instead of moving dangerously forward with code she merely recognized, Enning had to investigate it.
Change something.
Run it.
Look carefully.
Change something else.
Break it.
Fix it.
Ask why.
The eight lines stopped being something she had once written and became something she had to understand again.
Beginners are too easy to fool themselves: “I got it.”
Recognizing code is not the same as understanding code.
An experienced learner develops a habit of suspicion:
Do I really understand this?
Then comes the test.
Don't assume anything. Test, verify, and double-check—with your human eyes, or with any tool under them.
The extra hour was not lost time.
It was the time needed to turn recognition into understanding.