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.
Peniwize's Weblog 
#1 by Jorg on November 17, 2013 - 9:56 am
Absolutely agree with you, and I feel the same. Rest assure though that pair-programming is a quite rare beast nowadays that you will not encounter in the wild too often. It seemed that the whole idea peaked around 10 years ago when every Tom, Dick and Harry wanted to jump on the XP bandwagon and follow the mantra of Kent Beck. Luckily some Project Managers wisened up and decided that paying two people for doing the same task is not the way to go/
#2 by Gianluca Ciccarelli on November 17, 2013 - 11:12 am
I agree with you. The good point that I used to find about PP was the continuous code review that junior developers were exposed to (provided you have enough mid-to-seniors to actually have something to teach them); but what juniors (as well as seniors, actually) really need is indeed code reviews, not someone continuously talking over their shoulder like Long John Silver’s parrot. Anything more social is a developer’s waste of time.
People need time to interiorize mechanisms, which involves time on their own.
#3 by __m on November 17, 2013 - 11:47 am
Its purpose is to improve quality and in the long term productivity by finding bugs right at their creation. You are simply wrong if you think you make no errors.
#4 by peniwize on November 19, 2013 - 6:50 am
I made no such assertion. I make errors just like any other developer and I manage them efficiently without pair programming.
#5 by Chewsday on November 17, 2013 - 11:52 am
“I’m not a social creature. ”
So what’s with the blog? :p Looks pretty social to me. Maybe you just don’t like pair programming.
#6 by peniwize on November 19, 2013 - 6:55 am
You got me. 😀 But seriously, I’m not a very social person. I have friends and I socialize with them, but not to the same degree extroverts do. I don’t crave friendship or interaction with people. I keep a public blog mostly so that I can refer colleagues (and friends) to it to address issues that repeatedly arise. It saves time and reduces communication errors.
#7 by Stefan T. Kendall on November 17, 2013 - 1:09 pm
I’ve found that code review does better to catch bugs than pairing. Pairing in my experience improves quality and leads to better solutions, but it’s not required for all problems.
It doesn’t take a sales background to collaborate on a project. If one is this vehement about not pairing, I wonder if this bleeds into other communication.
Even when you’re not pairing, you need to talk to people.
#8 by peniwize on November 19, 2013 - 7:04 am
I don’t disagree and I made no comments about collaboration outside of pair programming. I’m strongly in favor of effective communication and collaboration and put significant effort into mentoring others and documenting my work (and theirs) including whitepapers, UML diagrams, notes, knowledge base (e.g. Confluence and Jira), and whatever else is necessary. However, I’m careful to balance the cost/value of the effort to avoid wasting time. Writing code is just one part of a complete software engineering effort.
#9 by engineer on November 17, 2013 - 2:25 pm
I agree with you for values of “pair programming” greater than 5-10 minutes. For extremely short periods, such as two people trying to figure out a bug, or looking over some tricky code, I don’t mind it. But that’s not really “pair programming”.
Every agile fanatic I’ve ever met, in 20 years of development, has been a terrible programmer.
Agile seems to be how they try to take two bad programmers and produce a mediocre one at twice the cost.
#10 by TimB on November 18, 2013 - 1:23 pm
Nonesense. that is the last statement about agile. Forget the title of agile. The biggest problem I’ve encountered in software is communication. Agile, or anything else that acts to facilitate better communication is IMHO a good thing. Agreed about pairing not been everyone’s cup of tea. It shouldn’t be forced down people’s throat, but it can lend itself to knowledge sharing/cleaner solution. I said Can, not will. I’ve benefited from pairing, just like having I have from Rubber Duck programming. But equally, I’ve benefited from working alone where I can concentrate too. No blue prints, no substitution for good and frequent communication.
#11 by peniwize on November 19, 2013 - 7:10 am
My personal preference is short hallway meetings between only stakeholders when applicable and more involved meetings when absolutely necessary. Then _everything_ is documented for posterity in an indexed medium that is easily accessed (I currently use Confluence). I’m totally fine with collaborating with one to three people in someone’s office to speed knowledge transfer. I do it frequently.
#12 by pierreclouthier on November 17, 2013 - 2:53 pm
Amusing. This is not unlike my impression. I think pair programming takes twice as long to accomplish, but you wind up with half the bugs, so it evens out.
And what is the one-man shop to do?
I have occasionally done pair programming, and have noticed the I, or my partner, do pick out the other’s bugs. But I couldn’t see myself doing it day in-day out.
BTW I’ve been programming since 1965, including assembler on 32K machines.
#13 by peniwize on November 19, 2013 - 7:38 am
Nice. 🙂 Assembly code on a 32K machine – I dig it. I really enjoy embedded development in a resource constrained environment. I’ve done my fair share as well.
#14 by Kai Großjohann on November 17, 2013 - 3:30 pm
Two points.
One is that I think code reviews might be a good way to get the benefits of pair programming without the constant interaction with other people.
Another is that I work in an environment full of interruptions, and in that environment pair programming actually seems to reduce interruptions because it’s just so much easier to shut out external interrupts if you are “in a meeting”. Quite fascinating. But it really drains me, too.
#15 by Darth Continent on November 17, 2013 - 6:19 pm
I mostly agree, though pair programming can be extremely helpful for bringing a newbie up to speed with the codebase, and in getting someone acquainted with an unfamiliar area of the code they haven’t had need to work with previously.
#16 by peniwize on November 19, 2013 - 7:14 am
I agree, however I view that as short term training rather than something that goes on indefinitely. I have also observed that newbies need time to absorb what they’re learning and really grok it, which requires quiet time in their own space without interruptions.
#17 by Bubba on November 17, 2013 - 7:55 pm
Pair programming: 1+1=0
#18 by ibrahim on November 17, 2013 - 8:17 pm
First of all I would like to congratulate you for having practiced your craft for 20+ years. I’m sure in twenty years you have worked long enough to understand in which conditions you are most productive.
Yes pair programming is not for everyone but the way you are describing it is very far from how I experienced it. You are looking at it in an extreme level. If after having 20 years experience you don’t have control of your working condition you probably are in the wrong company.
#19 by Dirk on November 17, 2013 - 9:57 pm
Pair programming is something big corps need to try to mitigate the software disasters inherent in their badly lead/managed, under paid, poorly trained workforce of work-a-day chair fillers. It has it’s place – thankfully somewhere I’m not 🙂
#20 by Paul on November 18, 2013 - 11:07 am
Thank you for this. A good review of the reasons to avoid PP…
#21 by Jeff on November 18, 2013 - 2:24 pm
I agree, I also hate the open environment all the people sitting in offices think works so well. Everyone that I have worked in had every person wearing headphones, so there was no “oh I heard something I will jump in and talk” but when they had cube walls less headphones, more jumping into conversations.
Plus people just felt they had their own space.
#22 by Ron Jeffries (@RonJeffries) on November 18, 2013 - 3:57 pm
Someone suggested I eat broccoli the other day. I don’t like green and I don’t like food with florets. I hate broccoli, and I’m never going to try it.
Interesting fact: about 90% of programmers who have never paired say they will not like it. About 90% of those who try it, do like it.
But you might not. We’ll never know, unless you give it a fair try.
#23 by peniwize on November 19, 2013 - 7:17 am
I enjoy broccoli.
#24 by anon on November 18, 2013 - 8:07 pm
Doesn’t sound like anyone would want to work with you anyway, because you sound like an abrasive dickhead from this post. I could be wrong.
Just be a freelancer if that’s what you prefer. Work alone. You already do anyway. You’d be what as known as ‘that guy’ – that one guy at every company, who is a gremlin and not to be disturbed lest they want to be shred apart.
Project and/or release managers don’t want code cowboys who want to be locked in a basement without communicating to the team or others about the progress and quality of their work.
#25 by peniwize on November 19, 2013 - 7:34 am
Honestly, I’ve found that people either like me or they hate me. Those who hate me have never really explained why (and I have asked in an effort to better myself; I’m uncomfortable with being disliked). They just seem to be the type to criticize others and/or dislike anyone they perceive to be a threat to them. Fortunately most people are not like that and I get along well with pretty much everyone. I’m far from the “gremlin” you think I might be and, while I strive to have and maintain the skills of a “code cowboy” or rock star programmer, I don’t have the ego. I’ve worked with prima donna’s and suffered with the miserable dysfunctional social environment they create. I don’t like them and I actively avoid being one of them. I’m only abrasive with people that harm others (or their work) and refuse to accept responsibility for their actions. That’s not cool and I won’t tolerate it. I learned early in my career that when I allow others dump on me or task me with their work or wreck my work and get away with it then they’ll continue to do it as long as they can. Putting up with that kind of behavior has jeopardized my career, harmed my projects, and harmed the company. I’ve seen more than one team and more than one company destroyed by allowing such behavior to go unchecked.
#26 by dogperson on February 8, 2014 - 12:36 am
Personally, peniwize sounds like the type of person I would love to work with. And the fact that you think he is an “abrasive dickhead” says more about you than him. Peniwize seems to understand that one size doesn’t fit all. As a software engineer of 30 years, I don’t like the extremists. I have used pair programming. Sometimes it worked well; sometimes it didn’t. Personally, I prefer to code alone. But that doesn’t mean I work alone. I enjoy interacting and learning from my peers. I just don’t like people who think that the only way to write quality code is to use pair programming.
#27 by Pure Logic Solutions on February 28, 2014 - 6:36 am
Stunning! Keep it up. 😀
#28 by Mo on December 11, 2015 - 8:36 am
I agree with you 290%. Those who love pair programming are too lazy to read. They want to be mentored by someone else, not knowing that they are slowing down the whole process.
#29 by Demont Washington on September 17, 2016 - 9:05 pm
Totally agree with your points here. I’m currently on a pairing contract, and it’s ruining my life.
Coding is very easy for me. Once I’ve gotten a look at the codebase, I can read a requirement or spec or agile story, and the code comes to life in my head and flows out onto the keyboard. Explaining it to someone else who’s less talented, or having them explain their idea to me, is a complete waste of time. Throw in a language barrier – half of my current team is non-native English speakers with varying low degrees of fluency – and you compound the waste. I’ve written a couple hundred thousand lines of code, most of it thoroughly reviewed and battle-tested. I didn’t need anyone to hold my hand to write it. I’m an effective collaborator and love being an accountable member of a team, but pair programming takes that concept to an illogical extreme.
I’m so socially and emotionally drained after a day of pairing that I have no enthusiasm for anything that I used to enjoy. I just want to go home and drink. I should start billing the client for all the single-malt Scotch I’m going through.
Pairing is a desperate attempt to increase quality, and it comes at the cost of productivity and sanity. If you want better code, hire better developers. Give the candidates coding tests, FFS. And when you find a good developer, let her/him work however they want.
#30 by bob on September 28, 2016 - 11:21 pm
I bet rigorous and regular code reviews get you all the benefits of pair programming. The junior guys may need review every two days.
#31 by Slavo Ingilizov on September 28, 2016 - 11:55 pm
It’s not about you, it’s about the business or project you are building. Many things can be achieved by individuals, but most big things cannot. I hope we’re not just talking about hobby projects here. If you can build an operating system, or a social network by yourself, you are delusional. If you put 5 people like you in a team, it will be an awful team. There will be too much “not talking to each other” which leads to misunderstandings and eventually failures. And businesses care about scaling and building teams more than you being happy. You are a local maximum, and optimising for you is by definition sub-optimal.
You might have missed the point. Pair programming is not a system that brings happiness to people. It’s a system for building teams and large scale projects. Don’t generalise it to everything and use appropriately.
#32 by bayazet on February 1, 2018 - 3:54 pm
Pair programming is ultimate crap. With very few corner cases it should not be practiced. I don’t believe that businesses benefit from it either. It’s another myth fed to arrogant managers. There is no real proof that it increases quality of the code. The only way to check it to create that code first using team of individual contributors, and then create it again using team of paired programmers. Then you can compare amount of bugs. I am not aware of anyone conducting this kind of experiment. Also I don’t see how any business can benefit and make things go faster, smoother, with better quality by making its main contributors miserable and uncomfortable. Yeah, right “it’s not about you, it’s about the business”. Pair programming completely eliminates research of the problem. I can’t say “ok, I don’t know how to approach this problem, let me google how others might’ve done it” if I paired up and need to type the code. There is not time to stop and google: you need to talk-talk-talk and type-type-type.
I noticed one trend too: pair programming is very spread in indian contracting sweat shops. They would do just about anything to get that contract. If the hiring business tells them “we want you pair-program” they will, if they ask them whether they know zigazumga programming language – they will tell you they have 50 years of experience in it. I suspect if they are required to program standing on their heads they would do that too. cognizant, wipro, collabera – they all are doing it.
#33 by Steve Davis on September 29, 2016 - 12:07 am
The trick with pair programming is to be sure that the least experienced developer is the one who types. And yes… it’s absolutely not about outright productivity, it’s about learning.