Archive for November, 2013
This is a rant. I’m irritated.
I’m not a social creature. I don’t want to spend all day, a significant portion of my day, or even a small portion of my day sitting next to another programmer writing code – even if my productivity could be measurably improved by it. It’s just not the type of life I want. It would ruin the quality of my life and my work environment. I, like most left-brained people, am an introvert and can’t comfortably tolerate that much company or social interaction. I find it VERY draining and aggravating. I prefer to think and work quietly and alone. I’m very productive this way. I’d say I’m extremely productive this way. I believe that I’m most effective this way. Most importantly, I’m happiest this way and not much in life is more important than happiness. I could do an experiment in pair programming to find out if I’m actually most productive working alone, but I won’t because I just don’t care. If I wanted to spend my whole day sitting next to one or more other people being social then I would have gone into PR or sales or something similar.
I know there are perceived benefits to pair programming. I know some believe it can help junior programmers advance more quickly. I know some believe it can help reduce bugs. I know some believe it can help create cohesion among team members. Etcetera, etcetera, etcetera… I know there are studies that profess to prove this. I’ve read some and they appeared biased to me. None of this applies to me. NONE. If I were forced into pair programming under the guise that I would be more productive (or whatever the buzzword of the day happened to be) then I would immediately find another job. If pair programming were the only practice in the software industry then I’d work alone in my own business. If programming could only ever be done in pairs then I’d be out. I’d find an engineering discipline that doesn’t unnecessarily stress me with social interaction and interruptions. (Frequent interruption is fundamental tenet of pair programming. How anyone can reach peak productivity or enter or stay in the zone for very long under pair programming conditions is beyond me.)
Pair programming is not compatible with my personality and I’m a very accomplished highly skilled software engineer. I know because my mom told me. 😉 The fact that I’m very accomplished and skilled proves that pair programming is not necessary. Pair programming is absolutely not necessary to increase developer productivity or produce the very best product. It would have the opposite effect with me.
I don’t believe that I’m alone in my opinion. All of my colleagues are very similar. In my 20+ year long career, I’ve only known one person that I suspect would be comfortable with pair programming and that person is more extroverted than introverted, and honestly wasn’t a particularly good software developer. Not terrible, but not all that good – mediocre. My point is that I’m confident that I’m not alone in my opinion about and attitude towards pair programming. Not by a long shot. I believe that the strong producers and leaders in the software industry feel the same. The mediocre “cogs” (9-5ers that just want a paycheck) outnumber us and I suspect 40% or less of them might benefit from pair programming, which I suspect is where all the buzz about pair programming comes from. Well, that and the extroverted management personnel tasked with running software teams populated with introverted minds (note: non-software developers should generally not be managing software developers – it’s like combining fire and water).
So, if you’re one of those guys, please shut up already about pair programming. It’s an old tired mantra that I’m personally sick of hearing. Yeah, it might work for you. Yeah, it might work for your team. But you’re the minority – the very small squeaky obnoxiously loud minority. Do what works for you and respect others and let them do what works for them. I can’t remember the last time I heard or read someone shooting off about how bad pair programming is and how everyone really should apply themselves, focus, think hard, grok the problem, design a solution, implement it properly, and methodically test the result. We’re not jamming our philosophy down your throat and getting all in your face about how “awesome” or “revolutionary” it is. We’re simply being productive and minding our own business. If you believe that evangelizing a particular programming methodology is important enough to do it instead of the development itself then you probably are someone that needs pair programming to be productive and effective. Be a better programmer. Practice your craft more; talk less.