5 ms·

Those 7 fears, most are false. Just remove the word "fear", some of them are true. > Fear that they don’t know what to code or where to start. Not really a bi

Those 7 fears, most are false. Just remove the word "fear", some of them are true. > Fear that they don’t know what to code or where to start. Not really a big deal, both don't know, and it's not about fear. Sometimes, we just laugh at each other, it's rather kind of funny. > Fear that others will laugh at their solutions. It's about one side blocks the other, make it slow, most of the time I have a good solution in mind already, but my politeness let the other runs, when he stuck I got a chance to interrupt "can we try this blah blah" and it's done this time. > Fear to don’t succeed in public. Not a big deal, no serious work is done during pair, it's for getting mutual understanding / agreement on something, just to make sure we are on the same page. The rest of work is done in isolate. > Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge. This one is true, I saw my team mate swam through randomly. It's ok, that's why pair programming is sometimes pointless. > Fear to change your mind in front of others. That's a sign of good thing is happening, something is getting more practical. > Fear to discuss and make decisions loud. People rather like this, shit talking like discussing works on tea table. > Fear of disagreeing with others. This is why pair programming is half-point, short-time debate is poor quality. Think longer, asynchronously, more research, and write disagreement in long form text .. on pull request.

elcomet 5y ago
> no serious work is done during pair I think that's the most important point you made. Pair programming is not for all programming, and in fact the goal is not to produce code. It's more about sharing thought processes with other people
- twic 5y ago
  When i've done pair programming, the goal was very much to produce code.
  - barrkel 5y ago
    The goal in sole programming is also to produce code. The value-add of pair programming is usually knowledge transfer, rather than code produced. And it's not just knowledge about the code being written, but work practices too.
    - twic 5y ago
      The goal of pair-programming in XP is to produce better code, faster. The idea that pair programming is mainly a teaching / learning mechanism is very widespread, but it's a profound misunderstanding.
      - barrkel 5y ago
        I don't honestly care tuppence for XP. It was an interesting revolutionary position in the mid 2000s, but an historical artifact now. I've never used pairing, nor seen it used, other than as a way of helping get someone up to speed on a task in an area or process unfamiliar to them.
    - regularfry 5y ago
      Not the way it's been sold to me. The goal is precisely to produce code, more effectively than two devs would individually, because a concurrent second pair of eyes avoids blind alleys and problems that would otherwise take a handoff to spot, and handoffs are efficiency tarpits. Knowledge transfer is an unavoidable beneficial side-effect, but it's not the point.
    - CRConrad 5y ago
      FWIW, although I only ever got to do very little pair programming (and it's long ago now), from all I heard about it (and the way it worked for us when we used it), I've got the same impression as regularfry and twic: It's at least as much about the actual code produced as any knowledge transfer. Seems to me that it has suffered the same fate as so many other original "Agile" practices: The image of them nowadays is gravely distorted, sometimes to the extent of being a caricature, of what they originally meant.
- dkersten 5y ago
  I had a very positive experience with pair programming on a project for about ten months. We (myself and one other guy) definitely did serious work. We built and delivered a complex piece of well tested software that is now running on aeroplanes (non safety-critical software). It was also a distributed system, adding to the complexity, where some parts run on AWS and some on the planes, communicating over satellite internet (which may or may not be available). We did it because we decided it would be the most effective way to work. There were only two of us on the project, so it was very important that both of us understood all aspects of the design and code. It was important to us that we spot issues early and that our test cases were comprehensive (we also used generative property-based testing to find actual bugs, which included simulating network errors, crashes etc). We designed on a whiteboard, then we would pair to implement it. We worked remotely about 50% of the time (using ScreenHero to do remote pair programming. I miss ScreenHero). Yes, the goal was to share thought processes, but it was also to produce high quality code, spot errors, come up with edge cases and tests. And to document everything. Personally, it was one of the most successful projects I ever worked on. The pair programming was exhausting, but very effective.
  - Existenceblinks 5y ago
    > We designed on a whiteboard I think this is where your impressive work is done, coding is just a chore, pair or not.
    - dkersten 5y ago
      I agree, I've commented this exact things on the Copilot discussions: that the actual programming isn't the hard part. Regardless, pairing helped us keep the code quality up and defects low, as well as making sure everything was properly tested and all corner cases were being dealt with. It of course also helped make sure we both understood every aspect of the code.
  - JasonCannon 5y ago
    We do mob programming at my company, but do so 100% remote. We do it via zoom for screen share, and use https://mob.sh/ https://mob.sh/ for handling the quick code handoff between drivers.
- Existenceblinks 5y ago
  I'll add more funny story to my own comment above. My boss usually pings me to do pair programing with him when: - He wanted to write some half-thought codes he also wants me as co-author to it (literally 2 names on git commit) - He wanted to do some dangerous things on production DB, he wanted me to be his witness, in case something went wrong, I would also share some guilt It's really funny I would call this "pair responsibility"

elcomet 5y ago

> no serious work is done during pair I think that's the most important point you made. Pair programming is not for all programming, and in fact the goal is not to produce code. It's more about sharing thought processes with other people

twic 5y ago
When i've done pair programming, the goal was very much to produce code.
- barrkel 5y ago
  The goal in sole programming is also to produce code. The value-add of pair programming is usually knowledge transfer, rather than code produced. And it's not just knowledge about the code being written, but work practices too.
  - twic 5y ago
    The goal of pair-programming in XP is to produce better code, faster. The idea that pair programming is mainly a teaching / learning mechanism is very widespread, but it's a profound misunderstanding.
    - barrkel 5y ago
      I don't honestly care tuppence for XP. It was an interesting revolutionary position in the mid 2000s, but an historical artifact now. I've never used pairing, nor seen it used, other than as a way of helping get someone up to speed on a task in an area or process unfamiliar to them.
  - regularfry 5y ago
    Not the way it's been sold to me. The goal is precisely to produce code, more effectively than two devs would individually, because a concurrent second pair of eyes avoids blind alleys and problems that would otherwise take a handoff to spot, and handoffs are efficiency tarpits. Knowledge transfer is an unavoidable beneficial side-effect, but it's not the point.
  - CRConrad 5y ago
    FWIW, although I only ever got to do very little pair programming (and it's long ago now), from all I heard about it (and the way it worked for us when we used it), I've got the same impression as regularfry and twic: It's at least as much about the actual code produced as any knowledge transfer. Seems to me that it has suffered the same fate as so many other original "Agile" practices: The image of them nowadays is gravely distorted, sometimes to the extent of being a caricature, of what they originally meant.
dkersten 5y ago
I had a very positive experience with pair programming on a project for about ten months. We (myself and one other guy) definitely did serious work. We built and delivered a complex piece of well tested software that is now running on aeroplanes (non safety-critical software). It was also a distributed system, adding to the complexity, where some parts run on AWS and some on the planes, communicating over satellite internet (which may or may not be available). We did it because we decided it would be the most effective way to work. There were only two of us on the project, so it was very important that both of us understood all aspects of the design and code. It was important to us that we spot issues early and that our test cases were comprehensive (we also used generative property-based testing to find actual bugs, which included simulating network errors, crashes etc). We designed on a whiteboard, then we would pair to implement it. We worked remotely about 50% of the time (using ScreenHero to do remote pair programming. I miss ScreenHero). Yes, the goal was to share thought processes, but it was also to produce high quality code, spot errors, come up with edge cases and tests. And to document everything. Personally, it was one of the most successful projects I ever worked on. The pair programming was exhausting, but very effective.
- Existenceblinks 5y ago
  > We designed on a whiteboard I think this is where your impressive work is done, coding is just a chore, pair or not.
  - dkersten 5y ago
    I agree, I've commented this exact things on the Copilot discussions: that the actual programming isn't the hard part. Regardless, pairing helped us keep the code quality up and defects low, as well as making sure everything was properly tested and all corner cases were being dealt with. It of course also helped make sure we both understood every aspect of the code.
- JasonCannon 5y ago
  We do mob programming at my company, but do so 100% remote. We do it via zoom for screen share, and use https://mob.sh/ https://mob.sh/ for handling the quick code handoff between drivers.
Existenceblinks 5y ago
I'll add more funny story to my own comment above. My boss usually pings me to do pair programing with him when: - He wanted to write some half-thought codes he also wants me as co-author to it (literally 2 names on git commit) - He wanted to do some dangerous things on production DB, he wanted me to be his witness, in case something went wrong, I would also share some guilt It's really funny I would call this "pair responsibility"