Activity 01
Collaborative Flowcharting: Decision Trees
Each group receives a real-world decision scenario (a school nurse deciding whether a student should go home, a streaming service deciding what to recommend, a loan approval system). Groups build a complete decision tree on chart paper using only conditionals, then swap with another group to find missing branches or impossible conditions.
Design conditional logic to handle complex decision trees in a program.
Facilitation TipDuring Collaborative Flowcharting have each group label every arrow with the Boolean expression that triggers it, not just the action.
What to look forPresent students with a simple scenario, such as a temperature check for outdoor activities. Ask them to write an if/else statement in pseudocode: 'If temperature is greater than 70 degrees, print 'Wear shorts'. Else, print 'Wear pants'.'
AnalyzeEvaluateCreateDecision-MakingSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 02
Think-Pair-Share: Boolean Debugging
Present five if/else code snippets, each with a subtle logical error (off-by-one on a threshold, a condition that can never be true, overlapping ranges). Students individually identify what is wrong, then compare diagnoses with a partner and agree on a correction before the class discusses.
Analyze how different conditions lead to varied program outcomes.
Facilitation TipDuring Think-Pair-Share give partners only 90 seconds to find the bug so they practice rapid Boolean reading without overthinking.
What to look forStudents create a flowchart for a simple decision-making process (e.g., deciding what to wear based on weather). They exchange flowcharts and check for logical completeness: Are all paths covered? Are conditions clear and unambiguous? Partners provide one suggestion for improvement.
UnderstandApplyAnalyzeSelf-AwarenessRelationship Skills
Generate Complete Lesson→· · ·
Activity 03
Live Coding Review: Trace the Execution
Walk through a multi-branch if/else chain as a class with different input values called out by students. Students predict which branch executes before the code runs, then verify. Use surprising inputs (negative numbers, zero, very large values) to expose edge cases and missed conditions.
Construct a program that uses if/else statements to respond to user choices.
Facilitation TipDuring Live Coding Review pause execution on the line with the condition and ask, "What does the computer see right now?".
What to look forGive students a short Python code snippet with an if/else statement and a specific input value. Ask them to write down the exact output the program will produce and explain why.
AnalyzeEvaluateCreateDecision-MakingSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 04
Peer Review: Nested Conditions
Students write a program with at least two levels of nested conditionals, then exchange code with a partner. Partners trace through three test cases by hand before running the code, noting where their prediction differed from actual output and why.
Design conditional logic to handle complex decision trees in a program.
Facilitation TipDuring Peer Review of Nested Conditions require students to add one boundary value test case for every nested level they review.
What to look forPresent students with a simple scenario, such as a temperature check for outdoor activities. Ask them to write an if/else statement in pseudocode: 'If temperature is greater than 70 degrees, print 'Wear shorts'. Else, print 'Wear pants'.'
AnalyzeEvaluateCreateDecision-MakingSelf-ManagementRelationship Skills
Generate Complete Lesson→A few notes on teaching this unit
Start with scenarios students already understand—eligibility rules for sports, school lunch choices, temperature thresholds—so the code mirrors decisions they make daily. Avoid letting students treat if/else as a magic template; insist they state the condition in plain English first. Research shows that tracing concrete values (32°F, 75°F, 70°F) before abstract logic reduces fall-through errors by 40% compared to starting with variables alone.
By the end of these activities, students will read and write if/else blocks with confidence, recognize when a path is missing, and explain why nesting and else-if behave differently. They will use precise language—condition, branch, threshold, fall-through—to describe their code and catch gaps before they ship.
Watch Out for These Misconceptions
Students think the else clause must always be included.
During Peer Review: Nested Conditions, have reviewers check every else block to confirm it adds meaningful code; if not, recommend deleting it and justify the removal in one sentence.
Students believe two conditions cover all possible cases if they look exhaustive.
During Collaborative Flowcharting: Decision Trees, ask each group to add a test value exactly at the boundary (e.g., 5) and trace the path it takes to expose uncovered cases.
Students treat nested ifs and chained else-if as interchangeable.
During Live Coding Review: Trace the Execution, run the same input through both structures and compare outputs side-by-side on the whiteboard to make the difference concrete.
Methods used in this brief