7 ms·

Pair programming appears to management as a huge waste — two people doing 1 job!! — but having done both I believe the exact opposite. It increases bus counts,

by jvans 4y ago

Pair programming appears to management as a huge waste — two people doing 1 job!! — but having done both I believe the exact opposite. It increases bus counts, speeds up shipping code(no waiting for review), and improves quality. It is very difficult to ramp someone up on your hard problem you've been working on for days in a short time. If someone is there in the weeds with you, it's so much easier to talk it through. Pull requests degrade to nit picks that are irrelevant to code quality and code function to make the reviewer feel like they are contributing

peterangular 4y ago
> 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 4y 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__ 4y 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 4y 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 4y 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 4y 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 4y ago
        Yes, I understood what you meant and was replying with that understanding.
      - tharkun__ 4y 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.
- jvans 4y ago
  my point is the literal interpretation doesn't come close to capturing the business value
- twawaaay 4y 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.
rgblambda 4y ago
>to make the reviewer feel like they are contributing I swear maybe 50% of review comments are either to make the reviewer feel like they aren't a rubber stamp or just to signal that they actually read the PR.
JackMorgan 4y ago
I completely agree with you. The sad thing is I've almost always seen management understanding the value of pair programming, but the devs hate it. It's so rare to find developers who are willing to pair for even half the week.
dhab 4y ago
I agree. I am a dev, and I have done pair programming few times now. I am not sure I got the value that was hyped. I'd use that selectively on some nutty areas, and address things more broadly by introducing the "waste" of having to do code-review and KT later.

by jvans 4y ago

peterangular 4y ago

> 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 4y 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__ 4y 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 4y 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 4y 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 4y 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 4y ago
        Yes, I understood what you meant and was replying with that understanding.
    - tharkun__ 4y 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.
jvans 4y ago
my point is the literal interpretation doesn't come close to capturing the business value
twawaaay 4y 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.

rgblambda 4y ago

>to make the reviewer feel like they are contributing I swear maybe 50% of review comments are either to make the reviewer feel like they aren't a rubber stamp or just to signal that they actually read the PR.

JackMorgan 4y ago

I completely agree with you. The sad thing is I've almost always seen management understanding the value of pair programming, but the devs hate it. It's so rare to find developers who are willing to pair for even half the week.

dhab 4y ago

I agree. I am a dev, and I have done pair programming few times now. I am not sure I got the value that was hyped. I'd use that selectively on some nutty areas, and address things more broadly by introducing the "waste" of having to do code-review and KT later.