28 ms·

Against Pair Programming

• deleted 5y ago
  [deleted]
• dustingetz 5y ago
  read any hn thread about how much time software engineers spend working. big company programmers are putting in 6 hours of effort per week.
  • Tabular-Iceberg 5y ago
    Maybe that’s the point. It’s harder to just sit at your desk and space out when you’re right next to someone else. On the other hand I feel like pair programming sessions often get sidetracked into interesting conversations about technology or just about anything else that’s interesting, so that part is nice.
    • JackMorgan 5y ago
      This is the biggest thing I have seen with pairing when it works. People are less likely to disrupt a pair, but they'll happily bother a single person. Enough of those happen a week, and the pair gets 20+ hours of coding vs the two singles only getting six each.
    • denton-scratch 5y ago
      > pair programming sessions often get sidetracked I've never experienced that. My experience was that pairing sessions were continuous, bloody hard work. My partner and I would have our noses to the grindstone throughout the session, which was strictly time-delimited (10AM to 5PM). I'd go home exhausted. Whether you're driving or navigating, you have to concentrate. The navigator has to show the driver that he's paying attention; the driver has to account for what he's doing. Working solo, it's much easier to get sidetracked. Feeling overloaded? Well, spend a few minutes on HN.
      • mnsc 5y ago
        How dare you call me out like that! But really, when you have trust rather than competition between colleagues it's absolutely ok to plan regular breaks and pull the emergency break when your focus juice has run out for the day. So depending on culture and how stable/jelled-in your team is pair programming shouldn't a exhaustive grind. That doesn't seem sustainable.
• davedx 5y ago
  Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense." The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric. Utterly ridiculous. I despair sometimes.
  • kstenerud 5y ago
    Please read the article all the way through before commenting. Your other points are already addressed.
    • adrianomartins 5y ago
      I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made. And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.
      • kstenerud 5y ago
        I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.
        • nijave 5y ago
          Async code reviews are slow. A code review is about getting people to agree on the code being reviewed (ideally using a set of objective guidelines). Instead of having a review done in an hour, for instance, it can easily stretch into days of back and forth to reach a consensus. Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome. You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things
• LandR 5y ago
  I've found pair programming has helped in the past when working on really complex or convoluted code. I could sit for a day myself and maybe get my head around it, or pair program with someone else and between the two of us we get it knocked out in a few hours. If you only have a simple code base, I think pair programming doesn't have a lot of value. But when you are in a 5million + LOC legacy app, pair programming can help a lot IME.
• spacemanmatt 5y ago
  "I did it wrong so it must be bad," the blog post.
  • adrianomartins 5y ago
    Most definitely. Once thing that I feel is not said about pair/mob programming, and also for Trunk Based Development for that matter, is that they essentially require a different mindset and ways to approach/solve a problem. If you're going to develop a feature in pair-programming in the exact same way you would if you'd be doing it alone, yes, it might not be the most effective thing. If both/many programmers discuss the ideia first, implement it, correct it on the fly, and when it's done it's completely done, with no waiting time, no delaying the value, no miscommunication in comment boxes, then it's highly effective.
  • stevage 5y ago
    I got the sense that he hadn't even really tried it.
• jordanbeiber 5y ago
  Resource optimization vs. Flow. It all comes down to measuring outcomes over time. Doing agile is doing right-ish things at the right-ish times, including ways of working. Use retros - are we being efficient over time? Why and when? Why not and when not? My teams tend to flow in and out of pairs, mobs and single contributions, all depending on task at hand and circumstance. Flow! Are you flowing? How do you know? Over time I’ve noticed that really well gelled pair and/or mobs deliver more consistently, over longer periods of time. YMMV.
• hownottowrite 5y ago
  Related: https://twitter.com/mattrickard/status/1492548554426048514?s=21 https://twitter.com/mattrickard/status/1492548554426048514?s... Not exactly a great attitude, but it’s how I came across the post.
• brianmcc 5y ago
  I'm pair programming ambivalent. A lot folks like it. I mostly don't, but I enjoy collaborating more broadly, and sometimes a pairing session can be truly invaluable when the task at hand is right. I think it has many benefits in that at least knowledge isn't entirely siloed with 1 contributor. It's not the silver bullet to solving wider system awareness problems though. >> Not to mention the coveted flow state that most developers look for. That is perhaps the single biggest factor around why I prefer not to pair for the most part. Frankly I just can't think as well about creative, problem solving stuff when I'm pairing. There's also an "enjoyability" issue. If people enjoy pair programming, and this will vary by individual, they'll find ways to keep practicing it even if it's not the most efficient option (and actually there's a good case it is long term cost effective). If people do not enjoy pair programming, they'll find ways to avoid practicing it even if has many economic or systemic benefits. As we often find, it's a people thing: we remain emotion-driven and reward-driven beings and that isn't going to change any time soon.
  • stevage 5y ago
    Yeah, personally I don't particularly like it, because I don't particularly like talking about the coding I'm doing - I like just being in it. But I can totally see that it's very effective and enjoyable for a lot of people.
  • adregan 5y ago
    I really enjoy a pairing or mobbing session, but I haven’t figured out a good way to integrate a key part of my process. I usually attempt an aggressive reshaping commit history as I find it allows me to re-evaluate and improve the code, but it also allows me to craft a PR that can be understood commit by commit (and even split out unrelated work to prevent big PRs). I appreciate reviewing small PRs that tell a story (and revisiting a nice PR years later for context), so I put a lot of effort into it. Often it’s an exercise in tedium that doesn’t really suit 10-15 min handoffs when you’re stuck deep in a rebase and it gets tougher when the commits are all “WIP,” but the biggest thing that bothers me is that doing so often clobbers the other devs contribution if the commits have been sufficiently remixed, and I want their contributions recognized in the history.
• mjw_byrne 5y ago
  Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, losing confidence, taking shortcuts to try to keep up and making a mess, you have two programmers in a state of flow producing high-quality work. As a side-effect, you also get great shared knowledge of the code base.
  • mihaaly 5y ago
    Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Myself I actually enjoy this quite a bit. For avoiding and catching mistakes is useful but not a guarantee at all especially as their way of thinking is synchronised. There are other techniques for these as well (tools, patterns, reviews, ...) allowing two people working with two things. Shared knowledge of a codebase is pretty useful. While it lasts. Also pitty it involves exactly 2 persons only. Documentation is far more reliable way of sharing code knowledge, especially long term and in changing team composition.
    • mhitza 5y ago
      > Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Feels like a reductionist statement. When working on a large codebase (call it legacy even, as everything devolves into legacy code given enough years), it's impossible to keep all the details in your head. Code review can provide the additional context missing to the developer implementing a task, but I'm sure you've been in the same situation before; where a feature change, even small in scope would crisscross multiple files, and without testing it out you're unable to review conformance. As an example. When I was team lead on a large and legacy SaaS project in the past, I pretty often would pair with other developers on the team, and their input as well as my input had us catch situations that while developing in isolation we could have missed. Even in a standard code review. Because during development we were deeply entrenched in the code and able to often try out multiple approaches for a problem.
• jasode 5y ago
  When I read a New Yorker article about Google, I was surprised to learn that Jeff Dean and Sanjay Ghemawat do a lot of pair-programming. Excerpt from: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship... >“I don’t know why more people don’t do it,” Sanjay said, of programming with a partner. >“You need to find someone that you’re gonna pair-program with who’s compatible with your way of thinking, so that the two of you together are a complementary force,” Jeff said. [...]
  • alisonkisk 5y ago
    They aren't "just" pair reprogramming -- they are practically married. They pair only with each other, forever, and they are best friends. It's not an arbitrary or rotating matchup.
  • davidthewatson 5y ago
    Having shared _exactly_ this kind of working relationship with several co-workers over the years, most of whom work at Google now, I'd argue that the problem comes down to counting things that don't count and the difficulty in counting things that actually do count, like execution, flow, shared mental model, vision, and ideation. There is a rhythm that arises from pairs work that I find much more peaceful than my own type-furiously-and-swear-vigorously personal style. I can work alone effectively being an introvert, but there is no question that the results and impact improve with a pair of talented co-workers who are mutually inclined toward pairs work. I don't think it has to be every time for everything, but when there is consensus on the approach, I see no reason to disallow it because some of the greatest achievements in science have come through this kind of collaboration. If it doesn't work for you, there's no reason to make individual, pairs, or mob programming the only way of working. It's a spectrum of work styles and that's OK.
• tweakimp 5y ago
  >>> Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up. In my experience, pair programming is really fun and helpful for some parts of my work, for example brainstorming solution ideas or finding bugs.
  • Veuxdo 5y ago
    > Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up. That's assuming two people pair programming would otherwise need to communicate about every individual line of code.
    • tremon 5y ago
      No, they would need to communicate about the ideas and thought processes behind every individual line of code. If not now, then the next time there's a bug in said lines.
      • falcolas 5y ago
        > ideas and thought processes behind every individual line of code I realize you're being hyperbolic (at least as hyperbolic as the parent), but this is one of the big hangups of pair programming for me: waiting for folks to get through boilerplate. Let's talk ideas and thought processes about the important (or at a minimum non-boilerplate bits of) code, not an entire programming session. "Alex, what were your thought processes that lead you to use 'i' for a loop variable?"
        • tremon 5y ago
          "Alex, what were your thought processes that lead you to a for loop here, rather than a {while loop/list comprehension/map operation/linq expression}?"
• pydry 5y ago
  >The output of pair programming must be greater than 2x the output of a single programmer to make sense. IME it does. Most of coding is identifying problems and two sets of eyes lets you hone in on the problems quicker. With design, two sets of eyes spots things that you will otherwise miss. Programming isnt chopping wood. If you're experience with it is that you're bashing out code like you're on a factory production line then something has gone wrong. >While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members. I've never seen this happen once. If somebody managed to write docs that correctly anticipated every potential question I'd be very surprised.
  • fsloth 5y ago
    >> there are more time and cost efficient ways to share knowledge between team members > I've never seen this happen once. Me neither. When you need pairing, it's super powerful and cannot be replaced. When you don't need it, don't do it.
• usrbinbash 5y ago
  IMHO, pair programming is a useful thing, but not for the reasons it's usually sold on. It is a really good oboarding vehicle. Pair an Experienced Dev and a new hire, and let the former guide the latter through the codebase. It also works great for implementing changes involving very complex parts of the codebase, usually the kind that interact with many different subsystems, which can get really tricky toget a good grasp on.
• nicodjimenez 5y ago
  Pair programming can be powerful with the right people and the right problem. It's a situational tool that can speed up progress in certain cases. Sometimes diving deeply into code is scary and having someone else right there can provide a feeling of safety that's conducive to making real progress. Also, sometimes programmers can have complimentary skills that can help them solve hard problems together on the spot. Pair programming sessions with the right people can also be intensely productive - people sometimes perform at a higher level when they're being watched. I've had very productive 3 hour coding sessions with team mates. What I don't like is weekly or recurring pair programming sessions. That's always a bad idea. Pair programming is a powerful tool but should be used judiciously and situationally.
  • Stratoscope 5y ago
    20 years ago I worked for Adobe on the Acrobat team. They brought me in because they needed some Windows expertise to help a team of talented developers who had mostly coded on the Mac. I don't think the term "pair programming" had been invented yet - at least I'd never heard of it - but when I was in the office I often spent a few hours a day on "house calls". People would ping me and I made the rounds advising them on Windows issues. It was focused time. No one needed my help much of the time, but when they did, we could work through a problem quickly and they would be better equipped to handle it on their own in the future. They always "drove", I just watched and discussed and helped troubleshoot. It was really great. As you said, what made it work was that I was there when someone asked for my assistance, not just because "pair programming" was the thing to do.
    • ehnto 5y ago
      I had a role as a mentor/go-to-guy for a complicated codebase and had a similar experience. I really enjoyed helping people out and loved the positive interaction, I would never have called it pair-programming and funnily enough we did have some kind of pair programming initiative at the time. If I were to give any advice to dev leads/teams/management that wants to introduce pair programming, it's good to put people of differing capabilities and expertise together. That way there's some value being added, and you're spreading around the arcane knowledge of your platform.
• konradb 5y ago
  One of the things I believe the author is missing is flow efficiency vs resource efficiency. To reduce handoff and waste, sometimes the utilisation of a single resource may go down.
• denton-scratch 5y ago
  Pairing with rotation results in a situation where everyone on the team is familiar with all the parts of the system. Apart from the bus problem, which is rather low-risk, it means that you don't have to wait for the expert in subsystem X to have finished what he's doing and move to the new task; everyone's a subsystem X expert. I don't think it's always worth pairing. Easy work that doesn't need expertise is best done solo. I acknowledge the "velocity" accusation; I've never seen a pair work faster than two skilled solo developers. But the quality of the output from a pair is generally a lot higher than that from a solo coder. It really does help to have someone looking over your shoulder. I've not seen a comparison of solo and pair velocity that takes into account code quality, and debugging and bug-fixing effort.
• JonChesterfield 5y ago
  Two keyboards, not one. As obvious as two chairs.
• ejb999 5y ago
  I've only used it once in my career, and at the time I was 'junior' to the other dev with the tools being used on a particular project (I was more senior/experienced than him overall though and had more produce expertise). Did it for a long week (about 80 hours actually) when we were under a very tight timeline to get a product out the door - I actually thought it was extremely effective and productive - gained months worth of learning in a very short timeframe. On the other hand, no way would I want to work someplace where it was assumed you would pair with someone all day every day.
• jll29 5y ago
  It depends on the people. Dean and Ghemawat at Google are so used to coding together that Wired wrote about them as if they are one person (hence hyphenated double name in the title): https://www.wired.com/dean-and-ghemawat/ https://www.wired.com/dean-and-ghemawat/ I can see where the author is coming from, but I have also had a few good pair programming sessions. Pair programming where one is more of a mentee instead of a reviewer should be useful to upskill the mentee so the pair are at more similar levels.
  • deleted 5y ago
    [deleted]
  • pyb 5y ago
    Indeed. In fact, following OP's logic gets absurd really fast : "Dean and Ghemawat would have been twice as productive if they'd worked each on their own! What a waste for the world !"
  • falcolas 5y ago
    > It depends on the people. Sounds like an exception, not the rule. At least, I've never seen two people who coded together all the time. Not in the 20 years I've been a software developer (in both startups and in BigCorpInc).
• lkois 5y ago
  I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two. We then spent every day of the next 2 weeks on near 8 hour videocalls developing some remaining features on his plate. It was an extremely effective knowledge transfer process. I learned plenty about this bizarre program and it's nonsensical logic, able to figure out future problems, and ended up as one of the main bits of glue keeping it all from collapsing. I also found it very rewarding to work that closely with a more senior developer, got a bunch of more general advice, had some interesting tangential discussions, and made a friend. Also got plenty of advice to leave the shitty company and it's terrible software asap. I dunno if I'd want pair programming day to day, but it was a great experience at the time, and made my entry to the role much smoother than anyone elses. The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it.
  • rr808 5y ago
    Nice. How do you sustain this for 8 hours a day though? After 45 minutes my brain starts to sag.
    • MattGaiser 5y ago
      Yep. If I have more than 2 hours of meetings in a day, I basically lose the entire day.
    • ehnto 5y ago
      Yeah I could never be on a video call for that long. There is a subprocess in my brain that starts running at 95% when I'm on a video call, like a kind of performance anxiety. I can deal with longer voice calls, but I can't really work during a call so it's only useful for syncing up. A call longer than an hour has probably become inefficient in some dimension.
    • MiyamotoAkira 5y ago
• Zigurd 5y ago
  This sentence can be (and has been in the comments) criticized from many angles: Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. I think it's bad because it shows a lack of understanding of metrics: The only valid productivity metric is code that works, and that everyone agrees does what it is meant to do. Code that does what it is meant to do without bugs is worth a lot more. Try quantifying that. I dare you. Counterbalancing that is time-to-market. Expedient hacks are worth a lot, too. That you can, sort of, quantify. Risk capital costs a lot more than cash flow. Do your coders understand that? Where to use pair programming? Probably not when you are racing to find product market fit. Possibly yes when you can lose existing customers due to a nasty bug (that may have root causes in early stage expedience). Avoid dogma.
• Veuxdo 5y ago
  Do other professionals do pair _______? Pair writing? Pair hairdressing? Like standups and pointing, it feels like a patronizing exercise we only force on devs.
  • gherkinnn 5y ago
    Absolutely. Penn and Teller develop their tricks together. Two-seater attack aircraft are a thing. Rally drivers have a driver and a navigator. Apprentices are taught in part through pairing. > Like standups and pointing, it feels like a patronizing exercise we only force on devs. There's truth in that. On one hand, many of our practices is formalised problem solving under the (non-)constraints of software. Others are cargo culted, clueless, patronising and painful.
    • Veuxdo 5y ago
      I think the difference is that the other activities you mentioned were execution/performance, while software development is a combination of engineering and creativity.
• stevage 5y ago
  Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc. > Pair programmers tend to give feedback that's more appropriate in a design or code review. What's his evidence? Why is it more appropriate there (after the code is written) than here (before/during)? > For the pairs that follow this, the only feedback that's left tends to be bikeshedding or stylistic, both of which kill velocity. That's, um, bullshit. Pair programming can pick up mistakes before they propagate, which increases velocity. > It's like having a backseat driver. I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver. > Alternatives like code reviews, design reviews, and general documentation are much better 1-to-n ways to share knowledge instead of 1-to-1. Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1. > In addition, most of these alternatives be done asynchronously. And this is better, because...?
  • toqy 5y ago
    > I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver. I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.
    • watwut 5y ago
      I don't think that is good analogy. Driving race with driver and navigator are in completely different then anything related to programming or even pair programming. That analogy is just yet another way how to shut up people who dont like the process.
      • travisjungroth 5y ago
        The way some people pair is really more similar to rally driving than you give it credit. I hate backseat driver style pair programming. Strong-style is very different and more like right-seat (I’m in the US, so let’s say not-driver seat) driving. https://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html?m=1 https://llewellynfalco.blogspot.com/2014/06/llewellyns-stron...
• lmilcin 5y ago
  Pair programming is exhausting and definitely not for everybody and for every single day. But. This is still the best way to exchange knowledge and produce code when normally you would need a code review. Pair programming is not a waste of time. It does not cost twice as much -- it actually costs less. It costs less because having another person working with you cuts all the procrastination and keeps things in focus. It costs less because now you have to discuss every part of the design with another person which is likely going to lead to better design. It costs less because if one person doesn't know it or spot it, the other person will. It costs less because you get immediate knowledge transfer and two people who can continue the project. Things can continue moving forward even if one person gets sick or leave the project. It costs less because people learn new stuff crazy fast when they can observe other person doing things they don't know. It costs less because actual people (like me) like to work with other people. It is fun. It costs less because code review is a shitty process where 99% of people fake they made a review and only pick on stuff that immediately stands out rather than actually trying to thoroughly understand and analyse the change. Unless you have a brilliant developer that can do everything by his/her own with no help or review. Consider yourself lucky.
• runarberg 5y ago
  Pair programming is a social event and should be employed when you want to have fun with your coworkers while doing work. As such pair programming is amazing. Sure you might write worse code and give/receive worse feedback but that is not the point. If you have fun with your coworkers while doing work, I would call that a net benefit.
• gherkinnn 5y ago
  Pairing has worked fabulously for me and I started this comment by refuting individual sections of the post. But I then got the feeling that the author doesn't personally get much out of pairing. And that's perfectly fine by me. Forcing it defeats the purpose. I wish Matt had argued from a general point and not a personal one. The latter would lead to more stimulating discussions. Skimming through his blog, I see a lot of interesting and succinct thoughts.
• midrus 5y ago
  The problem with pair programming, as with any other tool is when people read about it in a book and try to apply to 100% of the situations and the people as pure dogma. Several years ago I worked for a company where the "effective CTO" (he was not the CTO but given the CTO was remote (WTF!!) this guy acted as the intermediary) used to read TONS of books about XP, agile, scrum, team dynamics, programming paradigms, SOLID, design patterns, etc, etc and he *forced* every single f*ng thing he read about to everyone because "that's the professional way to do it". On the methodology front, pair programming was the worst part, as we were basically forbidden to work alone. He used to say stupid things (half kidding, half serious) such as "we should have one laptop every two developers". It was terrible. On the technical flank we ended up with a CQRS system passing messages between microservices on kubernetes and decoupled SPAs and a bastardised Python codebase that looked like Java and was the most unidiomatic python I've seen in my life, because hey, I've read the book of design patterns and object oriented programing 3rd edition. We were 5 devs. F*ng insane. So yes, a wrench can be an awesome tool to fix you car's motor, or could also be a weapon to hit somebody in the head and kill him. It's understanding the use cases and the situations what matters, not applying everything you read about as the definitive way to do it.
• candyking 5y ago
  I don't agree at all. The author only considers short term productivity and does not acknowledge the long term benefits of the skill sharing. Let's make up a metric, du (dev units), for how much a developer produces in a day, and let's say an average developer produces 100du per day. If we have two developers, Sally and Frank, producing 120du and 70du respectively. Short term, for these two people to pair program, the production of the pair programming has to be greater than or equal to 190du. But if we instead consider how productivity increase as experience grow, perhaps the next day, Frank will produce 80du and Sally 121du, then this is definitely worth it long term. I would agree with the author if the question was "ONLY pair programming" vs "ONLY individual programming", but that is a stupid question.
  • anthonygd 5y ago
    > I would agree with the author if the question was "ONLY pair programming" vs "ONLY individual programming", but that is a stupid question. I think there's some unstated context when people talk about pair programming. Everyone occasionally wants to pair (maybe not with the term though). Pair programming didn't have a name until it started being mandated. As soon pair programming gets a mandate of some sort (% of time, part of codebase, day of week...) it becomes a stupid mistake. It's pretty useful up until that point. Pair programming is like keyboards. I'm skeptical of anyone who brings up the topic: it doesn't need to be discussed.
• avereveard 5y ago
  > Let's start with the economics. Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. this is immediately wrong. since you're using only one computer and desk, the output can break even at less than 2x/pair, since you're not paying maintenance for double the space. the rest is absolutely missing any data backing it up, so it's completely pointless to argue about.
• rr808 5y ago
  I hate someone watching what I'm doing as often I'm trying things out and experimenting. However I've learned loads from watching others - usually its unrelated stuff like interesting tests, command line shortcuts, language features etc.
• yessirwhatever 5y ago
  The lack of understanding that this article shows about the author is just amazing. The dude looks to have extensive history in engineering and I don’t doubt that his experience can help in making him decide on what could work for him. But almost every one of his statements are not how one should think of pair programming, or is the purpose of it to generate > 2x value at all. Considering the potential technical debt that almost always amounts to a long debt repayment period (that is if even that’s possible) or that what works for one programmer may not work for others!
• _8j50 5y ago
  It's like discussing thought provoking topic while using the toilet. Just can't focus or do either things right.
• pyjarrett 5y ago
  I use pair programming from time to time when there's a subject matter expert who can provide assistance or clarification on something. However, I'm a super introvert and pair programming is absolutely exhausting for me. The notion that this should be done continuously doesn't account for the human factors involved. It's hard to communicate this to other people, but if I had to do this for 8 hours a day, 5 days a week, the stress would burn me out incredibly quick. I'd walk out the minute any company tried to impose this on me for even a couple days a week.
• shultays 5y ago
  In my experience putting two programmers on same task can even lead to less than 1x the output of a single person. People often argue about relatively pointless things while neither decision is not wrong. A single programmer would just go ahead and pick their own way and second one wouldn't consider it as important to raise during a review. Pair programming is great for new employees. But I am not sure either how much value they add over properly done design or code reviews when it comes to stability and putting two capable programmer on the same task sure sounds a waste of time. I think people that pairs up on same tasks/epics should try to work on different parts on parallel and try to sync up on what and roughly how they want to do stuff.
• sdiupIGPWEfh 5y ago
  I personally do not enjoy pair programming as a regular practice, but the focus here on performance is misplaced while the pedagogical benefits are swept under the rug. In exchange for some performance, I'd expect gains in team robustness. There are things you learn while participating in solving the problem that you'd never encounter during a design meeting or while doing code review. Subtler design problems and technical dead ends can be caught earlier and save substantial time over the typically async rejection process, leading to more productivity over a longer measure of time.
• the_af 5y ago
  As an introvert, I would have repeated what this article says point by point... ...until the pandemic hit. Now I work in a remote-first company. I have only met my team mates a couple of tines. We do all our collaboration online. And I crave pair programming. Slack isn't good enough, code reviews are welcome but not good enough either. I enjoy pairing over Zoom to get some things done. Not every thing, but more complex tasks: I need and want the pairing. Who would have thought?
• videlov 5y ago
  The case in support of pair-programming is the fact that feedback exchange happens early, while code is moldable. Compounding ideas and pooling knowledge is where collaboration really shines. There is of course the tradeoff that this way of working is inherently synchronous, taking away the flexibility of thinking about a problem at your own time. Developers have different cadences of coding/thinking, after all.
• treeman79 5y ago
  Having severe ADHD pair programming is flat out amazing for staying on task and being super productive. I don’t tolerate any medication at all for any length of time, nerve pain. although it does work wonders. So I can only use non-medication techniques.
• datavirtue 5y ago
  My idea of pairing is having two devs on the same feature or story. They don't nessesarily sit together coding at the same time but rather coordinate and possibly pair up when each gets stuck or is faced with a decision that they feel has longer range consequences. This ensures that multiple people are familiar with certain features or functionality and keeps the devs from feeling like they are siloed. It also ensures a steady march to done. However, each person is still on their own schedule for the most part.
• lbayes 5y ago
  Also, the learning process isn't one-way with junior & senior. I've been writing software since the mid nineties, and love pairing with junior devs. I almost always learn something new too.
• crisdux 5y ago
  I like these threads because I enjoy reading other people's experiences. The article in question is a fairly weak take down of pair programming, for many of the reasons others have stated. It just sounds like the writer doesn't really understand the point of it and enjoys working alone. Pair programming definitely has pros and cons. The teams I've been on in my company have been very deliberate about when and how we pair program. Most of my experiences have been positive, especially in person pair programming. Pair programming over video calls is much harder for me.
• eigenhombre 5y ago
  The last two places I've worked paired fairly heavily, perhaps 50% of the time, and on some squads mobbing has been popular as well. As an introvert, I prefer to go solo unless I'm working on something I know would benefit from additional knowledge or brainpower, but I've found pairing to be the single most powerful tool I know for training junior devs and for bringing people up to speed on code bases, languages, techniques, or business domains -- which is often quite important. There is undoubtedly a velocity cost in the short term, since ideally the junior person ("junior" here might be a senior person who is new to the code or the business) will "drive" (type) more, and some time is spent in the teaching. But the investment in higher overall knowledge of the team, and in catching bugs/avoiding dead ends early, tends to pay off. One subtle thing that takes time and practice is deciding when to stop pairing, because one or both of you needs a break, or time to think about the problem at one's own speed. I also think one can become over-reliant on pairing for learning. Personally I love reading (even printed books!) for learning languages, and writing for shaping thinking and capturing knowledge for future people. Not everyone loves these activities equally, but they are important skills for engineers to develop, and pairing is not a replacement for them. Finally, sometimes it's good to just go off and think for awhile.[1] [1] https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc
• marmarama 5y ago
  I've always done group working to some extent, especially where I need to work through an issue I've been stumped by, or where I need to bash out a consensus on a design. Similarly, I have always had other members of the team shadow me and work together to upskill them, let them gain confidence, and get ready to work with the training wheels off when I'm not there. Many times, they catch typos and silly errors that would otherwise have been missed until later, or possibly even not caught at all. But at the same time, I expect them to be building their skills and confidence so that they can be productive on their own, and to develop their own opinions so that they can challenge designs and approaches, and come up with their own. On many projects I have also had good experiences dividing up related work between different team members and checking back in a few times a day and comparing notes on how we're getting on, what we're finding difficult, and what we do where the related pieces of work touch each other. These approaches are so basic and so obvious, that I'm sure most of us have been doing them since we were teenagers at school doing group projects. But this isn't what "Pair Programming" is, or at least isn't the dogma that it has become in some organisations. The dogmatic version of it enforces working in pairs for all, or at least most of the day, no matter the personal preferences or personality types involved. It is exhausting for introverts and allows extroverts to dominate the work. It has strict rules about who is driving and who is navigating - or, more commonly, who is spectating. Even when regularly switching driver, a dominant personality normally emerges, and does the lion's share of the thinking. This means that, while the other member(s) of the pair or mob may absorb information quickly through osmosis, it takes them longer to form opinions of their own - instead they absorb the opinion of the dominant personality. This leads to groupthink and tunnel vision. While superficial flaws and errors are picked up quickly, larger issues are more easily missed without time for quiet reflection. It is especially difficult for those with weaker verbal communications skills, but who are still strong technically. Personally, my ego loves dogmatic Pair Programming because I am mostly an extrovert, enjoy dominating verbal conversation, and I like the attention. But enforcing it on a genuinely diverse team is bad news.
• werber 5y ago
  I love pair programming but remotely, with only audio. Live share in vscode, and jetbrains has their own version. The one keyboard paradigm is gone and you can work in two parts of the same code base at the same time. It’s not an all the time solution in my mind, but I frequently see higher quality code coming from these sessions with way smoother pr reviews. Just my two cents, as an introverted former pair programming hater (pre pandemic in the office).
• alistairSH 5y ago
  I never considered pair programming as a tool simply to increase raw velocity. For me, it's almost always been a pedagogical tool - it's an effective way to up-skill a developer who's learning (both young developers and experienced developers learning a new skillset). I would never force it on my team. But, given the task "teach Bob X", they often come to some form of pair-programming on their own. I usually only suggest it when learning becomes a roadblock.
• calsy 5y ago
  Pair programming stinks, always has always will. Its another mindless initiative managers come up with because some person in the organisation who subscribes to the Agile cult (there is always one) wont stop going on about it. Like most things Agile, it treats the developer as a child who cant be trusted to get things done. It's grade school where teacher tells you it's time for 'pair programming', yeahhhh. Usually it's at the worse possible time, and it's just another distraction in days filled with distractions that stop you doing anything meaningful. If people need to work together, they'll do it naturally like any ordinary adults who are asked to complete a task.
  • commandlinefan 5y ago
    > most things Agile, it treats the developer as a child Hey, don't blame "agile" for that - blame the bastardization of what managers who live to treat other people as children (or more likely as "subjects") have turned a decent concept into.
    • calsy 5y ago
      Agile is manager centric analytics tool that attempts to measure the ‘intangibles’ of development. This is done through rigid conformity to process. Excessive deliberation over design and breaking down of tasks gives the managers the info they need for the ‘higher up’s’ and the ability to better micro manager there subordinates. It’s brilliantly sold as a way to assist development, while focusing on the concerns of management.
• aerojoe23 5y ago
  As an industry we seem to think hard and make proclamations about programing. Where we should be thinking hard and making hypothesis and testing them. Turns out some people have been doing this and some people put it into a nice book. They conducted systematic reviews of the literature around many software development questions. The book (I know about anyway) is: Making Software: What Really Works, and Why We Believe It and Chapter 17 address pair programing. It has been a while since I read it, and it is a little thick to jump in and read it to make sure I'm 100% accurate ATM. But the summary I took away for my work environment is that, you get the same productivity with 2 devs working by themselves vs 1 pair, with a lower defect rate. I'd like to quote things directly but I'm not investing that much time right now. Pair programing IMHO is skill that needs to be learned, and it is a different skill depending on the type of pair you have at the time and what you're trying to do
  • shlurpy 5y ago
    Agreed. We've had an entire scientific revolution since the days of arguing about humans as a fatherless biped or the angels that can fit on a needle point. Articles like this that provide nothing but rhetorical arguments feel pointless in an era where tools like statistics and hypothesis testing exist.
• agentultra 5y ago
  I don't want to pair program full-time but this post is absurd. When I do pair program I find the process engaging. My partner is there to bounce ideas off of and the experience, for me, has generally been jovial. Code written in a pair programming session tends to get reviewed faster as it contains the assumptions and direction of more than one person on the team, leading to fewer surprises and questions. We're knowledge workers and sometimes having someone to bounce ideas off of and work alongside can be useful to get the creative juices flowing.
• rickmzp 5y ago
  I can't believe people are still posting this and giving this take any value...
• bluedino 5y ago
  Has anyone tried programming in a trio yet? If 2 is good, 3 must be even better.
  • commandlinefan 5y ago
    I think you're joking, but pair programming advocates are usually also "mob programming" advocates, too.
• IlliOnato 5y ago
  I don't have much experience with pair programming in general, but I have some in pair debugging. And in my experience, for a difficult debugging problem this pair debugging is a very powerful tool. It is hard to measure, of course, but I have strong feeling that the productivity of a pair is way more than a sum of individual productivity in such cases. I've seen bugs identified and fixed in hours, where both of the paired programmers believed it would take them days to fix if working alone.
• alediaferia 5y ago
  The main flaw behind this blog post is wanting to measure the effectiveness of a pair-programming activity as mere output
• commandlinefan 5y ago
  I did work for a few months in a dedicated "everything XP" shop that included religious pair programming. There were half as many computers as there were people, so we were forced, by design, to do pair programming. It broke down really fast. If one of us needed to read some documentation, the other one would just sit and chat while the first was trying to actually learn something. We'd have to take turns reading and responding to e-mail (sometimes we could work it around bathroom breaks... BTW, it gets uncomfortable when you know around what time another person uses the bathroom and how long it takes him). We had to make sure to take lunch breaks at the same times. Most of these pairs would end up getting off on discussion tangents and not get a whole lot done. I've seen some stupid management fads in my 30 years in this business, but pair programming is still by far the stupidest.
  • charcircuit 5y ago
    Can't one person read documentation on their phone?
• nine_zeros 5y ago
  I will start pair programming only when engineering managers and directors are mandated to sit in pairing sessions. I suspect that won't happen much. No one likes losing their own flexibility.
• mrtranscendence 5y ago
  I can understand that some people enjoy pair programming, and there are some situations like knowledge transfer where it may be appropriate. But I'm not sure it would fit with the way I solve problems. I don't know what I'm doing half the time -- I have to experiment and hit my head against the wall and continually inspect APIs in an IPython repl. I go back and forth between a console and a browser and emacs a mile a minute. When I've had to program with another person watching, my productivity screeches to a halt.
  • tlarkworthy 5y ago
    Maybe they will have some helpful suggestions or techniques that will speed up that process...
    • mrtranscendence 5y ago
      Maybe? But on the whole I tend to be pretty fast, just a bit hyperactive. I suppose I mostly feel as if pair programming would stifle the ability to experiment with every bit of code while I go, and cause me to have to plan everything out in a way that's unnatural to me. Maybe I'm wrong.
      • tlarkworthy 5y ago
        I find pair programming very good for transmitting workflow improvements. It's not the kind of thing that makes it to blogs
  • rngcntr 5y ago
    For me, experimenting, debugging and everything else that's basically try-and-error is actually where pair programming really shines. Most of our time is spent finding solutions to problems, even if it's just figuring out how to use an API. When we are working on a problem with two people at the time, we can carry on as early as the first of both figures out the solution. It's not about sharing a keyboard to write code together. Pair programming is about approaching development with two different ways of thinking.
• dkarl 5y ago
  > Pairs tend to devolve to least-common-denominator performance. Experts paired with novices need to move as slow as a novice. I think this misses a lot of the benefit of pair programming. The person with more experience on the project can point the other person directly to the places where it's natural to implement functionality, instead of the newbie having to scan through potentially the entire project structure so they can orient themselves. An expert can give a novice a heads-up about things they will be asked to change in code review, so they don't make the mistake in a dozen places and have to fix it a dozen times. Often pair programming happens because there's a mix of expertise -- there's a change that requires both familiarity with the project and a certain kind of technology expertise, so a junior programmer who knows the project pairs with an expert from another team, and the change gets done faster than either one could do it alone. Pair programming is also a great way to use excess capacity in a dev team. Martin Thompson points out in one of his talks that a system running at full capacity is slow and fragile, so you want your dev teams to work below capacity most of the time. Pair programming is a great way to improve quality and share knowledge, and when you have excess capacity, it's free!
• 5cott0 5y ago
  Pair programming is a very effective agile bodyshop sales ploy: twice the price for less than half the mediocrity.
• presentation 5y ago
  Pair programming has been great for me, for reasons other people said as well as the fact that it’s much easier to focus/not procrastinate when you keep each other to task.
• alfor 5y ago
  My experience is that pair programming is extremely efficient. I rewrote the firmware of a product with a college in two weeks that had taken years to do. I think the project would have failed without it. But it’s very tiring, you get rapidly exhausted at that level of concentration, there is a need to take breaks and to recharge by doing simpler task alone between sprints.
• tetraca 5y ago
  Pair programming should be another tool for your tool chest, not some religious orthopraxis that needs to be performed because some book told them it was good and so you should do the good thing all the time (and that is probably the root of all evil). There are a lot of times I've found pair programming very useful. Sometimes you just don't know why a behavior is happening and you need another set of eyes on it, or you kind of have an idea of what you need to do but the implementation is complex enough that it's not easy to keep everything in your own head anymore. We've saved a lot of time, many a time that way. But if the problem "clicked" already and I know what I need to do and where I need to go, it's just a waste of another person's time, and my own when I suddenly start making unusual mistakes because someone is looking over my shoulder. An experienced blacksmith can hammer out a fine knife in his sleep, but sometimes you're making armor for the King.
• davidrupp 5y ago
  Yet Another Introvert here. I paired full-time for three years when I worked at ThoughtWorks, and I did not enjoy the forced socialization aspect of it, but I can't think of a single day where I didn't learn something from my pair. We rotated pairs daily, and tried to keep one individual constant for the duration of a story (the "anchor") while rotating others through so we spread out context across the team. I once read a quote that I like to the effect of (paraphrasing, because I've lost track of the original): "Individual programming optimizes for the convenience of the individual; pair programming optimizes for the health of the team." This resonates with my experience of pairing.
• thiht 5y ago
  The author doesn’t understand what pair programming is about. It’s not about efficiency. It’s about sharing knowledge. The best pair programming was when I arrived on a new project and I paired on a big subproject with someone with domain experience. He could have done it way faster and I coul’ve worked on something easier. But in the end, I gained a lot of domain knowledge extremely fast, faster than any documentation would have allowed me to. That’s what pair programming is about.
• skeeter2020 5y ago
  > It's like having a backseat driver. I think it's like having a navigator in a rally car. Your pairing partner is both giving you timely input as you drive and looking ahead for upcoming issues. Also they literally or virtually sit beside you, not behind. If you are pairing for 2x output, you are doing it wrong. I think we SHOULD discuss if it's the best way to improve design, quality and share understanding and skill, but we can't do that from the position the author has staked out.
• dblohm7 5y ago
  As always, this is about nuance. Too many concepts are forced by management, instead of being organic. Organic pairing is awesome. Forced pairing is garbage.
• pictur 5y ago
  The worst of pair programming, in my opinion, is that people come to a consensus among themselves, as the author stated. at some point it turns into a mechanism where each group defends its own opinion.
• lainproliant 5y ago
  I like sharing ideas with someone while we're both coding together. I think "pair programming" works a lot better when two people sit down and work together on different parts of the same problem. Example: Alice is building the front-end for a product search page. Bob is building the product search APIs on the back-end. Alice and Bob working together can share immediate feedback on each other's designs and implementations, and work out any tiny ambiguities that weren't covered by whatever specification they previously agreed on. I think some of the best software dev experiences in my career have come from this style of collaboration.
• kraf 5y ago
  Funny, I often had the experience that code is done faster with a lot higher quality when people pair up.
• eyelidlessness 5y ago
  I don’t enjoy pair programming, primarily because it’s a lot of added cognitive load, and I’m already sensitive to that working solo. But one huge benefit of pairing which I think deserves more emphasis is that it gives each dev insight into how the other thinks about: the problem, the domain, design details which evolve during the process, risks/pitfalls, pretty much all of the stuff that can be more contentious or surprising in review. That said, a lot of that can also be had in interactive review, which I think people should do more often.
• nijave 5y ago
  >Experts paired with novices need to move as slow as a novice I actually find this to be highly effective for times experts aren't working at expert speeds. Sometimes you just get off a big project or have been heads down a couple days and it's nice to relax and talk things through with someone else writing code instead of trying to churn it out yourself. Likewise, novice and expert can be context dependent. Novice doesn't necessarily mean they can't write code but they might not be very familiar with the domain. The alternatives are read/write docs or have a meeting? The former is asynchronous so there will envitably be back and forth before the docs have useful info. The latter is similar to pairing except no code is being written and information is just being queued for use later
• stjohnswarts 5y ago
  If I hear pair programming is part of the job duties, that's the end of the interview for me full stop. I did it for years. Not a fan, probably an enemy. I know it can work for some personality types though.
• taylodl 5y ago
  I've been pair programming since the 80's - long before the practice had a name. Bottom line - pair programming creates a higher-quality result in less time. I can't state it any more succinctly than that. The higher-quality result bit is nothing to sneer at, either. Two minds are better than one. That means it's a better implementation having fewer bugs and fewer edge case surprises. These are things that all drive up software development costs. You know what's costly? Shipping buggy software. Especially back in the day when you had to distribute software via physical media that had to be shipped to the user. Things get even more complicated when the software is being used in a mission-critical process needing to run 24x7. Outage windows can be difficult to find. So sure, if you're creating software nobody really cares about because it really isn't critical to anything then I guess pair programming might be overkill. But who wants to work on such software?
• dennis_jeeves 5y ago
• girafffe_i 5y ago
  Empirical metrics would help. I personally love working with other people vs alone, but there's no meta-analysis of all the qualitative and quantitative netsum effects of it. Here's a random meta-analysis I found that looks at correctness, quality, and time https://www.researchgate.net/publication/222408325_The_effectiveness_of_pair_programming_A_meta-analysis https://www.researchgate.net/publication/222408325_The_effec... that found pair programming is "not uniformly beneficial" There's so many more variables that have more qualitative outcomes that make anecdotes baseless and throwaway. If you sit with people and share experiences, at some point you'll either click, or get so frustrated that you'll start being real and talk through frustrations to help you work with people better. The camaraderie or conflict resolution skills learned could have force multiplying effects latter. Who cares about efficiency, I like working with people and making friends at work. Why the hell do you want to work by yourself, especially remotely.