Learning Computing through Failure�Debugging and the Growth Mindset
Naace Conference 2015 | #naace2015�Miles Berry | @mberry
These slides: bit.ly/naacedebug
Some thoughts on failure
Are you failing better?
Ever tried.
Ever failed.
No matter.
Try again.
Fail again.
Fail better.
Beckett, 1983
Edison
Cello
Angry birds
Choosing what’s hard
We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills...
Kennedy, 1962
The teacher’s job?
A teacher’s job is not to make work easy. It is to make it difficult. If you are not challenged, you do not make mistakes. If you do not make mistakes, feedback is useless.
Desirable difficulties
Conditions of practice that appear optimal during instruction can fail to support long-term retention and transfer of knowledge and, remarkably, conditions that introduce difficulties for the learner—and appear to slow the rate of the learning—can enhance long-term retention and transfer
Growth mindset
While people with a fixed mindset see mistakes as a dismal failure — a sign that we aren’t talented enough for the task in question — those with a growth mindset see mistakes as an essential precursor of knowledge, the engine of education.
Computer cultures
Children are held back in their learning because they have a model of learning in which you have either ‘got it’ or ‘got it wrong’... The question to ask about the program is not whether it is right or wrong, but if it is fixable… Thinking about learning by analogy with developing a program is a powerful and accessible way to get started on becoming more articulate about one’s debugging strategies and more deliberate about improving them.
Papert, 1980
Debugging
Problem solving
The key skill of problem solving involves pupils developing the skills and strategies that will help them to solve the problems they face in learning and in life. Problem solving includes the skills of identifying and understanding a problem, planning ways to solve a problem, monitoring progress in tackling a problem and reviewing solutions to problems. All subjects provide pupils with opportunities to respond to the challenge of problems and to plan, test, modify and review the progress needed to achieve particular outcomes.
DfES/QCA 1999
Debugging in the national curriculum
KS1: create and debug simple programs
KS2: design, write and debug programs that accomplish specific goals�use logical reasoning to explain how some simple algorithms work and to detect and correct errors in algorithms and programs
Troubleshooting
Troubleshooting is among the most commonly experienced kinds of problem solving in the professional world… the problems that are most completely and accurately recalled are those that are most difficult to solve, because the problems solver was more conceptually engaged in the process.
Jonassen, 2004
Teaching debugging
Rubber ducks
Wolf fences
CC by Yellowstone National Park
The Barefoot Approach
Elementary
When you have eliminated the impossible, whatever remains, however improbable, must be the truth?
Conan-Doyle, 1890
Sabotage
I explain to the class that they are going to deliberately sabotage their partner’s working code by hiding five errors in there – no more, no less. I suggest that one error should be pretty obvious and one should be very sneaky: using the character 0 instead of the letter O, for example.
Pragmatic programming
Stay aware of what you're doing.
Don't code blindfolded.
Proceed from a plan.
Rely only on reliable things.
Document your assumptions.
Test assumptions as well as code.
Prioritize your effort
Don't be a slave to history.
Is there an easier way?
Am I solving the right problem?
Why is this a problem?
What makes it hard?
Do I have to do it this way?
Does it have to be done at all?
Avoiding learned helplessness
Is this an issue?
This takes time to solve
A positive attitude to problem solving
I’m not here to fix your code
Point out when they do it
Step away from the keyboard
The computer is not out to get you*
Team effort
Some exercises....
Recipe bugs
Ingredients:
175g castor sugar
175g plain flour
175g stork margarine/soft butter
2 tbsp vanilla extract
2 tbsp milk
3 eggs at room temperature
Method:
Mix all the ingredients together using the flat beater until light and creamy – takes about 4 minutes and should look like whipped double cream when done. Pour into two greased and lined round tins and bake in a preheated oven at 280C for 20 – 25 minutes until well risen and golden brown. A toothpick should come out of the centre clean when done. Cool on a wire rack and remove from the tins once you’re able to stand the heat
Recipe bugs
Ingredients:
175g castor sugar
175g self raising flour
175g stork margarine/soft butter
2 tbsp vanilla extract
2 tbsp milk
3 eggs at room temperature
1 tsp baking powder
Method:
Mix all the ingredients together using the flat beater until light and creamy – takes about 4 minutes and should look like whipped double cream when done. Pour into two greased and lined round tins and bake in a preheated oven at 180C for 20 – 25 minutes until well risen and golden brown. A toothpick should come out of the centre clean when done. Cool on a wire rack and remove from the tins once you’re able to stand the heat
Logic bugs
import random
a = random.randint(1,12)
b = random.randint(1,12)
for i in range(10):
question = "What is "+str(a)+" x "+str(b)+"? "
answer = int(input(question))
if answer == a*b:
print("Well done!")
else:
print("No.")
More logic bugs
cs
repeat 3 [
fd 150
rt 60
]
Multithreading
Performance
from turtle import *
for i in range(1000):
forward(0.5)
right(0.36)
Arithmetic
Resource
Resource
Syntax
Syntax
import Random
for i in range(l0):
a = random.randint(1,12)
b = random.randint(1,12)
question = "What is "+a+" x "+b+"? "
answer = input(question)
if answer == a*b
print (Well done!)
else:
print("No.")
From coding to software engineering
Test driven development
Iterative development
It sounds like a shampoo commercial, but the best advice I can give my students—and aspiring programmers everywhere—is this:
Code a little, test a little, repeat.
Build your app one piece at a time, testing as you go. Soon enough, even this process will become surprisingly satisfying, because you’ll see results sooner (and have fewer big, nasty bugs) when you follow it.
Given enough eyeballs, �all bugs are shallow
Questions?
@mberry
m.berry@roehampton.ac.uk
milesberry.net
These slides: bit.ly/naacedebug