Why We Teach To Fail

Twenty minutes into our “Choose Your Own Adventure: Introduction to HTML” class, we ask the room full of young people and their family to choose their favorite number.

“Two!” says the first student to raise their hand.

“Alright, two!” says Ali, who is teaching the class today. “Nobody else can choose two as their favorite number!”

Each student who raises their hand chooses a different number: four, twenty five, eighty seven, one thousand two hundred, and seventy six.

“Now, everyone enter less than symbol then the letter ‘h’. Then your favorite number, followed by the greater than symbol. See what happens!” An adult mentor demonstrates on a computer screen projected at the front of the room.

Before choosing their favorite number, the students had just written a simple sentence using the h1 heading code, something like:

<h1>Where do you want to go today?</h1>

This made the sentence bigger than the other text on the page — everyone in the class got the same result unless they had made an error in their code.

But after Ali had each student pick their favorite number to enter after the header tag, something very different happened.

Readers who are HTML pros can see where this exercise is going. HTML headers (written in HTML as <h#>), are only functional up to the number six. Nothing happened for the students that entered a number above six in the <h#> bracket. For the students who picked a number under seven, such as four in the example below, the website changed based on the headline they used.

<h4>Where do you want to go today?</h4>

The sentence of the student who picked four as their favorite number had their sentence get a little smaller than it was before.

By asking students to use their favorite number for this exercise, we changed the dynamic of the classroom. The success of the students’ code was entirely based on which number they picked, regardless of how well they had done in the class so far. Suddenly, students who previously had been struggling were excited to see that their code was doing something, while the code of students who had a relatively easy time in the class so far was not working.

This exercise inspired confidence in the students who were struggling before, and inspired students who were blazing though to think deeply about what was going on. In short: this exercise changed failure from something to dread, to just part of the process when learning something new.

When we teach students to code, we want to get them comfortable with failure. As developers, when our code doesn’t work the way we expect to, we know that there is something in our code that we’re overlooking — not that we are “not smart,” are “bad with computers,” or “just don’t get it.” At CoderDojoChi, we see having a problem solving approach to programming, and to learning in general, as a fundamental part of the skills that we’re teaching our students.

During the exercise, at one table, a student without access to a computer at home struggled with getting the correct syntax on her previous lines of code. After picking her favorite number, three, she saw her code get a little smaller. Her mother, brother, and sister, who all had favorite numbers above 7, were surprised.

“How did you get it to work?” asks her mother, mystified.

The student didn’t say anything, she just giggled.

Later, when she struggled with other parts of the class that didn’t come easily to her, she continued to work through the process slowly but surely, no longer concerned about whether or not others in the class are making progress faster.

“I really like coding,” she told one of the mentors afterwards. “I want to build another adventure game.”

When we teach students to fail, we teach them to be comfortable with the unknown: a framework that is useful not just when learning to code, but in every aspect of life.