1. 30

I promise this is my last article on pairing, I swear. 🤣

  1.  

  2. 11

    I think the most awkward pairing experience was switching-off computers with a guy who had a long vimrc when I also had a long vimrc. We had different muscle memories.

    It didn’t help that he used dvorak.

    One way to “pair program” I’ve found works a little better is a sort of ‘driver-gunner’ style. One person is writing the code, the other person is on their own computer, reading other parts of the codebase and researching docs to answer questions for the driver. It’s a lot less intense and more comprehensive, I think.

    1. 13

      This is one reason I’m not a fan of “super productive” custom configs. I doesn’t take long for the gains to be wiped out when any other human on earth tries to use your bespoke computer. If I were king, devs would be randomly assigned computers when they show up each day. :)

      1. 7

        If I were king, devs would be randomly assigned computers when they show up each day. :)

        You monster! :)

        In all seriousness, that would be a deal breaker for me.

        1. 7

          It’s my computer! Get your own!

          1. 7

            The more pain inflicted on anyone trying to use my computer the better.

            1. 6

              Funny story. I run an all Linux household, and my wife was using Ubuntu. It caused never-ending problems, particularly around dist upgrades, and I found the problems difficult to debug. I switched her over to my own personal setup (Archlinux, long bashrc, long vimrc, home grown WM, custom backups, yadda yadda) and things are much smoother now. She’s not as invested as I am, but whenever she hits a problem, I know exactly how to fix it.

              (Otherwise, I find the occurrence of other people needing to use my computer to be very infrequent. If it does happen, they usually just need a web browser, which I can open for them and they’re off to the races.)

              1. 5

                I have a longish blog post in the works about building keyboards and using alternate layouts. There is a sad, prominent section titled “Other People’s Keyboards” to describe the point at which the endeavor jumps the rails, bursts into flame, and tumbles off a cliff into the sea.

                1. 2

                  So you don’t care at all if a program you use eliminates a feature you rely upon because only 1% of the users use said feature, right? (think Google)

                  Or you don’t mind Carpel Tunnel Syndrome because the default keybindings are horrible? (think EMACS)

                  Or you don’t care when a program changes a default setting? (think just about every program on earth)

              2. 10

                I have yet to hear anyone say that they enjoy pair programming all day, every day, forever.

                I love pair programming — a key part of my interviews includes a pairing session — but I quite frankly can’t pair for more than about an hour at a time, tops about four sessions per day with at least two different people. That’s my personal preference.

                I would be interested to know if the authors team consistently concludes during regularly scheduled retrospective sessions that everyone enjoys doing forced pairing enough to keep it a thing.

                1. 6

                  Let me be the first. :) I love pair programming, and miss it whenever I have to code without it. Doing it for a year kind of ruined me for working alone. (And I’m not an extrovert! In general, I shy away from being around people.)

                  I read about bad pair programming experiences and count myself as lucky that all the partners I had were really great people and invested in the process. I can see how it could go sideways.

                  1. 7

                    In the past, I’ve misunderstood what “pair programming” actually means. Could you elaborate and say more exactly about what it means to you? What does your daily process look like? How did you deal with the practical problems stated, like, say, different editor configs or such?

                    1. 2

                      I’m not the OP, but here is a write-up of my good experience pairing.

                      http://deliberate-software.com/pairprogramming/

                      1. 2

                        OP here: I remember reading your article a while ago (it’s really good!). When I saw the below quote I realized you were talking about me.

                        Some developers love the idea of pairing, not the practice of pairing; they often leave when they discover that distinction

                        A lot of days I would wish I could like it, so I could enjoy my job. I felt like I gave it a fair shot too (2 years).

                        1. 2

                          Do you all have a notion of “going odd”? I probably am “odd” at least 3 sessions a week, which helps for time to think and recharge.

                          1. 1

                            We did but if you’re on a team with an even headcount you’ll never go odd. I wish we could’ve gone odd more often.

                            1. 1

                              Hmm that’s unfortunate.

                              Even with 6-10 in our office, one pair splits most of the time to handle odd work, research, or support.

                              Recognizing when to split pairs while still maintaining the tenet of “all production code written by a pair” goes a long way.

                      2. 2

                        Sure – when I did it full time, I had the same partner for about a week at a time before switching. We worked on a project for 8 hours a day, coding for about 45 minutes at a time with 10-15 minute breaks in between. We usually were co-located, although not always. We had two keyboards and mice, and usually two monitors, and would switch off who was writing code differently depending on the partner dynamic, but it was usually pretty organic – whenever your partner was stuck on what to write and you had an idea, you’d take over.

                        Different editor configurations were definitely a thing that could cause friction, but I don’t see that as a bad thing. I both learned a lot about editor tricks and gained an appreciation for keeping your config as simple as possible. We mainly worked in console-based editors (vi and emacs) as we were sometimes pairing remotely.

                        Remote pairing was easier in some respects. Instead of using one person’s machine, which could have its own config issues, we spun up a VM on AWS from an image we made, so there was a standard base configuration.

                    2. 4

                      I would be interested to know if the authors team consistently concludes during regularly scheduled retrospective sessions that everyone enjoys doing forced pairing enough to keep it a thing.

                      Pairing was already a part of the culture when I originally joined, so it was actually pretty hard to get people to admit they didn’t enjoy it (politically unpopular). It was never brought up in retrospectives. That said, I’d say the majority of the people who worked there did enjoy it and it worked well for them.

                    3. 8

                      I really dislike pairing, it takes away all the fun in programming and replaces it with a theatrical show.

                      Programming for me is 95% thinking (when writing and debugging) and 5% typing. My train of thought is orders of magnitude faster than my speech, so when pairing I get bored after 30 minutes and my productivity falls down.

                      1. 6

                        I’ve never done pairing at that level of intensity - all day every day. Doesn’t sound like fun, and I can definitely see feeling the way the author did. I think it might be useful to do an hour or two a day at most.

                        Related - I spend a lot of time on things that paring doesn’t sound so good for, including researching possible solutions, writing docs, reviewing other peoples’ code, troubleshooting, setting up meetings to build consensus on possible solutions, etc.

                        1. 6

                          I gotta be honest, the thought of 8 hours of pair programming a day is probably my definition of hell. Maybe for a while but daily sounds evil.

                        2. 4

                          I’ve paired full time for the last five years on complex banking software - I’d say unless you’re doing simple CRUD, it’s more like “pairing, take the productivity of two devs and multiply it by 4”.

                          Every developer gets to work in the whole system - no silos. Everyone gets to learn everyone else’s tricks and tips - no slow fuddy-duddy who still doesn’t know about Ctrl-c, etc.

                          Not only that, but pair rotation means we see no burnout on really hard tasks and tech debt. Normal companies I’ve worked at only have the stamina for either minor tech debt or “scrap it and start over”. Both are terrible choices for long term productivity. The real value is in massive tech debt projects accomplished over months, without a loss of functionality or features. Pairing enables that where single developers just can’t handle the boredom.

                          Also, pairing is a skill that is as separate from programming as touch typing. It needs to be learned and practiced for months to see an ROI. Most people don’t have the chance to try it for that long, so they remember it with as much fondness as someone with a few weeks of typing remembers the keyboard ;)

                          1. 1

                            I respectfully disagree.

                            I specifically wanted to avoid the conversation of productivity (happiness is a more humanitarian metric, and therefore more important to me), but here we go:

                            I’ve paired full time for the last five years on complex banking software - I’d say unless you’re doing simple CRUD, it’s more like “pairing, take the productivity of two devs and multiply it by 4”.

                            I was pairing on a payment gateway, so similar problem space (not easy). I found no such productivity multiplier. In fact, I was frequently (and silently) bemused when I noticed “odd” programmers completing far more work than their pairing counterparts. I’m still amazing that people try to say that dividing your work-streams in half yields higher efficacy. The math just doesn’t add up here, even in a world where everyone learned by watching people code.

                            Not only that, but pair rotation means we see no burnout on really hard tasks and tech debt. Normal companies I’ve worked at only have the stamina for either minor tech debt or “scrap it and start over”. Both are terrible choices for long term productivity. The real value is in massive tech debt projects accomplished over months, without a loss of functionality or features. Pairing enables that where single developers just can’t handle the boredom.

                            You’re creating a false dichotomy where you can choose between pairing or tech debt. Tech debt is equally prevalent in both XP and non-XP worlds. Also, anecdotally, I am living proof that burnout is possible with pairing. :)

                            Also, pairing is a skill that is as separate from programming as touch typing.

                            No argument here!

                          2. 5

                            Pair programming. Where you take the productivity of 2 devs and divide it by 4.

                            1. 3

                              While I’ve always thought the same way, I’ve never ever seen it be said by people who are effective at pairing. In other words, most of the experiences I’ve heard about maybe start out as less efficient, but the gains in shared understanding, shared problem solving, etc apparently pay dividends in time later on.

                              1. 3

                                Here’s two counterpoints I found looking for one whose bookmark I lost or can’t remember:

                                https://www.quora.com/Why-do-many-programmers-oppose-pair-programming

                                http://www.bennorthrop.com/Essays/2013/pair-programming-my-personal-nightmare.php

                                What’s your thoughts on those gripes given the perspective you shared? For me, I’m an introvert who does much better alone but collaborating with team members when exploring or debugging as in Quora answer. I’d be mentally drained by prolonged, pair programming. I still might try small sessions of it sometime when learning something new. I try to stay open-minded about it as I know it has benefited some people. But in production coding is it really necessary and helpful versus solo folks in the zone occasionally getting together in code reviews? I lean toward doubting that. Maybe for extroverts, though, as they zone when interacting with people.

                                1. 4

                                  Yesterday I did a driver-gunner style pairing and I’m curious if that would work better for you than “stereotypical” pair programming styles. Caveat is both my pair and I are fairly extroverted people, and I don’t know if this would be easier for an introvert than regular pairing.

                                  Context: Three of us are dealing with a complicated production fire that’s harried us for three weeks running. We think we have a patch that would fix the last part of the problem, but it interacts with workflow code creaking under five years of hacks, tech debt, and “move fast”. It’s pretty much rotting turtles all the way down. We paired to write tests to check that the patch doesn’t break any of the legacy behavior.

                                  My partner was driver, I was gunner. We spent one hour writing on a whiteboard all of the possible actions the user could take and all of the consequences of each action. When we were uncertain about the expected consequences she was responsible for reading and testing the code and I was responsible for asking other people in the company. Once we had a clear picture, she started with writing the setup code to generate exhaustive tests while I continued whiteboarding to figure out the invariants we would eventually test for. Once I finished and she confirmed they’d be useful, I switched to reading rspec docs and answering her questions so she could continue to focus on code. Then we had a meeting and that killed work for the day

                                  I found this really useful and helped us make a lot more progress than either of us would have individual. The notable differences from standard pairing were

                                  • I wasn’t on a computer until the very end. I never wrote any of the production code; it was all one person.
                                  • We never ‘took over’ each other’s computers, so we didn’t stumble over different configs.
                                  • While I sometimes watched her code, that was never my primary responsibility, so when either of us got edgy I could just back off.
                                  • She only had to explain what she was doing at a high level, which is less tiring. She only needed to explain low level stuff if she got stuck or needed me to research something.
                                  • Since we had a dedicated coder and a dedicated researcher, there was less context switching, and both of us could focus more.

                                  I don’t know why I call it “driver-gunner”. It’s just division of labour. “Driver-gunner” was just the first phrase that came to mind.

                                  1. 4

                                    My perspective is pretty similar to yours. I work best alone, but collaborative debugging and exploration work really well for short periods of time.

                                    I’ve tried pairing all day for a couple of weeks, but this experience was remote. I’m not sure how that effects the effectiveness of pairing as perceived by the “pros.” I did find all day pairing to be more draining, and while I appreciated the shared context, I didn’t believe that the person to person communication was better than just writing clear documentation (in the form of actual documentation, and detailed but concise commit messages about the reasoning for changes) which lasts forever.

                                    1. 1

                                      Makes sense. It’s about what I expected.

                                  2. 2

                                    This is not the case in my experience.

                                    1. 2

                                      Very interesting! I assume your experience mimics the OP? Or is there something unique?

                                      1. 2

                                        Mostly it’s just extremely draining and not very productive. I wrote about it at more length in the last pairing thread, here.

                                2. 3

                                  The only situations I found pairing to be useful are when you’re either exploring a potential solution, or trying to debug something.

                                  1. 3

                                    I think it’s great that you posted this. More people should speak up about it. I also liked that you called out the potential for ableism. It’s ironic that an industry that professes to value diversity goes and shoots itself in the foot with exclusionary tactics like this.

                                    I just found out the company I’m working for is setting up a 4month engagement to build an app with Pivotal, which is all XP. Im excited about the project but dreading having to do pairing 8 hours a day… funny thing is I’ve actually introduced a lot of pair programming into the company and am certainly a proponent of it but only for 1-2hrs a day and in certain situations (onboarding, difficult problems, etc).

                                    1. 3

                                      I’m super curious to hear your thoughts after you do it for several months.

                                    2. 2

                                      I enjoy pair programming because I enjoy people and socializing more than hard work and getting things done.

                                      It has occasionally resulted in my pair spotting a bug before I did, but nothing code review wouldn’t catch.

                                      1. 8

                                        “If you pair programmed you don’t need code review” is a terrible, terrible meme.

                                        1. 2

                                          I agree that meme would be worth destroying. I didn’t read the comment that way given @ec said the bug pair programming spotted was something a code review would probably catch. If anything, ec’s words dismissed pair programming in favor of code review.

                                          1. 4

                                            Oh definitely, consider my quip emphatic agreement with them.