Lesson 1 of 0

In Progress

Unit 2 – Teachers Guide

Unit 2 · Teacher's Guide | Knowledge Pillars · Code Quest

👋 Welcome — How to Use This Guide

This Teacher's Guide is your day-to-day companion for delivering Unit 2 of the Code Quest curriculum. It picks up where the Unit 1 guide left off and assumes students completed Unit 1 (variables, data types, operators, if/else). It's designed for new and experienced CS teachers alike — no programming background required to use it effectively. Every lesson plan stands on its own; if a substitute teacher takes over for a day, they should be able to pick up the next lesson and run it.

What this guide contains

A pacing guide showing how Unit 2 maps to roughly 7–9 class periods, including a longer Lesson 4 (50 min) and a 2-day capstone.
A standards & exam crosswalk showing exactly which Florida CTE standards and Coding Fundamentals exam objectives each lesson addresses. Unit 2 is the home of standard 07.03 (loops).
A unit vocabulary glossary with all 16 key terms students will encounter in Unit 2 — most of them brand new.
Five detailed lesson plans (one per lesson), each using the same 7-section format you saw in Unit 1.
An appendix with the most common Python error messages students will see in Unit 2 — plus the unique class of bug Unit 2 introduces: infinite loops (which produce no error at all).

How each lesson plan is structured

Every lesson plan in this guide uses the same 7-section format so you can find what you need quickly:

At-a-Glance — objective, time, materials, vocabulary, and a quick-reference standards box
Lesson Flow — a suggested 45-minute breakdown: warm-up, instruction, guided practice, lab, exit ticket
Watch For — the 2–4 most common student misconceptions, with how to address each in real time
Differentiation — what to do for early finishers and what to do for struggling students
Discussion Prompts — questions to spark whole-class conversation
Real-World Connections — how to answer the inevitable "why does this matter?" question
Lesson-Specific Vocabulary — terms introduced or reinforced in that lesson

How to read this in conjunction with the student lessons

Each Code Quest lesson is a self-contained HTML page that students work through at their own pace. This guide doesn't replace those lessons — it equips you to teach alongside them. The expected workflow:

Before class: read this lesson plan (5–10 min) and skim the student HTML lesson, paying special attention to interactive widgets (the Step-Through Tracer, the While Loop Visualizer)
During class: follow the lesson flow; the student HTML is the textbook + lab
After class: use the companion Answer Key to quickly grade Knowledge Checks and labs

💡 Unit 2 is where students hit "the wall." Lesson 1 (tracing) feels boring to some kids and easy to others. Lesson 2 (for loops) is the conceptual leap. Lesson 4 (while loops + infinite loops) is the highest-friction lesson of the unit. Build buffer time. The pacing guide assumes the average — but more than any other unit, individual student pacing varies wildly here.

🗺️ Unit 2 Overview

The big picture

Unit 2 introduces repetition — the single concept that turns programming from "writing instructions" into "writing programs that DO things." Students learn to read code line by line (tracing), then learn the two flavors of loop (for and while), then combine loops with the if/else logic from Unit 1. The capstone is a major upgrade to the Mad Libs game from Unit 1 — now with replay, multiple rounds, and real input handling.

What students learn

Trace code step-by-step using a trace table; predict what a program will print before running it
Write for loops using range() and list iteration
Identify the four parts of every for loop: keyword, loop variable, sequence, and body
Combine for loops with if/elif/else to make decisions on every iteration
Use counter variables to track results across the loop (initialize before, update inside, report after)
Manage three levels of indentation cleanly (top-level, inside loop, inside if-inside-loop)
Write while loops and choose between for and while based on whether the iteration count is known up front
Identify, prevent, and escape infinite loops — the most common while-loop bug
Use break to exit a loop early (and know when not to)
Apply the "prime the pump" pattern for input validation
Apply a 3-step debugging strategy — Read → Isolate → Test — and use print-debugging to find bugs
Build a complete replayable Mad Libs 2.0 game using the "two-loop sandwich" pattern (outer while, inner for)

Prerequisites

Unit 1. Students must be comfortable with: variables and reassignment, the four data types, the = vs == distinction, if/elif/else with correct colons and 4-space indentation, input(), and f-strings. If a student is shaky on indentation from Unit 1, address it before starting Unit 2 Lesson 3 — that's where indentation goes from 1 level to 2 levels and confusion compounds quickly.

What comes next

Unit 3 introduces algorithms — designing the steps of a solution before writing code, plus the formal pseudocode style. Unit 3 also introduces lists more deeply and adds the factorial loop pattern. The "plan-before-code" mindset that students just glimpsed in Lesson 2.5 (the SDLC plan stage) becomes central in Unit 3.

Materials you'll need

Computers with web browser access (one per student, or pairs)
Knowledge Pillars CodeSkills Lab access (where students write and run code)
Projector or large screen for live coding demos — Unit 2's interactive widgets (Step-Through Tracer, While Loop Visualizer) are great for whole-class projection
Whiteboard with space for trace tables (rows × columns) — used heavily in Lessons 1 and 3
This Teacher's Guide and the companion Answer Key
Optional: printed copies of the indentation rules from Unit 1 Lesson 4 — students will need them again in Lesson 2.3

        🎯 Course alignment. Unit 2 is the primary home of Florida CTE standard 07.03 (loops), plus heavy coverage of Exam Objective 2 (analyzing and predicting code behavior) — Lesson 1 is built almost entirely around this objective. See the Standards Crosswalk below for full lesson-by-lesson detail.
      

⏱️ Pacing Guide

Unit 2 is designed to fit in 7–9 class periods of approximately 45 minutes each. Lesson 4 (while loops) is intentionally slightly longer (50 min) because of the infinite-loop concept; Lesson 5 is a 2-day capstone. Adjust based on your students' Unit 1 fluency, class length, and how much homework time you can assume.

Recommended pacing — 8-day plan

Day	Lesson	Focus	Homework
Day 1	L1: Code Tracing	Reading code line-by-line. Trace tables. The Step-Through Tracer. Lab 2.1A in class.	Finish Lab 2.1B (paper trace)
Day 2	L2: For Loops	Anatomy of a for loop. `range()`. Looping a list. Lab 2.2A in class.	Finish Lab 2.2B
Day 3	L3: Loops + If/Else (pt 1)	If/else inside a for loop. Three indentation levels. Lab 2.3A in class.	Read Section 3 (counter variables)
Day 4	L3: Loops + If/Else (pt 2)	Counter variables. Tracing the combo. Lab 2.3B. Knowledge check.	Read L4 Sections 1–3 (why `while`)
Day 5	L4: While Loops (pt 1)	`while` syntax. `for`-vs-`while` choice. While Loop Visualizer. Lab 2.4A in class.	Read L4 Section 5 (infinite loops)
Day 6	L4: While Loops (pt 2)	Infinite loops, `break`, prime-the-pump input validation. Lab 2.4B. Knowledge check.	Plan Mad Libs 2.0 story
Day 7	L5: Mad Libs 2.0 Capstone	SDLC stages 1–2: PLAN + CODE. Two-loop sandwich pattern. Students begin building.	Continue building at home
Day 8	L5: Mad Libs 2.0 Capstone	SDLC stages 3–4: TEST + FIX. Peer testing. Showcase. Submit.	—

Compressed 7-day pacing

If you need to compress: combine Day 3 and Day 4 (cover all of Lesson 3 in one class) and assign Lab 2.3B as homework. This works for stronger groups but rushes the counter-variable concept — not recommended unless your students breezed through Unit 1.

Extended 9-day pacing

If you have a shorter class period (30 min) or you noticed your students struggling with indentation in Unit 1: split Lesson 4 across three days instead of two. Day 5 covers while syntax only; Day 6 covers the for/while choice + infinite loops; Day 7 covers break and input validation. This is the most generous pacing and recommended for first-time CS classes.

⏱️ Where the time usually goes. Lesson 1 (tracing) often runs fast — students who get it get it quickly. Lesson 3 (loops + if/else) consistently takes longer than expected because of three-level indentation. Lesson 4 (while + infinite loops) is the highest-friction lesson of the entire course so far. Build buffer here. Lesson 5 always benefits from a full 90 minutes — the last 15 of Day 2 (showcase) is the unit's emotional payoff.

Suggested grading weights for Unit 2

Component	Weight	Notes
Lesson Knowledge Checks (×4)	15%	3 questions each, completed in-platform
Lab Exercises (×8)	35%	Completed in CodeSkills Lab; checked for completion + correctness
Mad Libs 2.0 Final Project	40%	Capstone — see 100-pt rubric in Lesson 5 plan
Class participation	10%	Discussion, peer help, peer testing in capstone

Note: Mad Libs 2.0 is weighted higher than Unit 1's project because it's a 100-point rubric covering more skills, AND it explicitly requires the SDLC plan-test-fix cycle. The capstone is doing more pedagogical work this unit.

🎓 Standards & Exam Crosswalk

This crosswalk shows exactly which Florida CTE standards and Coding Fundamentals exam objectives each lesson addresses. Use this for admin reviews, IEP documentation, or to prove alignment when adopting the curriculum. Unit 2's primary "new" standard is 07.03 (loops); the unit also drills hard on Exam Objective 2 (analyze and predict code behavior).

Florida CTE Standards — Course #9009200

Standards from the Florida Department of Education Coding Fundamentals curriculum framework that Unit 2 addresses:

Standard	Description	Lessons
01.01	Use specialized computer coding software to solve problems.	All (CodeSkills Lab)
01.02	Demonstrate proficiency using specialized computer software (e.g., Python).	All
02.02	Explain the components of programming languages.	L1, L2, L3, L4
05.06	Recognize that more than one algorithm can solve a given problem.	L4 (for-vs-while), L5
05.07	Create a program that implements an algorithm to achieve a given goal.	L5 (Mad Libs 2.0)
07.01	Describe the structure of a simple program; explain why sequencing is important.	L1 (line-by-line tracing), L5
07.03	Describe iterative programming structures (loops); explain logic of loop conditions.	L2, L3, L4, L5 — primary unit standard
07.04	Describe selection programming structures (if/then, else); explain logic for if statements.	L3 (combined with loops), L5
07.05	Explain the types and use of variables in programming.	L2 (loop variables), L3 (counter variables)
07.07	Troubleshoot and debug errors in code.	L4 (infinite loops), L5 (3-step debugging)

Coding Fundamentals Exam Objectives

Exam objectives that Unit 2 prepares students for. Lesson 1 is built almost entirely around Objective 2 (predicting code behavior); Lesson 5 brings in Objective 7 (debugging) explicitly with a named strategy.

Obj	Title	Coverage in Unit 2	Lessons
1	Core programming concepts	Continued — loops are core	L2, L3, L4, L5
2	Analyze and predict code behavior	Full coverage — primary objective for L1	L1, L2, L3, L4
4	Write and debug simple programs	Heavy — capstone requires writing + debugging an interactive program	L4, L5
7	Debugging techniques	Heavy — explicit 3-step strategy + infinite loop diagnosis	L4, L5

Lesson-by-lesson alignment

Lesson	Florida Standards	Exam Objectives
L1: Code Tracing	01.01, 01.02, 02.02, 07.01, 07.05	2 (primary), 1
L2: For Loops	01.01, 01.02, 02.02, 07.03, 07.05	1, 2
L3: Loops + If/Else	01.01, 01.02, 02.02, 07.03, 07.04, 07.05	1, 2
L4: While Loops	01.01, 01.02, 02.02, 05.06, 07.03, 07.07	1, 2, 4, 7
L5: Mad Libs 2.0	01.01, 01.02, 05.06, 05.07, 07.01, 07.03, 07.04, 07.07	1, 2, 4, 7

📋 What's not in Unit 2. These standards are NOT addressed in Unit 2 and appear in later units: 03.x (file types) — Unit 6 · 04.03 (sorting/filtering) — Unit 10 · 06.03 (iterative SDLC debugging) — Unit 4 (Lesson 5 of Unit 2 previews this informally) · 07.02 (algorithms) — Unit 3 · 07.06 (pseudocode) — Unit 3 · 07.08 (databases) — Unit 10.

📖 Unit 2 Vocabulary Glossary

All key terms students will encounter in Unit 2. Almost every term is brand new this unit. The "Intro" column shows the lesson where the term first appears. Each lesson plan also includes its own focused vocabulary list.

Term	Definition	Example	Intro
Code Tracing	Following a program line by line — pretending to be the computer — to predict exactly what it will do, without running it.	`x = 5 → x = 8 → print(x)`	L1
Trace Table	A chart that tracks the value of each variable after every line of code runs, plus an Output column for what gets printed.	Line \| x \| y \| Output	L1
For Loop	A block of code that repeats a set number of times, or once for each item in a list.	`for i in range(5):`	L2
range()	Built-in Python function that generates a sequence of numbers. `range(5)` gives 0, 1, 2, 3, 4 (stop is exclusive).	`range(5)` → 0 1 2 3 4	L2
Loop Variable	The variable (often `i`) that holds the current count or item on each pass through the loop.	`for i in range(3):` → `i = 0, 1, 2`	L2
Loop Body	The indented code that runs every time the loop repeats.	The 4-space indented block under `for` or `while`	L2
Iteration	A single pass through the loop body. A loop that runs 5 times performs 5 iterations.	"Iteration 3 prints 'C'."	L2
Counter Variable	A variable that's initialized before a loop, updated inside, and read after — used to count or accumulate results across iterations.	`passing = 0` then `passing += 1`	L3
+= operator	Shortcut for "add to the variable's current value." `x += 1` means `x = x + 1`.	`count += 1`	L3
While Loop	A loop that repeats as long as a condition is True. Checks the condition before every iteration.	`while count > 0:`	L4
Infinite Loop	A while loop whose condition never becomes False. The program freezes. The most common while-loop bug.	Forgot to update the loop variable	L4
break	A keyword that exits the loop immediately, even if the condition is still True. Use sparingly.	`if answer == "quit": break`	L4
Input Validation	Asking the user repeatedly until they give acceptable input. The classic use case for `while`.	`while age < 0 or age > 120:`	L4
Prime the Pump	Pattern: set a variable to an obviously-invalid value before the loop, so the condition is True at the start and the loop body runs at least once.	`age = -1` then `while age < 0:`	L4
3-Step Debugging	Systematic strategy: Read the error message → Isolate the suspicious line → Test one fix at a time.	Read → Isolate → Test	L5
Print Debugging	Adding temporary `print()` statements to see what variables hold mid-program. Your first real debugging tool.	`print(f"DEBUG: x={x}")`	L5

📖 Teaching tip. 16 terms is a lot for one unit. Don't introduce them all at once — they're listed here for reference and end-of-unit review. Each lesson surfaces 3–5 new terms in context. The two terms students MUST own by the end of the unit: infinite loop (because they'll have caused one) and iteration (because the exam uses the word).

🕵️ Lesson 1 · Code Tracing — Read Before You Run

Lesson 1 · Code Tracing

Lesson Plan

At-a-Glance

Objective

Students will trace short Python programs line by line using a trace table, and will predict the output of a program before running it.

Time

45 minutes

Materials

Computer with browser, CodeSkills Lab access, projector, whiteboard with space for trace tables

Vocabulary

Code Tracing, Trace Table

FL Standards

01.01, 01.02, 02.02, 07.01, 07.05

Exam Obj.

Objective 2 (primary), Objective 1

Lesson Flow (45 minutes)

🔥 Warm-Up (5 min)

Project this on screen WITHOUT running it: x = 5; x = x * 2; x = x + 3; print(x). Ask: "What does this print? No clicking — just look."
Take 3–4 guesses. Most students will say 13 (forgetting the multiplication came first). The right answer is 13. Wait — actually walk it: x = 5, then x = 10, then x = 13. Yes, 13. Reveal that this skill — predicting WITHOUT running — is what today is about.

🎤 Direct Instruction (10 min)

Open Lesson 2.1 on the projector. Walk through Section 1 ("What is Code Tracing?") with the three rules: start at line 1, track every variable, never skip a line.
Walk through Section 2 ("The Trace Table"). Draw a trace table on the whiteboard with columns: Line | x | y | Output.
Live-trace this on the whiteboard, filling in cells as you go: x = 6; y = 4; x = x + y; y = x - 2; print(x); print(y). (Final: x=10, y=8, output: 10 then 8.)
Emphasize the difference between variable columns (filled when a variable changes) and the Output column (filled ONLY when print() runs).

🤝 Guided Practice (10 min)

Use the Step-Through Code Tracer in Section 3 of the lesson. Project it. Click "Step" together; pause and ask the class to predict each next move before clicking.
Run through one if/else trace from Section 4. Reinforce: in an if/else, ONLY ONE branch runs — and the trace table only fills in for that branch.

💻 Independent Lab (15 min)

Students complete the Predict the Output challenges in Section 6 — they write their guess, then run the code to check.
Then Lab 2.1A in CodeSkills Lab — paper trace required BEFORE running.
Circulate. Watch for students who run the code first and then "fill in" the trace table after — that defeats the purpose. Make them cover the screen with a hand or look away.

🚪 Exit Ticket (5 min)

On paper, students predict the output of: a = 10; b = 3; a = a - b; b = a + b; print(a); print(b)
Answer: 7 then 10. (a becomes 7; then b = 7 + 3 = 10.) Most common mistake: students apply the new b first or forget the order.

⚠️ Watch For — Common Misconceptions

1. "Why bother tracing? I'll just run it."

What you'll see: Students click Run before predicting. They never build the mental model. When the code breaks (in Unit 2 Lesson 4 with infinite loops, or in Unit 4 with debugging), they have no tracing habit to fall back on.

How to address: Frame tracing as "reading like a detective." Make a rule: in this class, you predict the output first, then run. The exam requires it — there's no Run button on a Coding Fundamentals exam. Bonus motivator: in real interviews, candidates trace code on a whiteboard. Every tech company does this.

2. "I only need to update the variable that changed."

What you'll see: A student leaves the other variable cells blank in subsequent rows of the trace table. Then they get confused about what the values WERE on later lines.

How to address: Insist on the rule: every row of the trace table fills in EVERY variable column, even if the value didn't change. The unchanged columns just copy down from the row above. This makes the "current state" visible at every line.

3. "print(x) changes x."

What you'll see: Students think a print statement updates the variable column. It doesn't — print just shows the value; nothing changes.

How to address: Drill the rule: print() only ever fills in the Output column, never the variable columns. The variable columns copy down unchanged. Use color on the whiteboard to make this visual.

🎯 Differentiation

For early finishers

Give them a longer trace exercise — a 10-line program with an if/else and 4 variables. Or have them WRITE a 6-line program that, when traced, prints exactly 5, 10, 25 in that order. (This forces them to think backwards from output.)

For struggling students

Slow down with smaller examples — 3 lines max, no if/else. Use the Step-Through Tracer one-on-one with them. The skill is real but it's a NEW skill — some kids need 2-3 sittings before it clicks. Don't rush; this skill compounds for the rest of the year.

💬 Discussion Prompts

Why is tracing valuable when computers can run code instantly? (Answer: tracing teaches you to UNDERSTAND code. When something breaks, you debug by tracing in your head. Computers run code; humans understand code.)
Have you ever solved a math problem in your head without a calculator? How is tracing similar? (Same skill: holding state in working memory and applying transformations one step at a time.)
What's the difference between READING code and TRACING code? (Reading is glancing at the structure. Tracing is simulating execution. Reading takes seconds; tracing takes minutes — but tracing is what catches bugs.)

🌍 Real-World Connections

Code reviews on GitHub. Every professional software team reviews each other's code before it ships. Reviewers don't run the code — they trace it mentally. Tracing IS code review.
Whiteboard interviews. Tech companies interview candidates by having them write code on a whiteboard with no computer. The interviewer traces along. Tracing is a hireable skill.
Embedded systems & aerospace. Software in pacemakers, satellites, and self-driving cars is reviewed by tracing every line by hand. There's no "click run" when the cost of a bug is a life.

📖 Lesson-Specific Vocabulary

Code Tracing — Following code line by line, pretending to be the computer, to predict what it will do without running it.

Trace Table — A chart with columns for the line number, each variable, and the output. Filled in row by row as you trace.

↑ Back to top

🔁 Lesson 2 · For Loops — Do It Again (and Again!)

Lesson 2 · For Loops

Lesson Plan

At-a-Glance

Objective

Students will write for loops using range() and lists; identify the four parts of a for loop (keyword, loop variable, sequence, body); and trace what each iteration does.

Time

45 minutes

Materials

Computer with browser, CodeSkills Lab access, projector for live demo

Vocabulary

For Loop, range(), Loop Variable, Loop Body, Iteration

FL Standards

01.01, 01.02, 02.02, 07.03, 07.05

Exam Obj.

Objectives 1, 2

Lesson Flow (45 minutes)

🔥 Warm-Up (5 min)

Ask: "How would you write a program that prints 'Hello!' five times?" Take a guess on the board — they'll write five print("Hello!") lines.
Now ask: "What if I want it 1,000 times?" Watch the realization. Then say: "Today we learn the tool that solves this — and it's only 2 lines."

🎤 Direct Instruction (10 min)

Open Lesson 2.2 on the projector. Walk through Section 1 ("Anatomy of a For Loop"). Live-code on projector: for i in range(5): print("Hello!"). Run it. Magic — 5 hellos, 2 lines.
Highlight the FOUR parts using color: the keyword for, the loop variable i, the sequence range(5), and the indented body print("Hello!").
Explain range() CAREFULLY. range(5) = 0, 1, 2, 3, 4 (five values, but starts at 0 and stops BEFORE 5). Use the Range Explorer in Section 2 to test variations: range(3, 8), range(0, 10, 2).
Demo looping a list: for color in ["red", "green", "blue"]:. Point out that the loop variable now holds an item, not a number.

🤝 Guided Practice (10 min)

Use the Loop Step-Through Visualizer in Section 3. Have students predict what i will be on each iteration before clicking Step.
On the whiteboard, ask: "What does for x in range(2, 7): print if we just print x?" (Answer: 2 3 4 5 6.) Drill the "stop is exclusive" rule.
Ask the trap question: "What does range(5) contain?" If a student says "1 to 5" or "5 numbers from 1 to 5" — gently correct: 0 to 4.

💻 Independent Lab (15 min)

Students complete Lab 2.2A ("Loop It!") in CodeSkills Lab — write 3 different for loops printing different outputs.
Lab 2.2B ("List Looper") — loop through a list of foods and print each.
Circulate. Watch for: missing colon at end of for line, missing indentation on body, putting code that should be INSIDE the loop OUTSIDE (so it only runs once).

🚪 Exit Ticket (5 min)

On paper: "What does for i in range(3): print(i * 2) print?"
Answer: 0, 2, 4 (each on its own line). Common mistakes: writing 2, 4, 6 (started at 1 instead of 0); writing only one number (forgot it loops); writing 6 (multiplied total).

⚠️ Watch For — Common Misconceptions

1. "range(5) means 1 to 5."

What you'll see: Students predict range(5) gives 1, 2, 3, 4, 5. They miss that Python starts at 0 by default.

How to address: Make this a unison chant: "range(5) is FIVE numbers, starting at zero, going UP TO BUT NOT INCLUDING five." Drill it. Have students count on their fingers: 0, 1, 2, 3, 4 — that's five fingers. Show list(range(5)) on the projector to make it visual: [0, 1, 2, 3, 4].

2. "Stop is INCLUSIVE in range(start, stop)."

What you'll see: Students write range(1, 10) expecting 1 through 10. They get 1 through 9 and don't understand why.

How to address: The rule: stop is exclusive. To get 1 through 10, write range(1, 11). Demonstrate this on the projector with list(range(1, 10)) vs list(range(1, 11)). Then say: "Python likes ranges that go up to BUT NOT INCLUDING. It's weird but consistent."

3. "Code outside the loop is part of the loop."

What you'll see: A student writes a loop, then a print("Done!") statement that they THINK runs every iteration but actually runs once after the loop. (Or the reverse — they put a "summary" line INSIDE the loop and it prints over and over.)

How to address: Indentation determines membership. Code indented under the for line is INSIDE the loop. Code at the same indent level as for is OUTSIDE. Have them count spaces. Use the visual model from the lesson — a literal box drawn around the loop body.

🎯 Differentiation

For early finishers

Challenge: write a loop that prints only the even numbers from 0 to 20. (Two valid approaches: range(0, 21, 2), OR range(21) with an if i % 2 == 0: inside — preview of Lesson 3!) Or have them try range with three arguments: range(10, 0, -1) for a countdown.

For struggling students

Stick to range(n) only — skip the two- and three-argument forms for now. Pair them with a stronger student for Lab 2.2B. Use the Loop Visualizer one-on-one — watching i change one step at a time is what makes for-loops click.

💬 Discussion Prompts

Why do you think Python (and most languages) start counting at 0 instead of 1? (Honest answer: math/computer science conventions go back to the 1960s. Indexes work cleaner with 0-based math. It's not arbitrary, but it IS something every new coder has to absorb.)
What's the difference between a for loop and just copy-pasting the same line 5 times? (Maintainability: change the loop once, all iterations update. Imagine wanting to change "Hello!" to "Hi!" if you'd written 1,000 lines.)
The loop variable i changes value on every iteration. Is that the same as the reassignment we did in Unit 1? (Yes — exactly! Python is just doing the reassignment for you, automatically, once per iteration.)

🌍 Real-World Connections

Every list of items on every webpage is built with a loop. Your social media feed, a product grid on Amazon, the contacts in your phone — a loop walks the data and builds one row of HTML per item.
Animations and games. Game frames are a loop: every 1/60th of a second, the loop body updates the screen. The for-loop variable is the "tick" counter.
Spreadsheets. A formula like =SUM(A1:A100) is secretly a for loop walking 100 cells.

📖 Lesson-Specific Vocabulary

For Loop — A block of code that runs once for each item in a sequence. The Python keyword is for.

range() — Built-in function that generates a sequence of numbers. range(5) = 0,1,2,3,4. Stop is exclusive.

Loop Variable — The variable (often i) that holds the current value on each iteration.

Loop Body — The indented code under the for line. Runs once per iteration.

Iteration — A single pass through the loop body. range(5) produces 5 iterations.

↑ Back to top

🧠 Lesson 3 · Loops + If/Else — The Power Combo

Lesson 3 · Loops + If/Else

Lesson Plan

At-a-Glance

Objective

Students will combine a for loop with if/elif/else to make a different decision on every iteration; they will use a counter variable to track results across the loop; they will manage three indentation levels correctly.

Time

45 minutes (often runs 50 min — build flex)

Materials

Computer with browser, CodeSkills Lab access, projector, whiteboard

Vocabulary

Counter Variable, += operator, nested logic

FL Standards

01.01, 01.02, 02.02, 07.03, 07.04, 07.05

Exam Obj.

Objectives 1, 2

⚠️ Indentation jumps from 1 level to 2 levels in this lesson. If any students were shaky on Unit 1 indentation, you'll see it surface here. Sit with them as they fix the first IndentationError — the pattern only clicks when they fix one themselves.

Lesson Flow (45 minutes)

🔥 Warm-Up (5 min)

Project this list: scores = [45, 88, 72, 91, 67, 83]. Ask: "How many are passing (≥70)?"
Take a guess. Have a student count by hand (4). Then say: "Today we make Python do this for us — even with a list of 1,000 scores."

🎤 Direct Instruction (12 min)

Open Lesson 2.3. Walk through Section 1 ("If/Else Inside a For Loop"). Live-code: for score in scores: if score >= 70: print("PASS"); else: print("FAIL"). Run on the warm-up list. The class can now SEE 4 PASS lines.
Walk through Section 2 ("Three Levels of Indentation"). On the whiteboard, draw the L0 / L1 / L2 visual: L0 = no indent, L1 = inside loop (4 spaces), L2 = inside if-inside-loop (8 spaces).
Walk through Section 3 ("Counter Variables"). Live-code the counter pattern: passing = 0 BEFORE the loop, passing += 1 INSIDE the if, print(passing) AFTER the loop. Run it. Confirm: 4.
Show the += shortcut: passing += 1 is the same as passing = passing + 1 (echo of Lesson 1.1 reassignment).

🤝 Guided Practice (8 min)

Use the Combo Step-Through Tracer in Section 5. Watch amazing_count increment only on iterations where score ≥ 90.
On the whiteboard, draw a trace table for a 4-iteration loop with a counter. Have students fill in the counter column row by row.

💻 Independent Lab (15 min)

Students complete Lab 2.3A ("Grade Counter") in CodeSkills Lab — use a counter to count how many scores in a list are A's.
Lab 2.3B ("Multi-Counter") — track THREE counters (passes, fails, perfects) in one loop.
Circulate intensely. The most common bug: counter initialized inside the loop (resets every iteration → final value is always 0 or 1).

🚪 Exit Ticket (5 min)

On paper: "In your own words, why must the counter be initialized BEFORE the loop?"
Look for: "because if it's inside the loop, it gets reset every time" or similar. If they can't articulate this, the concept hasn't landed — reteach with a quick whiteboard trace next class.

⚠️ Watch For — Common Misconceptions

1. "Initialize the counter inside the loop."

What you'll see: A student writes for score in scores: passing = 0; if score >= 70: passing += 1. The counter resets every iteration. Final value: 0 or 1, never the right answer.

How to address: Use the "scoreboard" analogy: you don't reset the basketball scoreboard every time someone scores — you set it to 0 BEFORE the game starts, and each score adds. The counter is the scoreboard. passing = 0 goes BEFORE the loop, ALWAYS.

2. "Three indentation levels confuse Python."

What you'll see: The passing += 1 line is at L1 (4 spaces) when it should be at L2 (8 spaces, inside the if), so it counts EVERY score, not just the passing ones.

How to address: Walk students through the L0 / L1 / L2 visual. Ask each line: "Is this inside the loop? Is it inside the if?" The answer determines the indent level. Count spaces: 0, 4, or 8. Print the indent rules card.

3. "Print the counter inside the loop."

What you'll see: A student's program prints "Passing: 1, Passing: 2, Passing: 3" — they put the print INSIDE the loop instead of AFTER.

How to address: Reinforce the three places a counter pattern lives: BEFORE the loop (initialize), INSIDE the loop (update), AFTER the loop (read). Get them to label their code with these three comments before running.

4. "x += 1 and x = x + 1 are different."

What you'll see: Some students use one and don't realize the other does the same thing. Or they think += only works for numbers (it works for strings too).

How to address: Show both side by side on the projector. Run them. Confirm same output. Tell students to use whichever feels more natural — pros use both. += is a shortcut, not magic.

🎯 Differentiation

For early finishers

Challenge: track FOUR counters in one loop on a list of test scores — A's (≥90), B's (80-89), C's (70-79), and F's (<70). Bonus: print the percentages at the end (use len(scores) for the total).

For struggling students

Skip Lab 2.3B for class time. Stay on Lab 2.3A — single counter, simple if. Use a printed trace-table template they can fill in by hand before writing the code. The win is recognizing the pattern: before / inside / after.

💬 Discussion Prompts

What's the difference between a loop variable (like i) and a counter variable (like passing)? (Loop variable: Python sets it for you on each iteration. Counter: YOU set it, BEFORE the loop, and YOU update it inside.)
If your loop tracks 5 counters, that's a lot of variables. What might be a cleaner approach? (Preview of Unit 5: dictionaries! For now, multiple counters is fine — just a hint.)
Could you use an elif chain inside a for loop? (Yes — and you'll do exactly that in Mad Libs 2.0 to pick prompts per round. The combination is the heart of Unit 2.)

🌍 Real-World Connections

Email spam filtering. A loop walks every email; an if/else categorizes each as spam or inbox; counters track how many of each type you've received this week.
Sports stats. A loop walks every play in a game; if/else figures out what KIND of play (run, pass, fumble); counters tally each type.
Voting. A loop reads every ballot; if/else figures out the choice; counters count votes per candidate. The same pattern runs every election in the world.

📖 Lesson-Specific Vocabulary

Counter Variable — A variable that's initialized BEFORE the loop, updated INSIDE, and read AFTER. Used to count things across iterations.

+= operator — Shortcut for "add to the variable." x += 1 is the same as x = x + 1. Pronounced "plus-equals."

Nested logic — Code structure where one block (like an if) lives inside another block (like a for loop), creating multiple indentation levels.

↑ Back to top

♾️ Lesson 4 · While Loops — When the Count Is Unknown

Lesson 4 · While Loops & Iteration Choices

Lesson Plan

At-a-Glance

Objective

Students will write while loops with correct conditions; choose between for and while based on whether the iteration count is known up front; identify and fix infinite loops; use break appropriately; and apply the prime-the-pump pattern for input validation.

Time

50 minutes (or split across two days for deeper coverage)

Materials

Computer with browser, CodeSkills Lab access, projector for live demo (especially the While Loop Visualizer)

Vocabulary

While Loop, Infinite Loop, break, Input Validation, Prime the Pump

FL Standards

01.01, 01.02, 02.02, 05.06, 07.03, 07.07

Exam Obj.

Objectives 1, 2, 4, 7

⚠️ Highest-friction lesson of Unit 2. Infinite loops feel scary the first time. Two specific moments require careful framing: (1) when a student's program freezes from an infinite loop, model calm — "this is normal, here's how we escape". (2) When showing the visualizer's infinite-loop scenario, use the "Trigger break!" button to escape — students need to see a way out exists.

Lesson Flow (50 minutes)

🔥 Warm-Up (5 min)

Ask: "I want a program that asks a player to type 'play again' and keeps playing until they say no. How many times will the loop run?"
Take guesses. Then say: "We don't KNOW. Could be 1, could be 50. for can't help — for needs to know the count up front. Today we meet while — the loop for 'I don't know how many.'"

🎤 Direct Instruction (15 min)

Open Lesson 2.4. Walk through Section 1 ("Why Do We Need Another Kind of Loop?"). Reinforce the difference: for = "I know how many"; while = "I know when to stop."
Walk through Section 2 ("The While Loop"). Live-code the countdown: count = 5; while count > 0: print(count); count -= 1. Run it. Walk through line by line.
Walk through Section 3 ("for vs. while"). Use the 30-second rule from the lesson: "What makes this loop stop? If 'I'll have done it N times' → for. If 'when X happens' → while."
Walk through Section 5 ("Infinite Loops"). Live-code the bug: drop the count -= 1. The loop runs forever. Use Ctrl+C (or the Stop button in CodeSkills Lab) to escape. Frame this calmly: "You haven't broken Python. You wrote an infinite loop. Here's how we recognize them."
Walk through Section 6 (break). Live-code the while True: + break pattern. Emphasize: use break sparingly. Prefer a clean condition when possible.
Walk through Section 7 ("Input Validation" — the "prime the pump" pattern). This is the killer use case. Run it. Type bad input — watch it ask again. Type good input — watch it accept.

🤝 Guided Practice (10 min)

Use the While Loop Visualizer in Section 4. Project it. Walk through the Countdown scenario together. Then the Password Retry scenario. Finally — bravely — the Infinite Loop scenario. Use the "Trigger break!" button to escape and show that infinite loops are recoverable.
On the whiteboard, write a buggy snippet: i = 0; while i < 5: print(i). Ask: "What's missing? What does this do?" (Missing i += 1; runs forever printing 0.)

💻 Independent Lab (15 min)

Students complete Lab 2.4A ("Countdown") in CodeSkills Lab — write a working countdown using while.
Lab 2.4B ("Validate the Input") — keep asking for an age until the user gives a valid one (0–120). This is the prime-the-pump pattern in practice.
Circulate intensely. Students WILL hit infinite loops in this lab. When they do, sit with them, identify the missing or wrong update line, and have THEM fix it. The fix-it-yourself moment is when the concept locks in.

🚪 Exit Ticket (5 min)

On paper: "You're writing a program that keeps asking for a password until the user gets it right. Should you use for or while? Why?"
Answer: while — you don't know how many tries. Look for the reasoning: "the count depends on the user." If they answer "for, with range(10) for 10 tries" — gently push back: that artificially limits the user, while works without a guess.

⚠️ Watch For — Common Misconceptions

1. "I forgot to update the variable inside the loop." (Infinite loop type 1)

What you'll see: Program freezes. The student's while condition uses a variable that never changes inside the loop body.

How to address: Teach the "infinite-loop checklist" from the lesson: every time you write a while loop, ask aloud — "What changes inside the body that will eventually make the condition false?" If you can't point to a specific line, you have an infinite loop. Make this question a habit.

2. "I updated the wrong variable." (Infinite loop type 2)

What you'll see: Student wrote while count > 0: ... i += 1 — they're updating i, not count. Same problem, harder to spot.

How to address: The condition variable and the update variable MUST match. Walk through their code and box the variable in the condition, then box every update inside. They should be the same name.

3. "I updated in the wrong direction." (Infinite loop type 3)

What you'll see: while count > 0: count += 1 — count grows away from 0 instead of toward it. Loop never ends.

How to address: Show on the whiteboard: condition is "count > 0". Update should make count smaller, not bigger. Sketch it as an arrow: count starts at 5, the condition stops at 0, the update arrow points DOWN.

4. "Use break everywhere."

What you'll see: A student writes while True: for everything and uses break as the only exit, even when a clean condition would work better.

How to address: Reinforce the rule from the lesson: "Use break sparingly. When a condition can express the stop cleanly, use the condition. Reach for break when there are multiple exits or the stop logic is genuinely complex." while True: is a power tool, not the default.

🎯 Differentiation

For early finishers

Challenge: write a number-guessing game using while True: and multiple break conditions — break on correct guess, break on "give up," break on too many tries. This previews the multi-exit pattern that Mad Libs 2.0 uses.

For struggling students

Focus on Lab 2.4A only — the countdown pattern. Skip break and while True: for now. Skip Lab 2.4B too if needed. The win for struggling students this lesson: write ONE working while loop without an infinite loop. That's enough.

💬 Discussion Prompts

If for can do everything while can do (just with a max), why does while exist? (Cleaner code, no arbitrary max guesses, expresses intent better — "stop WHEN" not "stop AFTER".)
What happens if your while condition is False from the very start? (The loop body NEVER runs — not even once. This is different from "prime the pump" — there you SET the variable to make the condition True at the start.)
Have you ever had an app freeze on you? Do you think it might have been an infinite loop somewhere? (Probably yes! Most "frozen apps" are either infinite loops or waiting on a network call. Coders cause both.)

🌍 Real-World Connections

Login screens. "Keep asking until they get the password right (or after 5 tries, lock the account)" — that's while + a counter + break.
Auto-save. "Every 30 seconds, save the document. Keep doing this while the document is open." Pure while.
Game loops. Every video game runs a "while game_running:" loop that updates the screen 60 times per second until the game ends.
The internet. Servers run while True: loops accepting requests — they're SUPPOSED to run forever (until shut down).

📖 Lesson-Specific Vocabulary

While Loop — A loop that repeats as long as a condition is True. Checks the condition before every iteration.

Infinite Loop — A while loop whose condition never becomes False. The program freezes. Usually a bug.

break — Keyword that exits a loop immediately, even if the condition is still True. Use sparingly.

Input Validation — Asking the user repeatedly until they give acceptable input. The classic use case for while.

Prime the Pump — Pattern: set the loop variable to a deliberately-invalid value before the loop, so the condition is True at the start and the body runs at least once.

↑ Back to top

🎮 Lesson 5 · Mad Libs 2.0 — Replay Capstone

Lesson 5 · Mad Libs 2.0 Capstone

Project Plan

At-a-Glance

Objective

Students will integrate for loops, while loops, if/elif/else, lists, input(), and f-strings into a complete replayable Mad Libs game; they will follow the four SDLC stages (PLAN → CODE → TEST → FIX) and apply the 3-step debugging strategy.

Time

Two class periods (90 minutes total) recommended

Materials

Computer, CodeSkills Lab, projector, optional: printed Mad Libs sample stories for inspiration

Vocabulary

3-Step Debugging, Print Debugging, "two-loop sandwich" pattern, all prior Unit 2 vocabulary

FL Standards

01.01, 01.02, 05.06, 05.07, 07.01, 07.03, 07.04, 07.07

Exam Obj.

Objectives 1, 2, 4, 7 — comprehensive Unit 2 application

Project Flow (90 minutes across 2 days)

📅 Day 1 — Plan + Code (45 min)

Warm-up (5 min): Project the original Unit 1 Mad Libs. Ask: "What was missing? What would make it better?" Steer toward "play again" and "more rounds."
Introduce the SDLC (5 min): Walk through Section 1 of the lesson — PLAN, CODE, TEST, FIX. This is the rhythm of every real software project. Today we DO it.
Introduce the 3-step debugging strategy (5 min): Read → Isolate → Test. This is your superpower for the rest of the unit (and the rest of your coding life).
Live walkthrough — the "two-loop sandwich" (10 min): Open Section 4 (Stage 1 — Plan). Show the structure on the whiteboard. OUTER while loop = "keep playing more games." INNER for loop = "3 rounds within one game." This pattern shows up in every game ever made.
Project setup + plan (10 min): Students copy the starter code into CodeSkills Lab. They write their plan as comments at the top BEFORE coding. They decide: their story, their 3 prompts, their replay sentinel ("yes" by default).
Independent build (10 min): Students start coding the inner-loop game first (just one round). Then add the for loop. Then wrap with while.

📅 Day 2 — Test + Fix + Showcase (45 min)

Continue building (10 min): Students finish their full two-loop sandwich. Many will be stuck on bugs from Day 1 — perfect, that's why we have Day 2.
Stage 3 — Test (10 min): Students run through the 8-test checklist from the lesson. Especially: 3 games in a row, "Yes" vs "yes" (case sensitivity), empty input.
Stage 4 — Fix (10 min): Pair students up. Each tests a partner's program and reports bugs. Use the 3-step debugging strategy out loud: "I'm reading the error... isolating to this line... testing this fix..."
Showcase (15 min): Pick 3–5 volunteers to run their Mad Libs 2.0 in front of the class with class members supplying the words. Encourage running multiple rounds with bonus stretch goals visible (custom themes, ASCII art, etc.).

⚠️ Watch For — Common Project Pitfalls

1. The "game runs forever" bug.

What you'll see: Game starts new rounds endlessly. No error message — just frozen output.

How to address: This is the Lesson 4 infinite-loop bug come home to roost. The student forgot to ask "play again?" inside the while loop, OR forgot to update play_again with the answer. Walk them through: "What changes inside the loop that should make play_again != 'yes'?" If they can't answer — there's the bug.

2. The "only 1 round" bug.

What you'll see: Game runs but only asks 1 question, then crashes printing the story with IndexError: list index out of range.

How to address: The student likely wrote range(1) instead of range(3). The story uses words[0], words[1], words[2] — but only one word was collected. Use the 3-step strategy: Read the IndexError, isolate the line using words[1], test by changing range(1) to range(3).

3. The "Yes" vs "yes" case-sensitivity bug.

What you'll see: Player types "Yes" with a capital Y. Game quits unexpectedly because "Yes" != "yes".

How to address: Show the fix: play_again = input("Play again? ").lower(). Calling .lower() on the input normalizes capitalization before the comparison. This previews methods (Unit 5).

4. F-string quote-nesting (carryover from Unit 1).

What you'll see: SyntaxError when a student writes print(f"They said "hello" to me").

How to address: Same as Unit 1 Lesson 5. Use single quotes inside double-quoted f-strings: print(f"They said 'hello' to me").

🎯 Differentiation

For students who finish early

Direct them to the bonus stretch goals: case-insensitive replay (.lower()), 4 rounds instead of 3, ASCII art divider between games, a "rounds played this session" counter, multiple themed stories chosen by user. Each adds +5 pts (max +20).

For struggling students

It's OK if their Mad Libs 2.0 only does 1 game (no while loop) but cleanly does 3 rounds (the for loop works). That's still a B-range submission — they demonstrated the for + if/else combo from Lesson 3. Skip the outer while if needed; come back to it as a stretch.

💬 Discussion Prompts

Why does the OUTER loop control replay and the INNER loop control rounds, not the other way around? (Because the whole game restarts inside the while. If you swapped them, you'd ask "play again?" between every word — wrong shape entirely.)
What was the hardest bug you fixed today? Walk us through how you found it. (This metacognitive question normalizes debugging as the main act of programming, not a failure mode.)
If you had another week, what would you add? (This sets up Unit 3 — algorithms — by having students articulate features they don't yet know how to build.)

🌍 Real-World Connections

Every game you've ever played. Pac-Man's lives, Tetris's levels, Mario's worlds — all use the same outer/inner loop pattern. The outer loop is "keep playing the meta-game"; the inner loop is "play this level."
The 3-step debugging strategy (Read → Isolate → Test) is exactly how senior engineers debug production systems. You just learned it on day one of your coding career.
SDLC. Every piece of software at every company follows some version of plan-code-test-fix. You can list this on a resume now: "applied SDLC methodology to a personal project." That's not a stretch — that's literally what you did.

📋 Mad Libs 2.0 Project Rubric (100 points)

The Mad Libs 2.0 rubric matches the one inside the student lesson. Students see this rubric while they build, so there are no surprises at submission.

Category	What to look for	Pts
While Loop Replay	An outer `while` loop wraps the game. The player can play multiple full games. Quitting works cleanly.	20
For Loop Rounds	An inner `for` loop runs 3 rounds within each game. Uses `range(3)` with a counter or list.	15
If/Elif/Else Inside Loop	A conditional inside the for loop picks a different prompt for each round. All 3 branches reachable.	15
Story Output	After the 3 rounds, words are plugged into a story using f-strings. Output is readable and fun.	10
Polish	Case-insensitive replay, clear round labels, blank lines between sections, friendly goodbye.	10
Comments & Style	Header comment, plan block, inline comments per section, clear variable names, 4-space indentation.	10
Debugging Mindset	Code runs without errors. Bugs found during build documented with a comment showing the fix.	10
Works Correctly	All 8 test cases from Stage 3 pass. Especially: 3 games in a row, case insensitivity, empty input doesn't crash.	10
TOTAL		100

🎁 Stretch Goals (extra credit)

Case-insensitive replay using .lower() on the input: +5 pts
4 rounds instead of 3, with a 4th distinct prompt branch: +5 pts
Game counter — "You've played X games this session": +5 pts
Multiple themed stories the player can choose at game start: +5 pts
ASCII art divider between games or a celebration screen at the end: +5 pts

Maximum stretch credit: +20 points. Document each stretch goal in a comment at the bottom of the file.

💡 Showcase tip. The Day-2 showcase is the unit's emotional payoff. Pick 3–5 volunteers — and try to include at least one student who struggled with Lesson 4. When the class laughs at their Mad Libs output, that student walks away thinking "I built that." That moment is the unit's biggest win, and it carries into Unit 3.

📖 Lesson-Specific Vocabulary

3-Step Debugging — Read the error message → Isolate the suspicious line → Test one fix at a time. The most important habit in this entire course.

Print Debugging — Adding temporary print() statements (e.g., print(f"DEBUG: x={x}")) to see what variables hold mid-program. Your first real debugging tool.

Two-Loop Sandwich — A common pattern: an outer loop wrapping an inner loop, each handling a different layer of repetition. In Mad Libs 2.0: outer while for replay, inner for for rounds.

SDLC (Software Development Life Cycle) — The four-stage rhythm of every software project: PLAN → CODE → TEST → FIX. Unit 4 covers this in depth; Unit 2 introduces it informally here.

↑ Back to top

🛠️ Appendix · Common Python Errors in Unit 2

This appendix lists the most common Python error messages students will see in Unit 2 and how to help them fix each one. Unit 2 introduces a unique class of bug — the infinite loop — which produces NO error message at all. We cover that too.

ERRORSyntaxError: expected ':'

What it usually means: Forgot the colon at the end of a for, while, if, elif, or else line.

How to fix: Add the : at the end of that line. Carryover from Unit 1 — every line that introduces a block ends with a colon.

ERRORIndentationError: expected an indented block

What it usually means: Python expected indented code after a for, while, if, or else, but the next line wasn't indented.

How to fix: Indent the loop body or branch body by 4 spaces. In Lesson 3, the loop body is at 4 spaces and the if-inside-loop body is at 8 spaces.

ERRORIndentationError: unindent does not match any outer indentation level

What it usually means: Mixed tabs and spaces, OR inconsistent indentation across the loop body (some lines at 4 spaces, others at 6). Especially common in Lesson 3 with three indent levels.

How to fix: Re-indent the entire block uniformly with 4-space steps. Eyeball the L0/L1/L2 visual: every line must be at one of three exact column positions.

ERRORNameError: name 'x' is not defined

What it usually means: Python is asked to use a variable that doesn't exist. In Unit 2, the most common cause is referencing a counter variable that was initialized INSIDE the loop instead of before — or trying to use the loop variable AFTER the loop in some Python contexts.

How to fix: Move the counter initialization (passing = 0) BEFORE the for line. The counter exists outside the loop, gets updated inside, gets read after.

ERRORTypeError: 'int' object is not iterable

What it usually means: Student wrote for i in 5: instead of for i in range(5):. They tried to loop over the number 5 directly. Python iterates over sequences, not single numbers.

How to fix: Wrap the number in range(): for i in range(5):.

ERRORIndexError: list index out of range

What it usually means: Tried to access a list position that doesn't exist. In Mad Libs 2.0, this happens when the for loop only collected 1 or 2 words but the story uses words[2].

How to fix: Check the range() count matches the number of items the program references. If the story uses words[0], words[1], words[2], then the loop must use range(3), not range(1) or range(2).

ERRORTypeError: '>' not supported between instances of 'str' and 'int'

What it usually means: The condition compares an input() result (a string) with a number. Carryover from Unit 1's "quotes trap" — but more common in Unit 2 because input validation requires comparing input to a number.

How to fix: Wrap the input with int(): age = int(input("Age: ")). Now the comparison age < 0 works.

SILENT(no error — program freezes)

What it usually means: Infinite loop. The while condition never becomes False. There's no error because Python is running normally — forever.

How to fix: Force-quit the program (Ctrl+C in a terminal, or click Stop in CodeSkills Lab). Then check three things: (1) Is the condition variable being updated inside the loop? (2) Is it the SAME variable that's in the condition? (3) Is the update going in the right DIRECTION (toward making the condition False)? 95% of infinite loops fail one of these three checks.

        🛟 The 3-step debugging strategy applies to every error above. (1) Read the error message ALOUD — it's specific. (2) Isolate the line Python points to. (3) Test ONE fix at a time, run, observe. This is the rhythm of professional debugging. Build the habit in Unit 2 and it carries you the rest of the year.
      

📘 Companion document. A Unit 2 Answer Key with Knowledge Check answers and lab solutions can be authored separately on request. The Teacher's Guide + Answer Key are designed to be used together (the Unit 1 pair is the model).

— End of Unit 2 Teacher's Guide —

↑ Back to top