I've spent far more programming hours pair-programming than working alone. It works for me. This fall I decided I wanted to learn Cocoa, so I called up Pivotal

I've spent far more programming hours pair-programming than working alone. It works for me. This fall I decided I wanted to learn Cocoa, so I called up Pivotal Labs and asked if they had any iOS projects I could work on. They paired me with someone who had been working with Cocoa for a year. On day one I was adding value. Within two weeks I was proficient, and within a month I was working as fast or faster than other developers at Pivotal. I wouldn't have been able to do it alone. Pairing is the fastest way to ramp up in a new language, ecosystem, or codebase. And beyond just ramping up, it continues to teach you long after you reach mastery, because you're constantly exposed to new perspectives and ideas. Pairing is also good for the team... by rotating pairs frequently, you distribute knowledge through the team. It's like a RAID array for your codebase. People talk about the cost of being interrupted. But what about the cost of having to read through someone's solo-written code when they're home sick and not understanding it? When your team is pairing, you can interrupt one person while the other person keeps coding, maintaining the focus for the pair. If you have a question, ask it. If the team needs to know something, tell them. Working alone is good, too. I enjoy rocking out with my headphones or working quickly from a gut level understanding and not having to articulate it to a pair in words. But often I find that my solo code improves when I expose it to feedback from a pair. Not a slow asynchronous code review, but a real time back and forth conversation. For me, software is a social activity. Deadly silent offices give me the creeps.