5 ms·

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 us

by 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.
- JohnFen 4y 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 4y 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 4y 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.

by l0b0 4y ago

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.
JohnFen 4y 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 4y 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 4y 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.