Making mistakes safely

Pop. Sizzle. Spark. The unmistakable smell of burning electrical parts. “Shoot shoot damnit!” I say, doing the best I can to keep my voice down and not swear while the DJ is on the mic. I unplug the ethernet jack but it’s too late. The cable tester, a handheld device that tells you what conductors in an ethernet cable are connected, was fried. LED number 4 had exploded from being connected to line voltage, mocking my attempts to deny what just happened.

In hindsight, it was obvious the line from the air studio through the ceiling to the control room hadn’t failed, but it was part of a system that wasn’t working. We try to be classier than playing YouTube on-air, but we give DJs the option of playing the audio output of the studio computer’s web browser. According to the computer’s meters, it was outputting audio, but according to the equipment it plugged in to in the control room, it was not. So the problem had to be between the computer’s digital audio jack and the equipment in the control room, connected mostly by ethernet cables. Right?

“It was a perfectly reasonable thing to do,” my friend consoled me. He was a fellow computer science major but with less experience with how the station was wired, and I was hoping to show him how the cable tester worked. Those ethernet lines were a mystery, and I was hoping to get a better look inside. (Which I suppose I got – that line was definitely connected!) But I later realized what had gone wrong was that, on a fundamental level, I was a computer scientist trying to solve an electrical engineer’s problem.

Computer scientists like the break big problems down into little problems. We like to understand those little problems as a series of things that happen in sequence: first this line then that one. When something goes wrong, the crudest form of “debugging” is to pepper the code with output commands. We got here and the value is this. Do this with enough granularity and you’ll pinpoint exactly where something isn’t as you expect it to be.

This is very much the methodology I brought to the nonworking web browser output. I found the earliest and latest places something could go wrong and then honed in. The problem is that while output statements in code are free, electrified wires tend to break things. This sort of danger is completely alien to a computer scientist, or at least those of my generation. Yes, it used to be you had to wait hours for your code to compile and if you weren’t careful you could overwrite the OS, but those days are over. The focus now is on trying anything, seeing if it works, and improving it in a tight feedback loop if it does not. Drill down and get data, instead of careful planning and reasoning. That’s not necessarily the best way to work, but it’s viable when you’re dealing with unfamiliar code that isn’t too complex.

In this light, two computer scientists connecting a tester meant for very low voltages to a live wire is a perfectly reasonable thing to do.

I guess this is the part where I lament that even closely-related disciplines have widely varying problem solving techniques, and how a field’s techniques arise from its content, and how you should find a field that thinks the way you do. But no. I think more subjects should work like computer science. Starting with math.

Math, as currently taught, shares key similarities with electrical wiring: there are rules you shouldn’t break, but no feedback until you break them, at which point you can’t recover. Yes, those rules are in place for very good reasons, but they’re not always obvious. The feedback loop takes even longer: instead of immediately frying something, an elementary student may do a whole page of problems wrong with the same error, and only get the grade back until after the class has moved on to new material. What can be done to make math more like programming?

Quite a lot, as it turns out. Seymour Papert’s Mindstorms (after which the Lego robotics kit is named) describes a system of geometry that is fundamentally computational. Students create programs that guide a “turtle” moving on the plane that leaves lines behind it. Forward 50. Right 90. Children can kinesthetically identify with the turtle; they can relate to moving in 2D space far better than abstract symbol manipulation. But more importantly it turns math into executable code: the turtle’s path can be seen immediately. Errors are no longer obscure and arbitrary but obvious and meaningful. With the fluidity of digital text and the real-time speed of computation, students quickly debug both their program and their understanding in a tight feedback loop.

As much as this would benefit math education, the meta aspects are even more intriguing. I remember educational games of the 1990s, which involved following chains of item exchanges. You’d find a magnet, which you’d use to retrieve a steel crankshaft, which would operate a piece of machinery, which would contribute to the plot. These sequences were often discovered by trial and error, and shared among classmates; the objective was to beat the game. As Papert observed 15 years prior, “the computer [is] programming the child.” But with the turtle, “the relationship is reversed: the child, even at preschool ages, is in control: the child programs the computer.” Instead of following a trail of breadcrumbs laid out by someone else, with the turtle the child is free to set  and follow his or her own agenda. No program (that is well-formed) is ever “wrong” but merely does something undesired.

Papert makes the argument, one I’m only too happy to agree with, that the programmer’s mindset of debugging and incremental improvement taught by the turtle are a superior way of learning and thinking in general. This mindset rewards sustained effort over initial brilliance, and provides children with confidence to overcome their failures and set things straight. Equally importantly, “in teaching the computer how to think, children embark on an exploration of how they themselves think … [which] turns the child into an epistemologist.” A more positive relationship with math leads to an embrace of knowledge in general.

But we can’t stay in Papert’s Mathland, “a place that is to math what France is to French.” We have to work in the real world, with unforgiving electrified cables and math too complex to be explored with turtles. Our best option is to come into this world as prepared as possible, and to recognize that when mistakes do happen, they may not be as terrible as we thought.

For the $40 cost of a new cable tester, I think this lesson is well worth it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: