Switch Programming

On a Thursday afternoon in Philadelphia, Mark Huot and I were sitting together working on different projects. We were both running into seemingly small issues, and becoming increasingly frustrated while debugging.

Sure, we could’ve just asked each other for help like we always do. We could’ve run through what we were working on, what was breaking, and what we had tried. But it’s good to change things up every once in a while, so we decided to try a little experiment.

We gave each other 30 seconds to explain our intended results, and nothing else. Then, we traded computers and got to work.

I was working on a fairly new project with a codebase that Mark really hadn’t been in, and Mark was working on an old project that I hadn’t touched for over a year and a half (long story). Point is, neither of us were intimately familiar with the project we were debugging. It didn't matter—we knew what had to happen, and we dug in.

Within five minutes, our issues were solved. We explained to each other what we did to fix the problems, we learned a little something, and we got back to work.

Fresh Eyes

Fresh eyes don’t see the rabbit holes you surely went down while debugging. They aren’t stuck on one particular piece of code that you’ve been thinking was the problem the whole time. They don’t have your bias.

They can step back, evaluate what’s happening, and (most of the time) solve the issue quickly. You might spend minutes or hours (or more…) running the problem through your head. You’ll mentally compile the project’s code or run through the entire stack more times than you can count. But fresh eyes only know what they see. They’ll catch little things you missed, and they’ll keep it simple. They don’t know enough about the project to complicate it.

If I were to talk Mark through the issue I was having and explain what I had been trying, I would’ve dragged him down those same rabbit holes I was already lost in. Instead, I just gave him my computer and let him run with it. He found his own rabbit holes, and they were the right ones to follow.

Sometimes it’s better to get your bias out of the picture and let fresh eyes work their magic.

Beyond Debugging

When Mark and I first talked about the idea of switch programming, we didn’t intend for it to be solely a debugging tactic. We talked about it as a way to keep the team up on all (or at least many) projects. We talked about making it a regular thing—on Fridays after lunch, trade computers and work for some amount of time.

This could even be a way to do code reviews—immerse someone new in the codebase and let them discover areas of improvement. I know I would learn a ton from being thrown into existing code that the people around me have been writing.

How much insight could you gain if someone that was previously not involved in the project jumped in and worked on a few things? They’ll point out things that, to you, seem straightforward as obtuse and overly complex. They’ll have helpful suggestions for improvement, and they’ll be excited about little bits of code you thought were bland when you wrote them.

It’s a little bit of a weird exercise, but it’ll help us all learn a little bit more each day. And, maybe surprisingly, it’s actually fun!