I clearly remember my first day at EdgeCase, over four years ago. I was new to Ruby, Rails, Vim, Agile, and -- more than anything -- pair programming. It was one of the most painful working days of my career. I was convinced I'd made a terrible decision. I was completely overwhelmed, my confidence was shot, and I dreaded coming in on day two. Of course it got much better. Over time I gained experience and confidence with Ruby, Rails, and Vim. I got comfortable with the continually evolving agile project flow at EdgeCase. Obviously, I fell in love with EdgeCase and the team I was a part of. But I never got used to pairing.
It's been a constant fight, really. For a while it seemed sacrilege to talk negatively about pair programming. Pairing was the Right Way, and if I felt differently, I must be doing it wrong. In some circles I still think that's the popular mindset, but thankfully at EdgeCase we're much less dogmatic. I'm able to speak my mind, and ultimately it's up to my immediate project team to decide for ourselves when and how often we want to pair.
Still, I've had trouble articulating why pair programming doesn't resonate with me. I often wonder if it's because I'm an OCD control freak who can't stand making compromises and concessions in my code. I can acknowledge that it certainly plays a role, but the thing is, I love getting feedback on my code, even if it gets torn apart. I love learning from that feedback, and I love a sense of shared code ownership. I really do want a peer reviewing every line of code that I write, I just want to write it without him watching me type.
So today's reason why I dislike pair programming -- as you've guessed by the title of this post -- is that pair programming is Design By Committee at the smallest scale. Software written by a committee (a.k.a pair) rather than an individual will be less innovative and less interesting. The result of every decision being a joint decision is that every decision is bland and predictable. For me that's very demotivating.
One thing I can say about pairing is that it's more consistent. A pair of developers will churn out code at a more constant rate than an individual. Not necessarily faster, but more consistent. An individual such as myself is going to swing wildly back and forth, such that at times I can do in two hours what at other times might take me two days. If I'm working with a pair my drive and productivity will be throttled. More consistent, but less capable of getting in the zone and doing something extraordinary.
The irony of this post is that today I worked solo and hardly got anything done. I was journaling tonight and wondered if I should've grabbed a pair. Certainly if I'd paired up with another developer I would have gotten more accomplished today -- at least on the surface. But how much would I really have contributed to it, and how much would I have held another developer back? I was distracted today. I had other things on my mind. It was just a flat out bad day. Shit happens. Pairing wouldn't have helped, it would've just masked the problem and dragged someone else down.
I don't want Design By Committee. I don't want someone else making me appear more productive than I actually am. Part of being human is having days when I just can't deliver. But when I'm ready to bring my A game, I want zero friction. I want no committee in my way. Maybe tomorrow will be one of those days.
Quite thought-provoking. I haven't paired as much as "shadowed" you when I had the pleasure of seeing you in action. Whether or not you'd call your work during that time extraordinary, it undoubtedly was for me. That said, do you think the code quality could depend as much on your pair? I'm sure there are moments of inspiration when you're pairing that you do do something outlandish and your pair can see its worth, and there's immediate feedback as opposed to just silently feeling good about it till something breaks?