16 ms·

Pair programming is definitely not for everybody. Some people hate it for multiple possible reasons -- because they can't focus with other person talking, becau

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.
  - tharkun__ 4y ago
    Nice to be talking to a fellow tech lead then. I think dictating exactly how people need to work is counter productive if you work with highly skilled people. I like working with people that I can give a goal and we can talk about how to achieve it best together, try some things and see if it makes it better or not. E.g. we've tried pair programming in the team and most people didn't like it at all, just like myself. I am not going to force it on them. To your point, which is very valid, if someone did that to me after the fact, I'd quit. Personally I don't think the solution is to force every new hire to 100% pair program, while I myself would then not pair program when I do code. That sends the wrong signal. Do as I say not as I do. And yes that does mean I'm constrained in who I can hire or work with. Not everyone will "make it" on my team. E.g. as people progress I will progressively expect them to communicate about being stuck by themselves instead of me asking if any help is needed. They either learn how to do that and work in a team or they are not made for mine. A Senior Developer I need to nanny every 2 hours is not a Senior Developer. It doesn't mean we have zero process of course. I just don't believe in a process that enforces 100% pair programming ;)

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.
- tharkun__ 4y ago
  Nice to be talking to a fellow tech lead then. I think dictating exactly how people need to work is counter productive if you work with highly skilled people. I like working with people that I can give a goal and we can talk about how to achieve it best together, try some things and see if it makes it better or not. E.g. we've tried pair programming in the team and most people didn't like it at all, just like myself. I am not going to force it on them. To your point, which is very valid, if someone did that to me after the fact, I'd quit. Personally I don't think the solution is to force every new hire to 100% pair program, while I myself would then not pair program when I do code. That sends the wrong signal. Do as I say not as I do. And yes that does mean I'm constrained in who I can hire or work with. Not everyone will "make it" on my team. E.g. as people progress I will progressively expect them to communicate about being stuck by themselves instead of me asking if any help is needed. They either learn how to do that and work in a team or they are not made for mine. A Senior Developer I need to nanny every 2 hours is not a Senior Developer. It doesn't mean we have zero process of course. I just don't believe in a process that enforces 100% pair programming ;)