HAP sitting at a laptop, eager to start coding but looking thoughtful

Station 1: Thinking Logically

Why clear thinking comes before code

Welcome to Station 1! I was so excited to start coding. I opened my editor, fingers ready on the keyboard, and then... I froze. I had no idea what to type first.

I kept asking myself, "How do I know what code to write if I haven't decided what should happen?"

Prof. Teeters smiled when I told her this. "Before you write a single line of code," she said, "you need to know what should happen. If you can't explain the behavior, the computer certainly can't guess it."

That's when it clicked for me. Being a developer isn't about typing code—it's about thinking clearly first.

Let me show you what I learned about describing behavior before writing a single line of code... 🟠

What You'll Learn at This Station

HAP's Discovery: I used to think coding was about typing fast. Prof. Teeters taught me that the real skill is thinking clearly about what should happen—before you write anything. Here are the three insights that changed how I approach every project.

🧠 Behavior First

Think → Then Type

Before writing code, describe what should happen in plain language. The computer needs you to be specific.

💬 No Syntax Needed

Plain Words Work

You don't need special keywords or symbols to describe logic. Regular sentences can capture exactly what a program should do.

🎯 Clarity Prevents Bugs

Vague = Broken

When your thinking is unclear, your code will be too. Clear behavior descriptions prevent confusing errors later.

HAP surrounded by tangled code with an 'oops' expression

HAP's Confession:

  • I jumped straight into code without deciding what the program should do—and spent an hour writing logic that never made sense in the first place.
  • I assumed the computer would "figure it out" if my idea was vague. Spoiler: it didn't. I got errors that made no sense because my thinking was unclear. 😳
  • I mixed up what I wanted to happen with how it would happen—and ended up solving the wrong problem entirely.

What Does "Behavior" Mean?

When Prof. Teeters talks about "behavior," she means describing what should happen—not how to make it happen. This was a big shift for me. I kept wanting to jump into the details, but she taught me to stay focused on the actions and outcomes first.

What Happens

Describe the actions: "The game picks a number" or "The player makes a guess." Focus on events, not mechanics.

In What Order

Things happen in sequence. First this, then that. The order matters because each step might depend on what came before.

Under What Conditions

Some things only happen if something else is true. "If the guess is correct, the player wins." Conditions control the path.

What Changes

Something usually changes along the way—a counter goes up, a message appears, the game ends. Track what's different after each step.

🟠 HAP's Insight:

Prof. Teeters told me: "If you can explain the behavior to a friend who's never coded, you're ready to start coding. If you can't, you're not." I keep that in my head every time I start something new.

The Secret Number Game

Throughout this Learning Lab, we'll use a simple game to practice our thinking. It's called the Secret Number Game, and here's how I would describe its behavior in plain language:

The Secret Number Game — Behavior Description:

  • The game chooses a secret number
  • The player makes a guess
  • The game checks the guess
  • The game gives feedback
  • The player may guess again
  • The game eventually ends

Notice what's not in that description: no mention of JavaScript, no code syntax, no details about how the computer generates a random number. That's intentional. At this stage, we only care about what happens, not how to make it happen.

HAP giving a confident thumbs up

🟠 Why This Matters:

This same game will follow us through every station in this lab. We'll represent it in different ways—diagrams, pseudocode, even real code—but the behavior stays the same. That's the power of thinking clearly first: once you know what should happen, you can express it in any format.

Vague vs. Clear Descriptions

I learned the hard way that vague descriptions create problems. Here's what Prof. Teeters showed me about the difference between unclear and clear behavior descriptions:

❌ Vague: "The game works"

Works how? What does "working" look like? This doesn't tell me anything about what actually happens.

✅ Clear: "The game checks if the guess matches the secret number"

Now I know exactly what action occurs. There's a comparison happening between two things.

❌ Vague: "The player tries to win"

What does trying look like? What counts as winning? Too many unanswered questions.

✅ Clear: "The player enters a number. If it matches the secret number, the player wins."

Now I know the specific action (entering a number) and the specific condition for winning (matching).

🟠 The Test I Use:

When I write a behavior description, I ask myself: "Does this raise more questions than it answers?" If yes, it's too vague. A good description should make the next step obvious, not confusing.

🎓 Thinking Logically Quick Reference

1

Behavior Before Code

Always describe what should happen before you write any code. If you can't explain it in plain language, you're not ready to code it.

2

Plain Language Works

You don't need special syntax or keywords. Regular sentences like "The game picks a number" are perfect for describing behavior.

3

Be Specific, Not Vague

Vague descriptions create bugs. Instead of "the game works," say exactly what happens: "the game compares the guess to the secret number."

4

Ask: What, When, If

Good behavior descriptions answer: What happens? In what order? Under what conditions? What changes as a result?