- January 23, 2014
Switch Programming
There are countless sayings about fresh perspective: “A little distance will give you a whole new perspective,” “You need to step away for a while,” etc. Unfortunately, we live in a culture where that’s not always possible—or practical. I have a very hard time getting up and walking away from my computer when I’m in the middle of a problem. My mind wants to sit and work right through it, no matter how long it takes.
Luckily, I work at a company that encourages collaborative problem solving. Someone always walks by my desk, hears my mutter, and asks me what’s up. Typically, explaining the issue is enough to help solve it (or at least put me on the correct track).
When that’s not enough, I’ll typically seek out a coworker for help. My request alone could take them right out of their zone. And, if they’re able to assist, they end up spending a bit of their day not how they had originally planned.
Switch Programming
Recently, Anthony Colangelo and I experimented with a way to keep everyone focused, even when we’re stuck. He calls it switch programming: “[Give] each other 30 seconds to explain [your] intended results, and nothing else. Then, [trade] computers and [get] to work,” Anthony explains. The gist is that if we switch problems for a short amount of time, we can get a fresh perspective on our own issues and lend a hand to others.
Anthony outlines several benefits of running a switch programming experiment. One, in particular, resonates with me. Switch programming gamifies peer code reviews and injects it into our process. In order to work effectively, our developers need to be writing interchangeable code—code that anyone can understand just by opening a file and reading top to bottom. Introducing switch programming into my development process has led me to write better documentation, think more about my method names, and ensure variables are clear and concise. My code is a book that someone else will read, not a personal journal that only I can access.