Show What You Know: Reviewing and Applying Knowledge with Debugging Activities

The following blog outlines my experiences in delivering workshops this summer on Teaching Computer Science.

Toni and I led a number of 4-day Teaching Computer Science with TI-Nspire Technology workshops across the state of Texas this summer.

Many of the sites offered days 1 and 2 consecutively, followed by days 3 and 4 at a later date.

Sometimes day 3 of the PD happened months after day 2. In these instances, how might we structure an activity that helps participant review key computer science ideas from previous learning episodes, while also applying these ideas in new situations? One strategy that we found particularly helpful in this situation was a set of debugging activities.

Side note #1: The first two days of learning delved into most of the topics from the first four units of the 10 Minutes of Code activities, including user input (via parameters or Request statements), output (Disp, Text), variables, data types, conditionals (If, If…Else), and loops (For, While, and DoWhile).

Additionally, we applied many of these same concepts to tasks with the Innovator through the first two units of the 10 Minutes of Code for the TI-Innovator Hub activities.

 

Side note #2: Our use of debugging activities was inspired by the work of Amin Lalani & Georgia Stuart at UT Dallas.

 

We started Day 3 with a Debugging Problems TNS file. The file was composed of 10 Problems. Each Problem contains a Program Editor page, like this one:

with a corresponding Calculator page, like this one, on which to run/execute the program:

Each program (named debug_1, debug_2, etc.) contained at least one error. Participants worked in pairs to debug/fix each program. In so doing, participants reviewed, applied, and discussed:

• How to compile a program in the Program Editor (using Check Syntax & Store)
• How to run/execute a program in a Calculator page (including the use of the var button to summon program names)
• Syntax for the TI-Nspire programming language
• Variable naming conventions
• Data type considerations (including concatenation)
• Control structures, including conditional statements and loops
• Logic and conditional statements
• User input mechanisms (including parameters and Request statements)
• Error types (including compilation errors & execution errors) and error messages
• …and more!

Some of the programs involved minor errors. For example, the debug_1program shown above—participants determined that the string in the Dispstatement should have been in double quotes (“) and not single quotes (‘). Here’s a quick GIF of troubleshooting this program:

Here are two other programs from the TNS file. What errors do you see? How might we debug these programs? What important CS topics connect to these errors and/or fixes?

It was incredibly valuable for participants to troubleshoot and debug these programs dynamically on the handheld calculators.

They could fix errors as they found them and then compile and execute the edited program right away to test their “fixes”.

On numerous occasions participants fixed one or more parts of the program, but then discovered another error when they ran the edited program.

Our brains often “fix the code for us,” helping us read the intention of the code, but perhaps missing some of the subtle errors specific to the coding language. This activity helped us review and apply programming skills specific to the TI-Nspire language, while also discussing larger computer science topics and content applicable across languages.

Additionally, we experienced the cognitive difference between writing a program from scratch and debugging an already written program. It feels different to debug–to find and correct errors in already written code–than to “code from scratch”; there was important learning to be had in this space.

Give it a try yourself! Here’s a copy of the TNS file with all 10 debugging programs in it. Each program does not necessarily have a unique solution—there may well be more than one way to “fix” the program so that it runs as intended, but with different code structures under the hood.

Also, Toni and I wonder…what would similar debugging programs look like that included TI-Innovator commands/components? What sort of errors would be helpful for learners to confront, discuss, and debug in regards to Innovator programs?

Here are some rough draft ideas for possible Innovator debug programs:

 

What other programs and/or lines of code might be valuable to include in a set of TI-Innovator debugging problems?

 

What other value do these debugging activities bring to the learning experience?

Please follow and like us: