> I’m not a social creature Then don't work in a team, work in contract development. Pair programming is really only good for team environments where everyone

> I’m not a social creature Then don't work in a team, work in contract development. Pair programming is really only good for team environments where everyone has to deal with confusing elements of everyone else's code. > 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 Do it over the internet with a shared tmux/screen session + a voip client. > I, like most left-brained people, am an introvert and can’t comfortably tolerate that much company or social interaction There's a difference between being introverted and being unable to handle technical conversations with another individual. If you can't talk to someone over the internet while you take turns in entering text into a screen session you should really look into therapy. I know quite a few people who have made efforts like that and it has helped them by miles work through these frustrations. Granted I hate most people but I can still have a few technical discussions with them. > I prefer to think and work quietly and alone When I pair program the quietly part is definitely one of the major parts. I have issue typing and talking. Pair programming usually works best as follows: - Get problem - Talk about the prototypes you want to mock up first - Write out a bit of the code at a time and listen to see if the other wants to take over - Keep going until you finish with this prototype then both spitball ideas at each other for how to break it. - Repeat until done More then half the time I've pair programmed I've basically talked with my partner for a few minutes about how to solve our problem, I've typed it out, they either took control and pointed out some things (for which I either defended or changed) and then we sat there for a bit attempting to break it. Most of the time is dead quiet. The only exception is when you ask the other programmer "hey while I type this out can you read me off the param list to X from the docs for Y" and they'll come back and read that to you. I'll count that as an interruption. > 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'd love to do a study that proves this to a standard that the author may agree with but I don't think it's possible. I have a few ideas for homework problems in my classes and see who writes more buggy code. > 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. Maybe it's just me and my friend I pair with but we have a "no-interruptions" rule. We tell each other when we are done thinking about something. This way we work more in lock-step rather then interrupts. Again, talking to people about this sort of stuff, just like about code, is important. > 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 I think this statement is the exact opposite of what I think people like me want. This lets you do program faster, and with usually cleaner results then if done by either of the two members. The sum is greater then the parts. I do agree with the author, they are most likely the majority which is sad.