Last time, Eon and his dad built an automatic intro animation for Eon's channel — a little cat that jumps and moves across the screen. The code works. So when his dad asks how it feels, you might expect Eon to be proud. Instead he's honest: it's kind of boring.
That single word is what this whole lesson is about. A program can run perfectly and still be wrong — because "wrong" isn't only about errors. It's about whether the thing you built actually does the job you wanted.
"Boring" is a clue, not a complaint
His dad doesn't argue. He asks why it's boring, and together they figure it out: "The cat didn't speak, right?" It just jumps and moves, jumps and move — over and over, in total silence. A cat hopping around with no voice doesn't feel like a real welcome.
This is a great coding habit to copy. When something feels off but you can't say why yet, slow down and name the problem in plain words. "It's boring" turned into "the cat is silent," and a fuzzy feeling became a clear, fixable fact. You can't repair a problem you haven't pinned down.
What was the objective?
Then comes the line that gives the video its title:
"Remember, when we write a program, we always want to follow the objective. So, what did you set out to do?"
An objective is the goal you decide on before you start building. And Eon remembers exactly what theirs was: write the intro and outro automatically — an intro that says "Hello everybody, welcome to the channel!" and an outro that says "I'll see you next time."
Read that goal again and look at what they actually built. The objective was a friendly greeting and goodbye. What's on screen is a cat doing silent gymnastics. Measured against the real goal — not against "did the code run?" — the intro isn't finished. It's missing the most important part: the talking.
That's why the objective is like a compass. Code can point you in lots of directions, and "it works!" can fool you into stopping too early. The objective keeps pointing at true north: this is what we actually set out to make. Whenever something feels off, you hold your work up next to the goal and ask, "Does this match?" If it doesn't, the mismatch shows you precisely what to fix.
The gap points to the next step
Here's the best part: once Eon and his dad name the gap, they instantly know what to do. The cat can't welcome anyone because it can't speak — so the intro needs sound. Their plan for the next video falls right out of the objective: record the audio — record themselves actually saying the welcome and the goodbye — so the cat finally has a voice.
Notice how no one had to guess. They didn't randomly add more jumping or new colors. They compared "what we have" to "what we set out to do," found the one thing missing, and that became the whole next step. A clear objective doesn't just tell you when you're done — it tells you what to build next.
Try it
Pick something you want to make — a drawing, a LEGO build, a tiny game, or a real program. Before you start, write your objective in one short sentence: "I'm making ___ so that ___."
Then build a first version. When you think you're finished, don't ask "did it work?" — ask Eon's question instead: "Does this match my objective?" Read your sentence again and hunt for the gap, the way Eon found the silent cat. Whatever's missing is your next move. If you get stuck partway through, that one sentence is almost always the thing that tells you what to do next.