Launch CS in five class periods - without a dedicated lab install day

The first five periods are the whole game

Every CS teacher knows the pattern: you plan a clean introductory unit, then spend three periods troubleshooting why fourteen students can't get Python installed on a school-managed Windows machine. By the time the environment works, the students who were excited have moved on mentally, and the ones who were nervous have decided the course isn't for them.

The fix is not better installation instructions. The fix is removing the installation step entirely from the first week.

Here is a five-period sequence that gets every student writing and running code on day one, regardless of what machine they have or what the district IT policy looks like.

Period 1: Accounts and first output

Goal: Every student has a working account and has seen "Hello" appear on screen.

Start with a browser-based environment - no downloads, no extensions, no package managers. Breya's student dashboard, CodePen, or Replit all work. The only prerequisite is a Google or school email.

Your first code challenge: print your name. That's it.

<!DOCTYPE html>
<html>
<body>
  <h1>Hello. My name is Alex.</h1>
</body>
</html>

Yes, it's HTML. Yes, it's trivial. But every student sees a result, and the result is theirs. Confidence is built on small wins stacked early.

End the period with a norm you will enforce all semester: "Error messages are information, not failure." Read one aloud together. Show that it tells you exactly what went wrong and on which line.

Period 2: Variables and decisions

Now that students have seen output, introduce the first real programming concept: storing a value and making a decision based on it.

Keep the context grounded. Instead of abstract examples, frame everything around a product or a person. "A store charges $5 per item. If you buy more than 10, you get a discount. Write the code."

By the end of period two, students should be able to: - Declare a variable and assign a value - Write a simple if/else - See different outputs based on different inputs

The key pacing note: do not introduce loops here. Students need to feel comfortable with sequential logic before adding iteration. Rushing to loops is one of the most common causes of early confusion.

Period 3: Paired debugging

This period is the most important one.

Pair students randomly. Give them a program that has three bugs. Their job is not to fix it - their job is to describe each bug in a sentence before touching the code.

"Line 7 uses = instead of ==." "The variable name on line 12 doesn't match the one declared on line 4." "The condition is backwards - it prints 'too cold' when the temperature is 40 degrees."

This period does three things at once: 1. It teaches students to read code before editing it 2. It normalises making errors in front of a partner 3. It shows that debugging is a methodical skill, not intuition

Rotate pairs on the next activity. The social cost of being wrong in front of a new partner is lower, and students internalise that bugs are universal.

Period 4: A real product decision

Introduce a constraint-based challenge. Something like: "Build a price calculator for a school canteen. Items cost between $1 and $8. If a student buys three or more items, they get the cheapest one free."

This is not a tutorial to follow step by step. Give them 25 minutes to work in pairs and figure it out using what they have already learned.

The teacher's job in this period is to resist answering direct questions. Instead, respond with: "What does the error message say?" and "What did you expect to happen on that line?"

You will be amazed how often students solve their own problems within 90 seconds of being asked those two questions.

Period 5: Debrief and toolchain intro

Only now, after students have built something and debugged something and explained something, do you introduce the idea of a local development environment.

Show them what an IDE looks like. Show them that it has the same features - syntax highlighting, error messages, output - but runs locally. Frame it as an upgrade they have already earned, not a requirement they have to survive.

Schedule the install day as a structured activity, not a class takeover. Run it with a checklist, a helper student per table, and a clear endpoint: "By the end of today, type 'Hello from my laptop' and run it."

What you are actually doing in these five periods

You are separating the concept learning from the environment setup. Students learn to think before they have to manage a toolchain. When the toolchain comes, they are not simultaneously trying to understand what a variable is.

The result: by the end of week two, your class has a shared vocabulary, shared debugging habits, and enough confidence to handle a real environment without it feeling like a barrier.

The install day becomes a milestone instead of an obstacle.