I spent the first fifteen months of my current job on a 100% pair programming team before transferring to a more traditional scrum-based team.

Some observations: team cohesion on the pp team was much higher, code quality was higher. Flexibility, not surprisingly was lower: we had a very fixed schedule: "Stand up" at 8.06 (despite the name, it was unrelated to the scrum event, instead it was more time for sharing news and interesting things before the workday started), team stand up immediately following (this was closer but not quite the same as the scrum stand up), then breaking into pairs and working until noon, then an hour for lunch, then working 1-4 then an hour for individual work like training, administrative junk etc. Remote work was not typical although there were two or three remote team members who lived elsewhere and tele-paired three weeks out of four.

I'm hard of hearing so this was a somewhat draining experience for me thus my switch to my current team. Here, team members typically work remotely 1–2 days per week (largely a consequence of corporate policies which have fewer desks than employees). Each team has 2–3 offshore teams that we work with. It seems like we spend an inordinate amount of time in meetings (my calendar has 11 hours blocked off for meetings in a "normal" week and more is not uncommon). There's a tendency for information to only be passed on orally which isn't great with my hearing loss.

It's not strictly a comparison of PP vs non-PP but overall, I would return to the PP team without hesitation.

Personally, I dislike PP

- hard for remote teams. Only good if everyone on the team can easily pair up.

- only good if everyone follows a strict schedule

- only good if everyone understands the problem and solution space equally. If one of us needs to go into a cave for an hr to read documentation or experiment, it all falls apart.

- very mentally intense. You're always on. Can only keep it up for a few hrs without some massive mental drainage.

Overall I like PP for small problems to help teach someone. I dislike it for day-to-day.

> A pair works at the speed of its slowest member, so it take at least 8 hours for them to finish the "easy" coding.

Not necessarily. I pair with a guy who's probably 10 times as productive as I am(I really try, but I understand that I'm relatively slow), and he'll ask me to pair with him because I might come up with an idea for something that even he is stuck on. I often do, despite the fact that I'm much slower than he is at implementing things.

So while I do think that it can often be the case that a pair will only work as fast as its slowest member, most likely when tackling a large problem or even doing something tedious, that doesn't mean that there aren't times where a more productive member can value from pairing with a less productive member.

EDIT: This is entirely from my point of view, so it's possible that this person I mentioned feels differently. However, even if they were frustrated by my slow performance, I don't think they'd inquire my assistance on problems if they thought they wouldn't benefit from it.

I work at a company that does full-time pair programming whenever possible. There can be drawbacks for sure, but overall, I love it. However, one caveat is that our hiring process places emphasis on finding people that are collaborative and easy to work with as opposed to know-it-all "rockstar" developers. We also do test-driven development, so in addition to the most common pattern (driver / navigator) we sometimes do it a different way wherein one person writes the failing test, then their pair writes the implementation to get the test to pass along with the next failing test. Rinse, repeat.

I generally find the axiom "If you want to go fast, go alone. If you want to go far, go together." applicable to this context.

----

Benefits of pair programming (IMHO):

* It eliminates the need for code review (most of the time) since another dev is providing input as you write.

* Pairing senior and junior developers is an excellent way to build the abilities and confidence of the latter.

* Pairing decreases siloing of knowledge and one individual's "ownership" of a particular feature or system. You much less frequently see things like "Oh, you have a question about our Widget Framework? Go ask Sally, she's the only one who touches that part of the code."

* You're less likely to implement hacky solutions just to get something to work because someone else is working alongside you. (At least, I am.)

* It's easier to find and fix bugs (in my personal experience) when you have two sets of eyes on the code.

* You have to slow down and explain your ideas before immediately jumping in and implementing them. I generally find that reaching consensus with my pair about the strategy to solve a problem helps surface edge cases I might not have thought of alone.

Pair programming can be very useful when you're training someone new or starting up a new project and want to spitball ideas.

I was offered a position with full-time remote pair programming. That sounds like a nightmare to me and opted out of that one.

Some people hate pair programming. I happen to be one of them. It kills my personal job enjoyment/satisfaction and if I was coerced into pair programming too often, I would find a job elsewhere.

So, the cost of losing one or both of the programmers in the process must be considered too.

Pair programming can be fantastic in short burst. The other day me and a coworker were working through a difficult solution and having another set of eyes was needed.

Maybe its just because I get along with my coworkers, but when working on something difficult we naturally collaborate and end up in an unofficial "pair programming session"

My experience pair programming:

- Pair programming works better remotely than people say, in my experience.

- It is a great way to share unwritten/unspoken information and best practices.

- PP is excellent for team cohesion and allowing engineers to get to know each other and their strengths.

- Not every engineering problem warrants PP.

- Some problems are better solved by one person as it can take too much time to get the other person up to speed with the issue.

- Pair programming often leads to better code, but you have to balance that with the overall reduced amount of work being done at once. If two people are working on one issue, you have to balance the benefit of that versus two people working on two problems.

- I'm more effective when I can focus, and sometimes I need to spend an hour deep-thinking about a subject and perhaps pseudocoding something. Pair programming with someone remotely and having long periods of silence would be... weird.

- People seem to view PP as a measure of success. The more a team is pairing, the more success being experienced. Right?

- If someone isn't into pair programming often, that's seen as a negative.

- 95% of people who pair remotely need better microphones or accoustic environments. I wish remote companies would ship their employees a pair of AirPods, a Yeti mic, and some acoustic foam squares.

- Pairing is more consistently useful for reviewing large code changes where it can be difficult for a reviewer to reason about the work that was done. Going through it with the author and doing a screen share can make all the difference.

My conclusion is that pair programming can be good for some things, but I would consider it a red flag if a company highly emphasizes pair programming or coerces people to do it. Treating pair programming like a panacea dismisses the fact that people of different personality types have been writing perfectly good software without pairing since time immemorial, and that there are other ways to improve code and product quality. What I think can be nearly as effective as pair programming is getting code reviewed early and often. I'm not the best at this yet, but I've noticed that life is just better when I don't do a ton of work and wait for it to be reviewed when it's "done".

There is a construction site in front of my office. When I walk close by, I always see a guy working and another one standing next to him apparently checking if he is doing correctly the job. Wondering if this is the equivalent of pair programming in the construction industry.

Anyway, I've done some pair programming when I was younger, and I like helping some new folks with a 1-hour pair programming sometimes, but I don't think I could stand having someone pairing with me all day. Furthermore, there are other ways to keep code quality high (code reviews, tests and so on).

I imagine this could be chain-gang hell for introverts.

I've always wondered if the people who move into decision-making spots are extroverts, who then go on to make decisions affecting introverts, like open-plan seating.

Like a lot of discussions of programmer productivity, it's hard to measure, so nobody bothers and we talk around the issue without any hard numbers.

In my experience some people use "pair programming" to hide their insecurity and incompetence.

I think PP is great; however, I do not like to use it as an educational practice. Why boils down to two ideas - a) you are not hired in teams, so you cannot rely on classmates; and b) we've made students so scared to help each through fear of academic integrity and copyright violations that we had to create a special activity centered around looking at someone else's code.

The first idea is rather obvious - the teams you build while learning may be enjoyable but that does not directly translate to hireability. PP Exercises are still scored primarily through correctness over contribution, so a slacking student can do less and potentially learn less without fear of too much penalty to their course grade.

The second idea is more an opinion about the state of CS ed. In an English class, if I wrote something that wasn't good, I could rely on peers to help. If I need help on my weight lifting form, I can show my form to others for advice. In CS, how dare you show your code to anyone because Copy and Paste are so easily done. I've literally had students swear off StackOverflow and helping peers for fear of being labelled a cheater. PP to me seems like its trying to solve that fear rather than deal with the cause of the fear.

Being forced to pair program all the time blows (IMHO). It's just too rigid. I was recently paired with another guy way below my ability. Great for him, not so great for me. PP is amazing when you and a co-worker decide to pair because it's the perfect approach for a problem you're trying to solve, or because one of you needs help figuring something out.

I'm seeing an error when I try to view the site that looks like this:

"Trouble Encountered https://c2.com/wiki/remodel/pages/PairProgrammingEconomics can't fetch document

See github"

I'm guessing the site is overwhelmed with more traffic than it can handle.

This sentence from the blog is key, "Caveat: Pair programming is a learned skill. It takes time and work to do it well."

Pair programming sounds great and all but if even one person from the "pair" is not good at it, everything falls apart. Also, the pair's chemistry has to be on point like Jeff Dean and Sanjay from Google :p

Pair Programming is a complete crock of shit. If you hire someone to do a job, either they can do their job, or they cannot. If you cannot trust someone to perform and deliver work up to a certain standard, do not hire them. Is there any other industry where you hire two people to do one job?!

Now there are certainly times when it is very valuable to do collaborate, such as rubber duck debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging or mentoring or simply doing a 'desk check'. But these are the exceptions, not the rule. Having someone breathing down your neck or be a back seat driver all day is at best a waste of productivity, forcing the driver to think at the pace of the observer, and at worst, a complete waste of time and effort.

I'm one of the right people, I love pairing and have been doing it for a decade full time. That being said, I'm also very much aware 80% of developers will never want to do it, and that's okay. Even though it's a skill to learn, and I'd guess a good many of those 80% would come to enjoy it with more practice, it's ok to not like it.

Even if it was scientifically the fastest and best way to program (engineer productivity is unmeasurable so we'll never know) there's still a huge number of developers who will hate it for a number of reasons. They are all valid and no one should be forced to do things they hate if they can add similar value some other way.

My experience pair (and mob) programming for the past months has been very positive, both with in loco and remote peers (sometimes mixed). New hires feel they get a lot of context faster, and experienced peers feel it improves quality, as it forces code to be understandable.

I believe it's instrumental that the entire team is at peace w/ some working agreements to make it work:

- Splitting work between pilot/guide(s) (otherwise, it turns into a monologue)

- Rotating roles often

- No pressure to stay or having to leave for a while

- Have adequate installations (quiet space, standup desks, large screens, 40"+ displays if possible, ambient sound for remotes to join in the session)

- Naturally leads to egoless programming

The economics of pair programming is twice the price for half the productivity.

Through a lot of experimentation I found that pair programming can help in many cases: onboarding, code reviews, design & architecture and others (https://www.togetherwecode.com/articles/seven-ways-explore-p...).

It doesn't always work for me, but I found that it offers a surprising amount of benefits.

Many previous threads going back 12 years, for the curious:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

This is a wiki that only serves user-agents that are capable of executing JavaScript. Weird.

For those who don't see the value in pair coding, there is an alternative with less overhead - code review.

Just emphasize to everybody to keep it friendly, and make an effort to +1 ASAP every time.

I've seen the following from pairing Junior and Senior engineers:

* Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing.

* Middle of the road junior engineers can be stunted and continually depend on the decisions / skill of the more senior pair. Pairing them more frequently with same level or lower helps. Sometimes this doesn't happen because this lower quality pair goes significantly slower and the result may need some code review/cleanup cycles, but it's a worthwhile investment.

Paring with Ping Pong TDD works really well. Improves paring with frequent driver/navigator switches and improves TDD by having the navigator thinking ahead. Been doing it almost exclusively for 14 years.

Hiring for pairing is important. It's not for everyone, although not everyone has been in an environment where it's done well. I make sure to let people know they will be pairing full time on my teams and ask if they are comfortable with that. Also won't hire anyone that would be significantly slow to work with (can't touch type, slow thought process)

These are all very valid benefits, which I've experienced from pair programming as well.

True. It's also true a lot of people hate solo programming, and do not want a non pair programming job.

My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you'll most likely end up with two annoyed programmers, and not great code.

Next time on Hacker News: an article about the economics of strong typing, with someone threatening to quit if they have to use a strong typing system, demanding that be factored into the economics as well.

Perhaps true, but not really the point the authors were looking at.

I don’t know if I would say I “hate” it, but the one time I tried it (at the behest of my then-employer), I and the rest of my team found it to be unworkably impractical. We had half as many computers as we had programmers, so we each shared a workstation. However, each of us had our own individual e-mail addresses, so we’d have to take turns checking and reading e-mail while the other one sort of looked away. When we started using something new (I think it was Apache Struts back then), we’d have to take turns reading the documentation - we even tried putting two different copies up side by side so we could scroll individually (but we still had to take turns moving the mouse). Beyond that, everything seemed to take way longer than it might have taken individually because neither of the people in the pair would be comfortable doing anything experimental unless they could quickly explain it to the other, so there was a lot of time spent talking about whether some approach or other might work instead of just trying it to see what happened.

Over the last few years I’ve come to this exact realization as well. I used to think about it as a couple devs sharing a keyboard for interminable stretches and it made my skin crawl. Watching someone “drive” fumbling for buttons in the IDE and not using shortcuts makes me want to shoulder them out of the way and take over.

However, for short bursts (10minutes to max about 90) that are focused on a particular goal makes me feel both re-invigorated and more satisfied with the completeness of the ideas.

The re-invigoratation (for me) comes from not having to run my brain at 100% for the duration. In auto racing terms, my partner and I can take turns drafting off each other’s thoughts, increasing our mental efficiency.

When differences arise I love hearing their thoughts and finding ways to merge the best of both ideas- or completely tossing my own because theirs are better. I’ve heard it (no clue where or from whom) described as idea sex. I’m very okay with my ideas being promiscuous and having lots of better little idea babies.

I still haven’t figured out how to keep my skin from crawling watching people fumble around their UIs though...

isn't how pair programming emerged ? a natural realization that teaming up helps searching through space at high speed, keep motivation up, anxiety low.

my favorite time in college was the one time I met a similarly minded guy, we cracked through problems with such a positive energy. It was like a biking race, I'd find an idea, then get stuck, he'd try something, so on and so forth.