What You'll Learn at This Station
HAP's Discovery: I thought I was just fixing a game. But the way I approached the problem—breaking it apart, noticing patterns, focusing on what mattered, describing steps clearly—turns out there is a name for that. And understanding that name helps me see why this kind of thinking matters.
Logic Is Not Enough
Correctness Is Just the Start
Logic helps you decide whether an idea is correct or incorrect. It tells you when something makes sense. But correctness alone does not tell you how to approach a problem, how to break it apart, or how to explain your thinking to someone else.
As problems grow more involved, relying only on logic makes it harder to move forward with confidence. Developers need more than correct answers. They need ways of thinking that help them decide what to focus on, what to ignore, and how to move step by step toward a solution.
We Already Did This
Experience Before Names
You practiced it with me in the earlier stations when we:
- broke the game into parts
- noticed repeated behavior
- focused only on what affected the outcome
- described steps clearly enough to follow again
Only now do we give this way of thinking a name. Naming it does not change the work you did. It helps you recognize it, remember it, and apply it again when you face a new problem.
Shared Language Helps
Names Create Recognition
Experienced developers naturally break problems down, look for patterns, zero-in on a problem, and immediately work in steps without thinking about their process.
For new developers, this workflow does not happen automatically. It is a skill that grows through repeated use. Naming ways of thinking builds the mental habits that make patterns easier to spot over time.
This is why naming ways of thinking matters. It helps good ideas travel—and it helps you build the mental muscle to recognize when to use them.
HAP's Confession:
- I thought that once my logic was correct, I was done learning how to think. I was wrong.
- When Grace mentioned "computational thinking," I worried it was something complicated I had not done yet. But she explained I had been doing it all along.
- I used to think developers just "knew" how to solve problems. Now I understand they have practiced a specific way of approaching them.
Wanting to Build More
After fixing my Secret Number Game, I felt accomplished. The game worked! The loop was correct. Players could guess until they won. But satisfaction quickly turned into curiosity.
The Secret Number Game taught me so much—how to describe behavior, write it down, trace it step by step, and fix what was broken. But now that it was complete, I found myself wanting more.
I told Grace: "This game is nice, but it is so simple. I want to build something bigger. Something like the games on my roboPhone—with levels, and characters, and things happening all at once."
Grace nodded. "You have ambition. That is good. But tell me—do you think the same kind of thinking that fixed your guessing game will work for a game with hundreds of rules and thousands of possible states?"
I had not thought about that. My game had one secret number, one guess, one loop. What happens when there are many things to track at the same time?
Logic Has Limits
Grace explained something that changed how I think about problem-solving.
What Grace Told Me:
"Logic helps you decide whether something makes sense. If this, then that. True or false. Correct or incorrect."
"But logic by itself will not carry you very far. Logic does not tell you how to break a big problem into small pieces. It does not tell you which details matter and which to ignore. It does not help you recognize that this problem is similar to one you solved before."
"There is a different kind of thinking you will need. It has a name: computational thinking."
She did not explain what it was. She just named it and sent me to Prof. Teeters to understand why it mattered.
The Four Pillars of Computational Thinking
I found Prof. Teeters and asked her: "Grace said I need something called computational thinking. What is it? And why does it matter?"
Prof. Teeters explained we can describe this kind of problem-solving using four pillars.
Decomposition
Breaking a problem into smaller parts so each piece can be understood and worked on. I did this when I looked at the game piece by piece instead of all at once.
Pattern Recognition
Identifying repeated behavior so solutions do not need to be reinvented. I did this when I noticed the guess-and-check was repeating and could be a loop.
Abstraction
Focusing on what matters and setting aside details that do not affect the outcome. I did this when I traced only the relevant parts to find the flaw.
Algorithmic Thinking
Describing steps clearly so a solution can be followed again and again. I did this when I wrote pseudocode that anyone could trace through.
🟠 The Moment It Clicked:
I recognized every single one of these. I was not learning something new—I was learning the names for things I had already practiced.
Prof. Teeters nodded. "You were not just fixing a game. You were practicing how developers think."
Why This Thinking Matters
Prof. Teeters explained that computational thinking is not just about solving one problem. It is about solving problems in a way that scales—that works even when things get complicated.
Solutions Can Be Automated
When you describe steps clearly enough, a computer can carry them out. That is how programs work.
Solutions Can Be Reused
When you recognize patterns, you can apply solutions to similar problems without starting over.
Solutions Can Be Tested
When you break things into parts, you can test each part separately to find where problems hide.
The difference:
Logic answers: "Is this correct?"
Computational thinking answers: "How do I approach this so I can figure out what to do?"
What I Now Understand
I sat with this for a while. My game is simple—just one loop, one check, one secret number. But the way I approached fixing it is the same way developers approach much bigger problems.
I know my game is super simple and not the real world. If I want to build things that work beyond this game, I cannot just think logically. I need a way of thinking and communicating that stays effective even as what I am building becomes more complex.
The Four Pillars are not rules to memorize. They are names for behaviors that become natural with practice. And now that I know the names, I can recognize when I am using them—and when I am not.
🟠 What Changed for Me:
Before this station, I thought I was just "trying stuff" until things worked. Now I see that I was following an approach—an approach that professionals use every day.
Understanding this does not make me an expert. But it helps me recognize what I am doing and why it works.
One More Thing I Noticed
As I reflected on everything I had learned, something else occurred to me.
Right now, all of this understanding exists only in my head. I know how the game works. I know why the loop failed. I know how I fixed it. But if I step away for a while—or if someone else looks at my code—will they understand what I was thinking?
The reasoning behind my decisions is not written down anywhere. If I forget, or if I need to explain it to someone else, I would have to figure it all out again.
That seems like a problem. Especially if I want to build bigger things with other people.
Prof. Teeters noticed me thinking about this. "You are right to wonder," she said. "Developers do not just solve problems—they record their reasoning so it can be understood later. That is what we will look at next."
🎓 Computational Thinking Quick Reference
Decomposition
Break big problems into smaller, manageable pieces. Do not try to understand everything at once—focus on one part at a time.
Pattern Recognition
Look for repeated behavior or similarities. When you recognize patterns, you can reuse solutions instead of reinventing them.
Abstraction
Focus on what matters and ignore what does not. Not every detail is relevant to solving the problem at hand.
Algorithmic Thinking
Describe steps clearly and precisely. If someone else (or a computer) can follow your instructions, you have thought algorithmically.