7 ms·

> Pair programming appears to management as a huge waste — two people doing 1 job! Sorry to play devil's advocate, but pair programming is literally two people

> Pair programming appears to management as a huge waste — two people doing 1 job! Sorry to play devil's advocate, but pair programming is literally two people doing a job that has traditionally/historically been done by one person. There is no surprise this is going to cause raised eyebrows with management. Two devs sharing a keyboard is 100% going to be seen as two people fulfilling a single person's job to nearly anyone external to the role for obvious reasons.

l0b0 3y ago
Another way to look at is is two people doing two jobs at the same time - programming and code review. Or even three jobs, if you include the (IME incredibly useful) design review which seems to happen almost inevitably as part of the implementation.
- tharkun__ 3y ago
  And it's incredibly one sided. If you and your peers like it, use it. I happen to hate it. Tried it at multiple companies and it still makes no sense to me. You are forcing two people to do a specific thing at the same time and pace. One of them has a meeting? Sorry can't do any work. Oh the other guy has a meeting after yours is done? Can't do any work. Oh one of them has a doctor's appointment? No coding. I prefer "the best of both worlds". Workshop/whiteboard the solution. Go separate ways if possible working on different parts of the problem. A great split is someone doing the frontend and the other doing the backend if that's the kind of thing you are working on. Or find some other way to parallelize. Reconvene after some hours/when you are done with something agreed upon or if "stuck". Not everyone likes 100% of the time social contact. Sometimes I just really need to be left alone in a corner, head down, no distractions.
  - twawaaay 3y ago
    Pair programming is definitely not for everybody. Some people hate it for multiple possible reasons -- because they can't focus with other person talking, because even if they stop talking the awkward silence is distracting, because they are distracted by their feelings about putting up half baked code and opening their development process to another person, etc. What I do is that I include pair programming as part of interview process to let people experience the process a bit before they decide to join the team. Can't do much about people who are already in the team -- I try to be flexible about it but only to some extent. In the end, being part of large software development project is a social endeavour, whether you like it or not. I get that some people prefer to work alone but I have to insist that social part cannot be somehow ignored.
    - JohnFen 3y ago
      > I have to insist that social part cannot be somehow ignored. Not doing pair programming doesn't mean the social part is ignored. It only means that the social part is done separately from the keyboard work.
      - twawaaay 3y ago
        By social part I don't mean socialising. I mean multiple people working together to achieve a business result being unable to work as mere robots following a procedure but rather working together as human beings with all consequences of it.
        JohnFen 3y ago
        Yes, I understood what you meant and was replying with that understanding.
    - tharkun__ 3y ago
      I agree that the working together in a team can not be ignored. You call it the social part, fair enough description, though easily confused with the socializing part. What 100% pair programming does however is to dictate exactly one way of achieving that goal. Like with any form of dictatorship, I think there is more harm than good in it. Pair programming in an interview would not be an issue for me for example. It is something that I do in some situations. Just two days ago, I had a PR comment from someone on how to do a part of what I was doing differently - and better. That was great but I wasn't sure how exactly it would play out and hadn't used that particular way of using the framework we're using. So I pinged him and we hammered it out together in 15 minutes of pair programming. Then he dropped off the call and kept working on his task while I cleaned up the mess of copy and pasted, commented out and `blah = newFunction()` type code we created in order to quickly figure out if "the other way" of doing things would work and if it actually was better. Coming back to the interview situation, we'd probably get along fine in pair programming that together and you'd want to hire me. And then you tell me that this is how I will be required to work 100% of the time and I'll end the interview right there.
  - JohnFen 3y ago
    Yes, I'm highly allergic to pair programming as well for a bunch of reasons. Fortunately, I've only rarely encountered it on the job. I can't seem to code and engage in an ongoing human interaction at the same time. It has to be one or the other. I also really hate having someone looking over my shoulder while I'm typing.
    - lcall 3y ago
      As am I. I guess it is related to having "Sensory Processing Sensitivity", a newer name for "Highly Sensitive Person", which basically means that one thinks deeply about everything all the time, whether they want to or not, and quick context changes (like having that train of thought interrupted frequently in pair programming) is highly disruptive. One TED talk about on youtube said it affects 1/5 people, even among animals, and it can't be changed, and has pros and cons.
      - JohnFen 3y ago
        > which basically means that one thinks deeply about everything all the time, whether they want to or not, and quick context changes (like having that train of thought interrupted frequently in pair programming) is highly disruptive. Wow, this is me. A friend once analogized it to being like a light source. I am a laser, deeply penetrating a narrow spot, but leaving the larger field in the dark while I do so. Other people are like a floodlight, illuminating a large area, but not deeply penetrating any particular portion of it. I always though of being like a laser as a kind of superpower, though, not a pathology. There are, naturally, advantages and disadvantages to each way of thinking. A good team needs both lasers and floodlights.
jvans 3y ago
my point is the literal interpretation doesn't come close to capturing the business value
twawaaay 3y ago
I have this conversation literally every single time I join a team. (I am tech lead and/or manager and it is usually my responsibility to shape the development process). People are definitely NOT taking twice as much time per-person to write a piece of code. First of all, code review is already a cost tacked onto development to ensure quality. So one could say code reviews are a waste of time. Well... not necessarily. It is always cheaper to catch and fix an error closer to the source of the error. When the error happens in prod it may be costing your company millions, but the same error caught in review may mean a cost of somebody's 1h review and half a day to fix it and then re-review it. So we are saying: it is better to spend a bit of extra effort upfront than let those quality problems spew uncontrolled into codebase and production environment. Naively, pair programming means one person writes the code and another "watches" and catches errors. But that's not what is happening. People discuss the course of action so you usually already get better result with two people doing it. Then there is the fact that if one person would get stuck it is usually much faster to get unstuck with another person involved. And you get other effects, too. For example, I find it impossible to procrastinate when working in pair with another person. It would be just disrespectful to the other person to be wasting time while we are both assigned and expected to produce results. All this means that not only the quality is better than if one person worked on it, but also the work progresses much faster. I would also suggest that in many businesses the most important factor is not development efficiency per se, but how fast can you deliver a given result. Meaning, if business figures out they want capability X, how fast you can provide it. To get to X you create a project with tasks. Any project will have critical path and adding more resources to the project will not speed up the project at all. The only way to speed up the project is to either change the critical path to a shorter one or speed up the tasks on critical path. There is normally very few ways to speed up development tasks. You can reassign them to your best/fastest devs. You can produce more technical debt. That's about it. So working in pairs offers an invaluable ability to speed up the development process without creating more technical debt and without using your critical resources. And yet another effect is scaling your development operations. Normally, adding more developers to the project creates more efficiency. Twice larger development team will not be twice more efficient. Working in pairs counteracts this problem a bit, ie. it lets the team be twice as large at the same level of efficiency/complexity. Any techniques that let you stave off the effects of growing organisation are very valuable.

l0b0 3y ago

Another way to look at is is two people doing two jobs at the same time - programming and code review. Or even three jobs, if you include the (IME incredibly useful) design review which seems to happen almost inevitably as part of the implementation.

tharkun__ 3y ago
And it's incredibly one sided. If you and your peers like it, use it. I happen to hate it. Tried it at multiple companies and it still makes no sense to me. You are forcing two people to do a specific thing at the same time and pace. One of them has a meeting? Sorry can't do any work. Oh the other guy has a meeting after yours is done? Can't do any work. Oh one of them has a doctor's appointment? No coding. I prefer "the best of both worlds". Workshop/whiteboard the solution. Go separate ways if possible working on different parts of the problem. A great split is someone doing the frontend and the other doing the backend if that's the kind of thing you are working on. Or find some other way to parallelize. Reconvene after some hours/when you are done with something agreed upon or if "stuck". Not everyone likes 100% of the time social contact. Sometimes I just really need to be left alone in a corner, head down, no distractions.
- twawaaay 3y ago
  Pair programming is definitely not for everybody. Some people hate it for multiple possible reasons -- because they can't focus with other person talking, because even if they stop talking the awkward silence is distracting, because they are distracted by their feelings about putting up half baked code and opening their development process to another person, etc. What I do is that I include pair programming as part of interview process to let people experience the process a bit before they decide to join the team. Can't do much about people who are already in the team -- I try to be flexible about it but only to some extent. In the end, being part of large software development project is a social endeavour, whether you like it or not. I get that some people prefer to work alone but I have to insist that social part cannot be somehow ignored.
  - JohnFen 3y ago
    > I have to insist that social part cannot be somehow ignored. Not doing pair programming doesn't mean the social part is ignored. It only means that the social part is done separately from the keyboard work.
    - twawaaay 3y ago
      By social part I don't mean socialising. I mean multiple people working together to achieve a business result being unable to work as mere robots following a procedure but rather working together as human beings with all consequences of it.
      - JohnFen 3y ago
        Yes, I understood what you meant and was replying with that understanding.
  - tharkun__ 3y ago
    I agree that the working together in a team can not be ignored. You call it the social part, fair enough description, though easily confused with the socializing part. What 100% pair programming does however is to dictate exactly one way of achieving that goal. Like with any form of dictatorship, I think there is more harm than good in it. Pair programming in an interview would not be an issue for me for example. It is something that I do in some situations. Just two days ago, I had a PR comment from someone on how to do a part of what I was doing differently - and better. That was great but I wasn't sure how exactly it would play out and hadn't used that particular way of using the framework we're using. So I pinged him and we hammered it out together in 15 minutes of pair programming. Then he dropped off the call and kept working on his task while I cleaned up the mess of copy and pasted, commented out and `blah = newFunction()` type code we created in order to quickly figure out if "the other way" of doing things would work and if it actually was better. Coming back to the interview situation, we'd probably get along fine in pair programming that together and you'd want to hire me. And then you tell me that this is how I will be required to work 100% of the time and I'll end the interview right there.
- JohnFen 3y ago
  Yes, I'm highly allergic to pair programming as well for a bunch of reasons. Fortunately, I've only rarely encountered it on the job. I can't seem to code and engage in an ongoing human interaction at the same time. It has to be one or the other. I also really hate having someone looking over my shoulder while I'm typing.
  - lcall 3y ago
    As am I. I guess it is related to having "Sensory Processing Sensitivity", a newer name for "Highly Sensitive Person", which basically means that one thinks deeply about everything all the time, whether they want to or not, and quick context changes (like having that train of thought interrupted frequently in pair programming) is highly disruptive. One TED talk about on youtube said it affects 1/5 people, even among animals, and it can't be changed, and has pros and cons.
    - JohnFen 3y ago
      > which basically means that one thinks deeply about everything all the time, whether they want to or not, and quick context changes (like having that train of thought interrupted frequently in pair programming) is highly disruptive. Wow, this is me. A friend once analogized it to being like a light source. I am a laser, deeply penetrating a narrow spot, but leaving the larger field in the dark while I do so. Other people are like a floodlight, illuminating a large area, but not deeply penetrating any particular portion of it. I always though of being like a laser as a kind of superpower, though, not a pathology. There are, naturally, advantages and disadvantages to each way of thinking. A good team needs both lasers and floodlights.

jvans 3y ago

my point is the literal interpretation doesn't come close to capturing the business value

twawaaay 3y ago

I have this conversation literally every single time I join a team. (I am tech lead and/or manager and it is usually my responsibility to shape the development process). People are definitely NOT taking twice as much time per-person to write a piece of code. First of all, code review is already a cost tacked onto development to ensure quality. So one could say code reviews are a waste of time. Well... not necessarily. It is always cheaper to catch and fix an error closer to the source of the error. When the error happens in prod it may be costing your company millions, but the same error caught in review may mean a cost of somebody's 1h review and half a day to fix it and then re-review it. So we are saying: it is better to spend a bit of extra effort upfront than let those quality problems spew uncontrolled into codebase and production environment. Naively, pair programming means one person writes the code and another "watches" and catches errors. But that's not what is happening. People discuss the course of action so you usually already get better result with two people doing it. Then there is the fact that if one person would get stuck it is usually much faster to get unstuck with another person involved. And you get other effects, too. For example, I find it impossible to procrastinate when working in pair with another person. It would be just disrespectful to the other person to be wasting time while we are both assigned and expected to produce results. All this means that not only the quality is better than if one person worked on it, but also the work progresses much faster. I would also suggest that in many businesses the most important factor is not development efficiency per se, but how fast can you deliver a given result. Meaning, if business figures out they want capability X, how fast you can provide it. To get to X you create a project with tasks. Any project will have critical path and adding more resources to the project will not speed up the project at all. The only way to speed up the project is to either change the critical path to a shorter one or speed up the tasks on critical path. There is normally very few ways to speed up development tasks. You can reassign them to your best/fastest devs. You can produce more technical debt. That's about it. So working in pairs offers an invaluable ability to speed up the development process without creating more technical debt and without using your critical resources. And yet another effect is scaling your development operations. Normally, adding more developers to the project creates more efficiency. Twice larger development team will not be twice more efficient. Working in pairs counteracts this problem a bit, ie. it lets the team be twice as large at the same level of efficiency/complexity. Any techniques that let you stave off the effects of growing organisation are very valuable.