If you have any personal anecdotes fixing bugs, share them. You may also have students share the most difficult bugs they've encountered so far and how they've resolved them. One of the objectives of this activity is to emphasize the inherent value in the daily process of resolving issues.
As a developer, you WILL be working with unfamiliar codebases that someone else wrote. Being able to navigate and fix small-ticket bugs in such codebases will likely be one of your first tasks as a junior developer.
-
What are some strategies you've employed to debug an error or unexpected behavior?
Also see Review Questions at the bottom of this module
Student Instructions
google doc Please make COPY
Review Slides (Optional)
google doc - Please make COPY
- Alone - Write down or answer opening questions in chat or DM
- Class discussion
- Pairs or groups
Roles:
- Note taker
- Time keeper
- Researcher
- Group Rep
- Driver (pairs)
- Navigator (pairs)
-
Intro (<5 min):
- Discussion: Discuss debugging. See "hook" and "the why" for topic suggestions.
- Activity Set up: Run the fixed version of the Flasketball code and show students the working features in your browser, walking through how the features should behave. Allow time for any questions.
- Roles: Be sure students understand that at least one person will need to take notes on the bug and how they solved it to post in discord (or wherever medium makes sense for your class).
- Expectations: Review the student directions hand-out with everyone
-
BREAKOUT GROUPS (~15-20 min):
- Students do not have to finish all the challenges, but you may want to go longer to let them finish if it's going well.
- Rotate, check on and help groups.
-
Presentations (~10 min):
- Have groups present / share their docs.
- Review Options:
- Review errors with the slides
- Go through the broken version of the code with the class' help or calling on an individual student to 'drive' (shared screen and typing) as the class navigates or navigate as you, the instructor 'drives'
-
Reflection:
- Do you develop incrementally? If you build and test one feature at a time, or only debug one error at a time, it is much easier to localize a problem.
- How do you test your assumptions? Use print statements or a debugger!
- If you have a hunch, what are the assumptions you are making? For example, is the value of that variable what you think it is? Is it even running that function right now? How do you know? Assert or test your assumptions before changing any code.
- How do you find what code to look for? (Reading the entire error message, backtracking and stepping through the code from where the error occurred, using print statements to confirm where the execution got to at each step.
References: Cornell Debugging Techniques
-
Self-Assessment: What did you learn? (See 'How Will Students Know They Were Successful')
- Come away with a written list of encountered errors and the solution used
- Can articulate at least one strategy they found helpful and will use going forward