Day 1
01 Opener 02 Model 03 Break 04 Debugging 05 Equity 06 Lunch 07 Resources 08 Planning 09 Break 10 Barriers 11 End

Session 4: Debugging

30 minutes

lesson exploration

Purpose

The purpose of this session is for participants to build empathy with the student experience when debugging and explore strategies to implement the debugging process in their classrooms.

Objectives

  • Participants will explain what debugging is.
  • Participants will identify steps of a debugging process to use with all students.
  • Participants will identify how the debugging process supports inclusion in CS.

Supplies & Prep

Room Setup:

  • None from intial setup

Facilitator Supplies:

Teacher Materials:

Agenda

What is Debugging? (21 minutes)

Debugging Debrief (9 minutes)

Facilitation Guide

What is Debugging? (21 minutes)

(1 minute) Overview and Context

Facilitator Note: This session includes a modified version of Lesson 4: Debugging in Maze from Course C 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 "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.

Remarks

We can think of debugging as both a process and a skill. Debugging is essential in CS and builds on the following student practices found on page 27 of the Curriculum Guide:

  • Problem Solving
  • Persistence
  • Creativity
  • Collaboration

  • Communication

    We are going to engage with debugging through role play, just like we did during the “Model Lessons” session. I will have my “teacher hat” on and you will have the “learner hat” on. Again, as you engage in debugging keep your students in mind and consider role playing as your students. Remember to either reframe a question to be something a student might ask or write it down to come back to at the end of the lesson. After the role play, we will have time to discuss and reflect on debugging as a process to use with all of our students. The debugging lesson introduces a CS teaching strategy built-in to the learning platform called pair programming.

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.
  • The debugging lesson introduces pair programming which is a CS strategy built-in to the learning platform for students to engage in.
    • Remind participants to join the class section, if they have not, in order to use pair programming during the debugging lesson.

(20 minutes) Debugging Lesson

Warm Up (5 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)

Remarks

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.

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

    • (5 minutes) Have participants work as pairs on Course C, Lesson 4: Levels 2 and 3.

      • Circulate between pairs and tell them it is okay if they feel frustrated and encourage them to ask others for help.

Check-In (2 minutes)

After five minutes of participants working on Levels 2 and 3, pause participants, and tell them it’s okay if they didn’t complete both levels. Check-in with participants as they respond to the prompts below.

Remarks

Say: Let’s check-in.

  • Have a couple of participants share their responses.
    • How are you persistent as you work with the code?
    • How are you feeling when you are persistent with the code?

After responding to the check-in prompts, participants go back to working for another five minutes (ten minutes total of work time).

Wrap Up (3 minutes)

Participants respond to the following 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 (9 minutes)

(3 minutes) Pair Programming

Facilitator Tip

The intent is to introduce participants to pair programming and provide them with resources to set up pair programming after the workshop. Encourage participants to add questions about pair programming to the Question Parking Lot and share when these questions will be addressed during the next break or at the end of the workshop.

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:

(6 minutes) Debugging Process

  • (2 minutes) Partner Talk

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

  • Participants work with their pair programming partner and respond to the following prompts:

    • Prompts:
      • How did your approach to debugging during the lesson compare to the Debugging Process Guide?
      • How might you modify the debugging process shown in the guide to meet the needs of your students?

  • (4 minutes) Whole Group Share Out

    • Invite participants to briefly share responses to the prompt.

Discussion Goal

This is another opportunity to support participants in identifying ways for inclusion to be a part of their CS classroom culture. Participants will discuss inclusion again during the Focus on Equity session.

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 supports discussing multiple perspectives and solutions to help students learn from each other (including the teacher) when finding ways to debug or fix code.