3 ms·

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. Yo

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.
  - twawaaay 4y ago
    As a tech lead I am tasked with finding ways of organising development process to achieve the result the best way we can. At some point this has to result with dictating how people need to behave, what is expected of them. Unfortunately, giving people just the goal and no process to get there does not work. What does work is giving people progressively more freedom after they have shown this can at least potentially lead to better results. Taking away freedoms does not work -- people become resentful, demotivated and stop working. That's why demoting people very rarely leads to good results. Giving entire team complete freedom can work with highly selected individuals who are very committed and motivated to achieve the goal. But then the reason this can work at all is because they organise themselves and they honour their internally established constraints. But those circumstances are rare in large companies and building those teams is extremely difficult. I am not naive to think I can do it and even then I usually am given a team rather than given free hand to choose whatever people I want at whatever price I find necessary. I empathize with people who don't like being constrained in how they do work, I don't like it myself. But this to some extent is required to get a large organisation working. The best solution is to do your job well and show it is in everybody's interest to give you more freedom. > 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. And I think it is perfectly fine. This is the point of interviewing process -- for me to find if I can work with you and for you to find if you want to work with me. For my end I try to explain and demonstrate how it would look in reality. It costs me much more to hire somebody that will then be unhappy with the process. On a more personal level I am trying as much as I can to not hire people that I would have to soon fire. I hate firing people. And more than that I feel responsible for causing problem to a person that I could have prevented by not hiring them in the first place. So in a sense you breaking the interview is win win for both of us. Hopefully there would have been screening before the interview where you would learn a bit about how we work and you would leave the process with less disruption to both of us.
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.

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.
- twawaaay 4y ago
  As a tech lead I am tasked with finding ways of organising development process to achieve the result the best way we can. At some point this has to result with dictating how people need to behave, what is expected of them. Unfortunately, giving people just the goal and no process to get there does not work. What does work is giving people progressively more freedom after they have shown this can at least potentially lead to better results. Taking away freedoms does not work -- people become resentful, demotivated and stop working. That's why demoting people very rarely leads to good results. Giving entire team complete freedom can work with highly selected individuals who are very committed and motivated to achieve the goal. But then the reason this can work at all is because they organise themselves and they honour their internally established constraints. But those circumstances are rare in large companies and building those teams is extremely difficult. I am not naive to think I can do it and even then I usually am given a team rather than given free hand to choose whatever people I want at whatever price I find necessary. I empathize with people who don't like being constrained in how they do work, I don't like it myself. But this to some extent is required to get a large organisation working. The best solution is to do your job well and show it is in everybody's interest to give you more freedom. > 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. And I think it is perfectly fine. This is the point of interviewing process -- for me to find if I can work with you and for you to find if you want to work with me. For my end I try to explain and demonstrate how it would look in reality. It costs me much more to hire somebody that will then be unhappy with the process. On a more personal level I am trying as much as I can to not hire people that I would have to soon fire. I hate firing people. And more than that I feel responsible for causing problem to a person that I could have prevented by not hiring them in the first place. So in a sense you breaking the interview is win win for both of us. Hopefully there would have been screening before the interview where you would learn a bit about how we work and you would leave the process with less disruption to both of us.

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.