Living Museum of Learning
When Code Became a 3D Bike
Situation
What started as an independent p5.js project has grown into something much bigger.
Enning has been building a 3D bicycle piece by piece. Today, one particularly satisfying piece was finished: the bike seat.
She built the seat independently as a reusable function:
function drawSeat(s) {
...
}
It isn't just a drawing anymore. drawSeat(s) is a tool she can call from her larger 3D bike project, even with different values of s to create different-sized seats.
And then came the moment we had been waiting for.
We uncommented:
angle = angle + 1
The wheels started spinning.
We happily shot a video.
Our gorgeous 3D bike was alive. 😄
Turning Point
Wait.
Where were the two red axes of the wheels?
Enning looked at another computer.
“Oh, it's on another computer.”
But if the project was saved, we should be able to see it anywhere.
She opened another bike project.
“Here we are.”
Apparently, there were two bike projects. Maybe one was simply a copy of the other.
The seat code was already getting long. Rather than copying a large amount of code, we looked for the small function that had already been created for the red axes:
function drawRedAxes() {
drawRedAxis(-100)
drawRedAxis(100)
}
So surely we could simply call:
drawRedAxes()
But Enning had copied the two lines inside the function instead.
Another hole in the programming model had just been located. 😂
At first, “wrap two small tools in a big tool” wasn't quite enough to make the idea click.
Then came a more concrete explanation:
“When this function is called, the execution jumps into it. Your two numbers are here.”
And suddenly she got it.
The function wasn't something she had to open up and copy.
Call it, and execution jumps inside.
The two little tools run.
Then execution comes back.
The same idea connected beautifully with her drawSeat(s) function: a large amount of geometry can be wrapped into one reusable tool.
Emergence
By the end of the class, Enning had practiced parameter passing again and again.
She experimented with s.
She learned that the caller can provide different arguments.
She drew two seats with different sizes.
She discovered that a function can hide a whole collection of smaller operations.
She also discovered that a bug can remain unfinished and naturally become homework. 😄
And finally, she reshot the bike video—with the two red axes this time.
The result is not a classroom exercise.
It is a piece of 3D art.
A translucent green bicycle.
A custom-built seat.
Two spinning wheels.
Two red axes revealing the geometry of the wheels.
And behind the beautiful picture: functions, parameters, coordinates, transformations, abstraction, debugging, and a beginner gradually building a mental model of how her own code actually runs.
Learning
Sometimes the most important programming discoveries arrive disguised as tiny moments of confusion.
Why does drawRedAxes() have no parameter?
Why aren't the two numbers passed from the caller?
Why can't I just copy the two lines?
Where did my red axes go?
These questions forced Enning to move beyond seeing functions as pieces of code on the screen.
She began to see them as actions that can be called.
And she began to see parameters as information passed into those actions.
The most beautiful part is that the learning happened inside something she genuinely wanted to make.
She wasn't learning functions so that she could pass a test.
She needed functions because she wanted her bicycle to work.
Theme
When code becomes a tool, and the tool becomes art.
What Is Possible
A beginner can build a surprisingly sophisticated 3D object from explicit geometry, functions, parameters, and a lot of curiosity.
How Does It Happen
By making something real, finding the holes in understanding when they matter, and fixing one piece at a time.
Why Does It Matter
Because programming becomes much more powerful when the learner stops thinking only about lines of code and starts thinking about reusable ideas.
And sometimes, after all that thinking, you get to press Record and watch the wheels spin. 🚲