I'm really good at thinking about problems, since thinking in general is a big part of my day-to-day job. In fact, I've gotten so proficient at thinking about problems that over thinking them is a real, pervasive issue for me; I can easily miss something that's quite obvious to the next person. My son hasn't quite reached that level, and his insight into solving a video game puzzle reminded me that more eyes on the problem is what often reveals the answer.

A happy small child uses a laptop, with the caption "Silly Daddy, the code goes like this"

I've recently been playing The Legend of Zelda: Skyward Sword, a single-player action/adventure game (for those of you who don't play video games, it stars a green-garbed mute hero called Link and generally features swords, magic, and fairies). My son practically begged to play the game with me, which I wasn't necessarily in favor of since it is a lot more mature than other games he's played. It took a bit of work on his part, but eventually I was convinced, and now we "play" it together, with me reading the dialogue aloud so he can follow along with the story. It's been a surprisingly nice way to teach him about storytelling and logic, since the game involves a number of puzzles that you have to solve in order to move the story along.

One of these puzzles was stumping me. I needed to defeat two enemies; giant hands made of lava. They lurked in a sunken arena, which I had to pass through in order to continue. Each time I tried to fight them, though, none of my tools would be effective; the sword, the bow, the bombs, none of it made any impact on them. I started trying more complex solutions: run around them until they get tired (they fried me), make them run into a wall (they flattened me), play them a lullaby on a harp so they'd go to sleep (hey, I was desperate). None of it made a damn bit of difference.

My son, however, realized something: the hands were made of lava, which (he reasoned) is like fire, which can be put out by water. So he asked me, "Can you try throwing water at them?"

Oh, duh! I thought. Sure enough, a bottle full of water was all it took to make the lava hands disintegrate. He'd discovered the solution to a problem that had been bothering me for a while, something that I'd totally missed.

I found that having his eyes on the game while we were playing helped immensely. To be fair, sometimes his suggestions were way off the mark ("Maybe you can carry that rhino in a bottle?") but often his ideas were what allowed us to continue adventuring. Having more than one set of eyes made the game easier and more fun for everyone involved.

What really drove this home for me was that earlier that week I'd asked a coworker (we'll call her Stacy) to come examine my code to help me find a bug, for the sole reason that no one else was in the office that early. She and I aren't part of the same development group, but I desperately needed another set of eyes. I'd been struggling with this particular issue for much of the previous day, and had spent hours running in circles trying to attack the problem with new and increasingly desperate methods, each more convoluted than the last. Finally, I asked Stacy to come take a look at what I'd done and see if she could find what I was missing.

Five minutes later, she knew what the issue was. It was something I'd completely missed, something I should have considered but failed to. All it took to find that solution was the involvement of a new person, one who hadn't been exposed to this code and therefore harbored no assumptions about how it should or should not behave.

Many hands make light work, even if those hands are tiny. Programming is so often a solitary endeavor; we sit up in our ivory towers, write code, then give it to someone else to review it, implement it, etc. I'm seeing more and more that having other humans look at my code while I'm working on it yields more meaningful improvement than I had imagined. Working in pairs (accurately termed "Pair Programming") seems to help uncover issues earlier, before they become actual problems.

What I'm saying is this: don't forget to have someone else look at what you are doing once in a while, even if that other person is a five-year-old. Even if we can't do full-blown pair programming, we can at least have someone sanity-check our code when we're having difficulty solving a particular problem. Many times the other person, with fresh eyes, will see that problem in a new light that reveals some hidden (or not-so-hidden) clue to the solution we've been searching for. We might start out trying to carry a rhino in a bottle, but eventually, we'll end up finding the water we need to put out the fires we've been fighting.