Living Museum of Learning
When the Code Became His
Situation
Ethan has been building a p5.js soccer court for his 2026 World Cup project.
The project has gradually accumulated real pieces of a soccer world: the court, a goal, and a soccer ball.
But the ball is not an ordinary sphere.
It grew out of an icosahedron—the most calculated project Ethan has built so far. The geometry led to the structure of a soccer ball, and Ethan became the first of the kids to finish that soccer ball.
Now the goal was ready too, including its net.
Today's class was about bringing those pieces together.
Ethan moved the goal code into the court codebase. He used the same global scale that the court used, because naturally the goal belonged to that environment.
Then Donald asked a seemingly small question:
“Is it better to give the user of the soccer goal freedom to set its own size?”
Ethan immediately agreed and turned scale into a parameter.
But that was only the beginning.
Turning Point
Donald and Ethan carefully examined the global constants.
One constant was genuinely needed in several places.
Then Ethan discovered that five others were actually local variables left behind after an earlier refactoring.
They removed them.
The code became cleaner without changing what the program did.
Then came the question of location.
Ethan created a drawXYZ idea for establishing local origins, much like Donald had previously done with Enning's 3D bike project. He understood that different parts of the goal could be drawn relative to their own local origins.
The goal was working.
Then Donald looked at the three lines used to establish a location for a goal and had another thought:
push().
Draw the goal in its local coordinate system.
pop().
The transformation would stay inside its own little world.
Since the project only needed one goal, Donald suggested another refinement: rename the existing construction function drawGoal to drawLocalGoal, then create a higher-level drawGoal responsible for positioning the goal and calling the local construction.
The distinction was subtle:
drawGoal() decides where the goal belongs.
drawLocalGoal() knows what a goal is.
The code was becoming architecture, not just geometry.
Ethan's 2026 World Cup court:
Emergence
Then Ethan moved his soccer-ball code into the court codebase as well.
Donald looked at the result:
“This is our most calculated project so far, coming from the icosahedron.”
And something unexpected happened.
Ethan looked at the code and said:
“Uncle, let me add all the missing ;s.”
He was the code owner.
Donald hadn't asked him to do it.
Ethan simply wanted his code cleaned up.
Then he went further.
He added the missing spaces so that single-digit numbers lined up with two-digit numbers in the same columns.
Suddenly the code had a different feeling.
It looked almost textbook-quality.
And throughout the process, whenever Donald caught one of those little things—perhaps a hard-coded number where a parameter belonged, or an editing operation that could be done more cleanly—Ethan had his characteristic response:
“What the heck am I doing here?” 😂
Always accompanied by laughter.
He would immediately fix it.
At another point, while changing a name, Donald showed him that the comma and following space could be included with the word as one unit, so the whole replacement could happen in a single paste.
Ethan understood.
And laughed again.
The tiny improvements kept accumulating.
Finally, the soccer ball and the complete soccer goal were no longer separate experiments.
They were becoming parts of one project.
Ethan's 2026 World Cup soccer world.
Learning
The deepest learning in this class wasn't about soccer.
It was about ownership.
Ethan learned that good code is not merely code that runs.
It can also be:
carefully scoped;
independent of unnecessary global state;
configurable through parameters;
organized around local coordinate systems;
protected by push() and pop();
divided into meaningful layers of abstraction;
minimally changed during refactoring;
formatted so its structure is visible;
and clean enough that its author wants to polish it.
None of these arrived as a lecture.
They emerged because Ethan was working on something he cared about.
The most revealing moment may therefore have been neither the icosahedron nor the soccer ball.
It was:
“Uncle, let me add all the missing ;s.”
At that moment, Ethan wasn't asking Donald to improve his code.
He was improving his own code.
That is a different relationship with programming.
The project had started as something Ethan was building.
Now it was becoming something Ethan owned.