Allowing Room for Failure: The Benefit of Providing Master Code Files

If you’ve followed any of my earlier posts, you may have seen a link to a giant 100+ slide Google Slides on teaching Arduino. If you are crazy and took the time to read through all of it (first off, give me some dang feedback ya selfish jerks!) then you may have noticed that I put the code files at the beginning of each new section. I’ve gotten a few questions about that, and I’d like to address that.

Encouraging Creative Confidence

My course is all about encouraging creative confidence and fostering confidence to try new things and completely suck at them.

Photo Credit.

My man Jake The Dog couldn’t have said it any better - Adventure Time is full of life lessons, (and cool wizard biz), check it out. But seriously, let’s pause and think about this.

There has been a huge buzzword around Failure lately. Many schools are using this in their marketing and their admission events. This is similar to “Growth Mindset” which I even wrote a blog post about. But I wanted to do a shorter article about how we can actually encourage failure instead of just talking about it.

Student Life and Teambuilding

First, let’s all empathize a bit with the schedule of a student nowadays. (I was originally going to post a screenshot of my Google search for “Students overscheduled.” But then I came across this gem.

Photo Credit.

Wow. Much speed. Such message. But it brings up a good point, students now are wildly overscheduled and rarely have free time for hobbies and creative pursuits. Many are getting home late, staying up late, and getting up early.

What does this mean for us, as educators, though? It means that when we ask students to engage in creative ideas and wild fun, sometimes that sounds like a chore or a bore to them. Or even worse, becomes overly stressful.

I want you to picture the following: teambuilding.

If this image fills you with dread, you’re not alone. Photo Credit.

Teambuilding activities can be great! But I often inwardly groan when I go to a conference and the first twenty minutes is spent on teambuilding and “Hi my name is ______ and 2 truths and a lie about me are…..”

Let me be clear. It’s not that these activities don’t have immense value, but we can tell when it’s forced on us instead of adding true value. And sometimes we’re just trying to get it over with.

Our students can tell too.

That quote “Dance like nobody’s watching” is great! But if we were to apply this ideology to the idea of failure in school, the quote would more likely be “Dance like nobody’s watching, but you will receive a score that helps decide the future of your dance career.”

That’s not really conducive to bad dancing and living in the moment.

Failing Forward

In case you haven’t already heard this, a lot of students have gotten really good at the idea of school. Sure, they’re not all great test takers, but they like knowing what to expect from school. Go to class, listen, follow instructions, take test, rinse and repeat - is easy to follow, and when school isn’t your favorite, it is a great way to float through until the end of the day when you can do things you are more interested in.

So let’s empathize with our students and give them ways to “fail” while still maintaining a grade they are proud of. Although there are many steps that need to be taken to create this culture in a classroom, the thing I most often hear from CS teachers is, “My students don’t mind/generally enjoy coding, until they have to troubleshoot!”

Let’s run through this scenario. Student starts writing code to learn for loops or how to multiplex LEDs or how to run an LCD screen, etc. Student runs into errors. Student starts searching for these errors but, this being new code, is not truly confident about most of their code.

This scenario has two outcomes. Either the student finds these errors and fixes them, or they don’t, and their program never works. Obviously there is more learning in the first outcome. But is there not still a lot of learning involved in the second outcome? Yet, at the end of class, the student in the second scenario might not have any way of showing their learning, and might not be able to vocalize what they’ve learned.

However, there is another way.

Image this version: students do a code along together with an instructor or tutorial, and then are asked to go above and beyond with a prompt. I’ve done this plenty of times with instructions such as the following -

• “Okay, now I want you to start playing with the delay times to make it blink three times a second.”
• “We’ve done 2 LEDs, but what about adding a third? Try it!”
• “We know how to control an RGB LED, but what if I wanted the color to be purple?”
• “We just learned for loops to light 8 LEDs at once. Now, try to light them with a tiny bit of delay in between each”

And the list goes on.

We’re asking our students to take a guess and try some code. But often, their code doesn’t work on the first go. And unless they’re using the Scientific Method to keep track of every variable or line of code they change, they tend to change more than one thing when they get errors.

Yes, we should teach proper troubleshooting.

Yes, we should teach event logging.

No, that doesn’t guarantee somebody won’t still encounter problems.

So they end up breaking their own code and often can’t get back to a working version unless they saved it as a separate file before. Queue frustration, anxiety, and the cries of “Coding just isn’t my thing!”

Experimenting with a Safety Net

What if, instead, we gave them the correct code? And put it somewhere they can redownload it over and over so that as they mess up, they can always start over without having to spend thirty minutes doing so?

Here’s how I do it.

Each new lesson starts with the blue background and the title. The third “slide” is where I give them new code and then explain the code instead of explaining all of it and then providing the code.

If you were expecting some elaborate shining light of truth, sorry to disappoint. It’s nothing fancy, but I give them the master code files through Google Drive (just let them view not edit!) and that way they can always pull it whenever they get stuck.

I can hear some coding purists crying out now. If you’re worried that this doesn’t teach them to troubleshoot - well…..

Oh Futurama, how I miss thee. Photo credit.

You’re right, this doesn’t teach them to troubleshoot in a formal way. And yes, that is the best way to learn.

But again, I’ll point you to the beginning of this post where I discuss building creative confidence in students. And the first step to that is creating a culture in the classroom where students feel safe to tinker/experiment/play. Asking students to sit through a lecture, then apply what they’ve heard without any safety net doesn’t build that culture. It just builds frustration.

To solve the troubleshooting problem, I’ll point you to the last slide of each sketch.

Giving them challenges to complete forces them to troubleshoot

Alternatively, you can also give them master code files that are wrong and ask them to spot the errors! I often do this as a warm up for the next class - reinforcing the lessons from last class. Boom, double header!

How do you encourage failure in your classroom or among your faculty? What are some challenges you face? Get at me in the comments or on twitter @rellidenahs.

Stay awesome!