Debugging Model Lesson (16 minutes)

(1 minute) Overview and Context

Facilitator Note: This session includes a modified version of Course C, Lesson 4: Debugging in Maze to model teaching and learning about debugging while using pair programming. Facilitators and participants engage with debugging through role playing wearing teacher and learner hats, just like during the “Model Lessons” session. The purpose of role playing during the debugging is:

• For facilitators to model debugging which is an essential skill and process in CS
• To provide teachers with an experience of how learners might engage with debugging
• To provide an additional opportunity for participants to engage with the curriculum as learners

Debugging Lesson Context

• The debugging lesson is part of Course C, designed for students in second grade.
• The debugging lesson is another example of a skill-building lesson, done on the computer.
• The debugging lesson shown here is shortened and modified for the purpose of understanding debugging.
  • Please refer to the lesson plan for the full lesson.
• Pair programming is introduced during the debugging lesson, but a modification will be in place for the purpose of learning about pair programming.

(15 minutes) Debugging Lesson

Warm Up (3 minutes)

Invite a couple of participants to briefly volunteer responses to the following prompts.

Prompts:

• How do you fix something that isn’t working?
• Do you follow specific steps?

Introduce the following vocabulary words:

• Bug: Something that is going wrong with the code, an error.
• Debugging: Finding and fixing “bugs” or errors in the code to fix.
• Persistence: A student practice of not giving up when trying things many different ways, many different times.

Share with participants they will be working to fix code or “debug” today.

Share with participants they will watch a video about pair programming, a video about debugging, and work with a partner on Lesson 4.

Activity (10 minutes)

Say: Today we will work in pairs using pair programming as we work on fixing code. Let’s first watch a video to learn about pair programming.

• (2:51 minutes) Show the video “Pair Programming” for participants to watch as a whole group.

• Invite participants to ask any questions about pair programming (as a learner, not as a teacher).

  • If a participant asks a question as a teacher, encourage them to write it down to come back to later.

• Transition participants to sit in pairs and work on a single device as they will engage in pair programming.

Say: Let’s watch a video to learn about debugging.

• (1:50 minutes) Show the video “Debugging” from Course C, Lesson 4: Level 1 for participants to watch as a whole group.

Say: Instead of working with partners, I am going to show you how pair programming works. I will be the driver and you as a class will be the navigator. Please be patient with me and don’t all shout out at once.

• (2 minutes) Have participants work on Course C, Lesson 4: Level 2 with you as the driver and the whole group as the navigator.
• (5 minutes) Participants work individually on Course C, Lesson 4: Level 3.
  • Tell them it is okay if they feel frustrated and encourage them to ask others for help.

Wrap Up (2 minutes)

Share with participants the journal prompts for the Wrap Up, but do not have the participants complete the journal prompts.

• Journal Prompt:
  • Today’s lesson was about debugging.
  • Draw and write about a bug you found and how you debugged it.

Transition: Share with participants they will now take their learner hats off and transition back to their teacher hat.

Debugging Debrief (14 minutes)

(3 minutes) Pair Programming

Briefly share with participants what pair programming is and how to use pair programming. Invite participants to ask any clarifying questions about pair programming.

• Pair programming is a technique in which two programmers work together at one computer.

  • The “driver” writes the code on the screen while the “navigator” directs the design and setup of the code (tells the “driver” what to write).
  • The two programmers switch roles often.

• Share the following resources with participants to refer to after the workshop:

  • Page 25 of the Curriculum Guide
  • Code.org support article,“How does pair programming on Code.org work?”

(11 minutes) Breakout Rooms

(7 minutes) Debugging Process

• Refer participants to the Debugging Process Guide on page 28 of the Curriculum Guide.

Participants discuss the following prompts in breakout rooms with small groups of 3-4 people and share their small group response on the designated slides.

Prompts:

• What modifications to the debugging process, if any, did you suggest to meet the needs of your students?
• How does debugging as a process support inclusion where all students are engaged and learning CS?
  • Example responses:
    • Debugging as a process means all students are working together to learn about debugging and how to practice it individually.
    • This can be a time to create a classroom culture that welcomes making mistakes in order to learn from them.
    • Debugging as a process can be an opportunity for students to learn from each other by listening to possible solutions and seeing how others (including the teacher) find ways to fix code.

Transition: Remind participants the designated slides include prompts for the breakout room discussion. Each group needs a presenter to share key takeaways from the small group discussion with the whole group.

Producers: Send groups of 3-4 participants to breakout rooms for seven minutes. Then bring participants back to the main room.

Circulate: Circulate the breakout rooms and provide support as needed.

(4 minutes) Whole Group Share Out

Participants return to the main room and a presenter from each small group shares key takeaways from the small group discussion about one CS teaching practice. Encourage participants to read other group’s slides.