4 ms·

I used to think there was a lot of value in the concept of pair programming but I think the Pull Request and Code Review model is simply superior. It allows for

I used to think there was a lot of value in the concept of pair programming but I think the Pull Request and Code Review model is simply superior. It allows for a lot of the benefits of pair programming but with lower costs. I've always found that even looking over someone's shoulder to help debug something slows to a crawl. It takes more discipline than most engineers have to keep it truly paired.

djeikyb 9y ago
What kind of pair programming have you engaged in, beyond the "debug over the shoulder" scenario?
- snarf21 9y ago
  To be honest, it has been a while but I did try it for developing code. The main issue is that (not bragging) I was working with an older, more "senior" developer but I was a much stronger developer. When he was driving, he wouldn't really have a plan for what to work on next. Maybe it was someone looking over his shoulder, I'm not sure. He also had trouble following when I was driving even though I spent extra energy trying to explain what I was doing. As has been discussed, it takes a lot of discipline and matched skill levels and approaches to be successful (imo) and I think that is the exception not the rule. ymmv, so to each their own.
  - djeikyb 9y ago
    ymmv for sure. i suspect that pairing is far less valuable if not used in tandem with other XP techniques (eg tdd, ci/cd, continuous process). but certainly pairing isn't the One True Agile Way ;)
TheAceOfHearts 9y ago
I've had a occasionally successful pair-coding experiences, but I'd say I generally agree with you. Pull requests and code reviews have a lot of benefits. It lets the team work asynchronously, so you can collaborate more effectively with remote workers from around the world. As you make some changes, other people in your team might be interested in the reasoning which lead to that decision, and you can point to the pull request's discussion. In addition, it lets you think about the problem over a longer period of time, without putting anyone "on the spot"; sometimes you just need to let things stew for a bit.
rexpop 9y ago
> a lot of the benefits of pair programming So much of the work I do as a programmer does not go into the repository. Yeah, that's not ideal, but so much of the work I do is in the technique. In the keyboard shortcut, the ~/.bashrc, the discipline of red-green-refactor, of pomodoro. None of that stuff goes into the pull request, and yet all of it is something my programming pair can experience and learn from. And when I enter an area that's bizarre to me — when I am picking up a new language, a new tool or paradigm — a partner is 1000x more productive than my incessant slacking of code snippets when her explanations easily become demonstrations, and not least of all because it means that helping me is not an interruption to your KPIs. None of that comes across in a pull request. Maybe if your work exists entirely within code, within languages that you know, with build toolchains that are done changing, and you're entirely satisfied with your development environment, habits, and methods. In that case, yeah, CI and a little PR review are probably all you need. Meanwhile, pair programming actually decreases the discipline you need to be a good engineer.
- snarf21 9y ago
  I agrer that these things have value too but some places do Developer Share Sessions where one developer does a short presentation on a complicated subsystem or tools they use or a new api that needs integrated.
  - rexpop 9y ago
    That sounds terribly dull. Unlike during a programming exercise, there's no forcing function during a presentation that impels me to try and put this information in the right place in my mind. Certain note-taking strategies attempt to fabricate such a forcing function, but it's ersatz. Most of my notes during presentations or long-winded meetings boil down to "what motivated this presenter to speak?" or "why do I have to sit through this?"
mikekchar 9y ago
Pair programming is a skill. Some people do it very well. Some people do it very poorly. It is a skill you can get better at if you practice regularly and have good guidance from people with experience. I like pair programming -- though I personally prefer to do it remotely, believe it or not. I am never comfortable in other people's space (well, my wife being an exception, but I'm not willing to put in as much effort for a coworker ;-) ). Also, I have poor vision and I require a different setup on my computer than most people. Finally, I like being able to turn up or down the volume of the person I'm talking to (really, this is the killer feature for remote pairing). But you are right that it takes a lot of discipline. Usually when I get a new person, we start with ping-pong (I write a failing test, you make it pass, you write the next failing test, I make it pass, I write the next failing test, etc, etc). This gets you used to the idea that it is a collaboration, not a demonstration. Normally, switching "drivers" at most every 5 minutes is a good indicator of success. If you go more than 20 minutes with the same "driver", then you will almost always have problems. I refer to the "non-driving" partner as the "navigator". Imagine a rally car race. The driver is concentrating on keeping the rubber on the downward side and not running into a tree. The navigator is concentrating on what's coming up and giving useful guidance like "3rd gear. left turn". By separating the two tasks, the car can go significantly faster -- especially in rough terrain. In terms of programming, this usually comes out as descriptions of the next test, advice for refactoring, warning about YAGNI, keeping a todo list, etc. Normally the navigator should be giving short guidance, or asking quick questions. Occasionally the navigator should ask the question, "What are you doing?". If the driver goes silent, then it is up to the navigator to pull them out of their head. Sometimes the navigator or driver can not explain what they are thinking in words. In those cases, they should take control of the keyboard and sketch their thoughts in code. This should take no more than 5 minutes, generally. Many people I've worked with have difficult with pair programming. Usually these people have no trouble pairing with me. I don't say that to brag, it's just that it is a lot easier to pair with someone who has done it successfully for a long time (I started doing pair programming around the year 2000). Most of the problems I see come down to one or more of the following: - Personal problems between people. There are some people that don't get along (even some people don't get along with me ;-) ) Good programmers can mitigate this problem to a certain degree, but sometimes this requires an "organisational solution". Honestly, this is one of the best parts of pair programming because the hostility is going to come out one way or another. Making it obvious makes it easier to fix. - Vast differences in approach. Pair programming works dramatically better with TDD IMHO. It is really difficult to get a good rhythm without it (although I'm sure there are ways to do it -- I just don't know what they are). If you are pairing with someone who really dislikes TDD, you are probably going to have problems. This is one of the places where I will usually back off on the pair programming and suggest other kinds of approaches. - Experiential gaps. It is frustrating when your pair is sitting and looking at a blank screen with no idea what to do. It is equally frustrating when they start running off in a crazy direction because they don't know what they are doing. On the other side, it is often impossible to pair program with someone who charges ahead when you have no idea what's going on. It is embarrassing and frustrating to constantly have to ask them to stop and explain what they are doing. I could (and should) write a whole blog post about how to address these kinds of issues. The main thing is that you must hand over the keyboard every 5 minutes. If you do that, then the problems will become a lot more obvious. - Schedule conflicts. Get to work at 8:30. Coworker has slept in. Do some admin until 9:30 when the coworker shows up. But you aren't done, so you suggest that you start at 10. Coworker, gets grabbed by someone to look over a design and doesn't get back until 10:30. By then you have been asked to pair on a quick and urgent bug. At 11:00 you are both free. After you get the pleasantries out of the way, you start coding. You get 1 pomodoro done and it's 11:45. Your coworkers are yelling at you to run out to the burrito restaurant before it gets busy. You've worked 3 and a half hours and have done 1 pomodoro :-P Unfortunately you need to be really, really disciplined. Pairing starts on time and finishes on time. If someone is late, you make sure that you start ASAP. This takes a lot of practice. Finally, wrt to debugging, there are times when pairs should split. Debugging is usually one of them. It's another great reason to remote pair because it is trivial to split and then come back together again. As soon as you find the problem, you shout at the other person (or ping them on the computer) and you go back to pairing. Another time this happens is when you have to read documentation, or do google searches to figure out how to do the next bit. Having said that, if you spend any non-trivial amount of time debugging, then you are failing at TDD. I say this having written very, very large system before. You virtually never need to debug code that you have TDDed well, because you can write a failing test more easily (the only time you can't is when you can't reproduce the failure, which hopefully will be rare ;-) ). Of course, if you are dealing with legacy code (even if it's your own legacy!) that's of scant help -- so you will have to split to debug. But it should give you at least a small benchmark to see if your TDDing has been effective. Edit: formating
piva00 9y ago
No PR + Code Review process is going to help with the cognitive load of programming. When you begin to juggle multiple open files, moving program flows between them, rewriting or moving tests and methods, etc., those times when you are refactoring part of your architecture, for this kind of task I think there's no better tool than pair programming (or even mob programming) for example. Also you are right on it: it takes discipline. It's exhausting by the end of the day but some of my most productive days were after a 6 hours session of pure pair programming, while refactoring or splitting up a service that grew too big. Or implementing some convoluted business logic where my head couldn't properly hold all of the pieces together. I don't think PR + Code Reviews would help on those cases, if done properly it can probably come to the same end result but with a muuuch longer feedback loop.
Gonzih 9y ago
You can avoid a lot of back tracking that happens during PR process by just simple applying human contact and clear communication during the feature implementation. I really don't like when people who are unable to work with others force everyone in to asocial PR mindset.
firepoet 9y ago
I much prefer pair programming because: 1) I am sharing a thought process in-the-moment, and bringing my unique thoughts. This drives out a lot of the biases that engage when reviewing someone else's thinking after-the-fact. 2) Conversely with #1, my code is actually much better when I have paired with someone. They challenge me in-the-moment so I am able to have more powerful insights about what's a better way to go. I think better with someone who knows how to pair. 3) The results of a pair programming session are that both of us are intimately familiar with the codebase we just created. This is great for the business -- no silos. When I review someone's code, I have passing familiarity, but since I spent a fraction of the time with it, I haven't built up a strong memory stream of why, what, and how we built what we built. So if my partner or I end up needing to go somewhere else, there is no real hit to the organization. I feel like I brought a high level of professionalism and can leave with a clear conscience. And more. There really is no substitute that I've found.

djeikyb 9y ago

What kind of pair programming have you engaged in, beyond the "debug over the shoulder" scenario?

snarf21 9y ago
To be honest, it has been a while but I did try it for developing code. The main issue is that (not bragging) I was working with an older, more "senior" developer but I was a much stronger developer. When he was driving, he wouldn't really have a plan for what to work on next. Maybe it was someone looking over his shoulder, I'm not sure. He also had trouble following when I was driving even though I spent extra energy trying to explain what I was doing. As has been discussed, it takes a lot of discipline and matched skill levels and approaches to be successful (imo) and I think that is the exception not the rule. ymmv, so to each their own.
- djeikyb 9y ago
  ymmv for sure. i suspect that pairing is far less valuable if not used in tandem with other XP techniques (eg tdd, ci/cd, continuous process). but certainly pairing isn't the One True Agile Way ;)

TheAceOfHearts 9y ago

I've had a occasionally successful pair-coding experiences, but I'd say I generally agree with you. Pull requests and code reviews have a lot of benefits. It lets the team work asynchronously, so you can collaborate more effectively with remote workers from around the world. As you make some changes, other people in your team might be interested in the reasoning which lead to that decision, and you can point to the pull request's discussion. In addition, it lets you think about the problem over a longer period of time, without putting anyone "on the spot"; sometimes you just need to let things stew for a bit.

rexpop 9y ago

> a lot of the benefits of pair programming So much of the work I do as a programmer does not go into the repository. Yeah, that's not ideal, but so much of the work I do is in the technique. In the keyboard shortcut, the ~/.bashrc, the discipline of red-green-refactor, of pomodoro. None of that stuff goes into the pull request, and yet all of it is something my programming pair can experience and learn from. And when I enter an area that's bizarre to me — when I am picking up a new language, a new tool or paradigm — a partner is 1000x more productive than my incessant slacking of code snippets when her explanations easily become demonstrations, and not least of all because it means that helping me is not an interruption to your KPIs. None of that comes across in a pull request. Maybe if your work exists entirely within code, within languages that you know, with build toolchains that are done changing, and you're entirely satisfied with your development environment, habits, and methods. In that case, yeah, CI and a little PR review are probably all you need. Meanwhile, pair programming actually decreases the discipline you need to be a good engineer.

snarf21 9y ago
I agrer that these things have value too but some places do Developer Share Sessions where one developer does a short presentation on a complicated subsystem or tools they use or a new api that needs integrated.
- rexpop 9y ago
  That sounds terribly dull. Unlike during a programming exercise, there's no forcing function during a presentation that impels me to try and put this information in the right place in my mind. Certain note-taking strategies attempt to fabricate such a forcing function, but it's ersatz. Most of my notes during presentations or long-winded meetings boil down to "what motivated this presenter to speak?" or "why do I have to sit through this?"

mikekchar 9y ago

Pair programming is a skill. Some people do it very well. Some people do it very poorly. It is a skill you can get better at if you practice regularly and have good guidance from people with experience. I like pair programming -- though I personally prefer to do it remotely, believe it or not. I am never comfortable in other people's space (well, my wife being an exception, but I'm not willing to put in as much effort for a coworker ;-) ). Also, I have poor vision and I require a different setup on my computer than most people. Finally, I like being able to turn up or down the volume of the person I'm talking to (really, this is the killer feature for remote pairing). But you are right that it takes a lot of discipline. Usually when I get a new person, we start with ping-pong (I write a failing test, you make it pass, you write the next failing test, I make it pass, I write the next failing test, etc, etc). This gets you used to the idea that it is a collaboration, not a demonstration. Normally, switching "drivers" at most every 5 minutes is a good indicator of success. If you go more than 20 minutes with the same "driver", then you will almost always have problems. I refer to the "non-driving" partner as the "navigator". Imagine a rally car race. The driver is concentrating on keeping the rubber on the downward side and not running into a tree. The navigator is concentrating on what's coming up and giving useful guidance like "3rd gear. left turn". By separating the two tasks, the car can go significantly faster -- especially in rough terrain. In terms of programming, this usually comes out as descriptions of the next test, advice for refactoring, warning about YAGNI, keeping a todo list, etc. Normally the navigator should be giving short guidance, or asking quick questions. Occasionally the navigator should ask the question, "What are you doing?". If the driver goes silent, then it is up to the navigator to pull them out of their head. Sometimes the navigator or driver can not explain what they are thinking in words. In those cases, they should take control of the keyboard and sketch their thoughts in code. This should take no more than 5 minutes, generally. Many people I've worked with have difficult with pair programming. Usually these people have no trouble pairing with me. I don't say that to brag, it's just that it is a lot easier to pair with someone who has done it successfully for a long time (I started doing pair programming around the year 2000). Most of the problems I see come down to one or more of the following: - Personal problems between people. There are some people that don't get along (even some people don't get along with me ;-) ) Good programmers can mitigate this problem to a certain degree, but sometimes this requires an "organisational solution". Honestly, this is one of the best parts of pair programming because the hostility is going to come out one way or another. Making it obvious makes it easier to fix. - Vast differences in approach. Pair programming works dramatically better with TDD IMHO. It is really difficult to get a good rhythm without it (although I'm sure there are ways to do it -- I just don't know what they are). If you are pairing with someone who really dislikes TDD, you are probably going to have problems. This is one of the places where I will usually back off on the pair programming and suggest other kinds of approaches. - Experiential gaps. It is frustrating when your pair is sitting and looking at a blank screen with no idea what to do. It is equally frustrating when they start running off in a crazy direction because they don't know what they are doing. On the other side, it is often impossible to pair program with someone who charges ahead when you have no idea what's going on. It is embarrassing and frustrating to constantly have to ask them to stop and explain what they are doing. I could (and should) write a whole blog post about how to address these kinds of issues. The main thing is that you must hand over the keyboard every 5 minutes. If you do that, then the problems will become a lot more obvious. - Schedule conflicts. Get to work at 8:30. Coworker has slept in. Do some admin until 9:30 when the coworker shows up. But you aren't done, so you suggest that you start at 10. Coworker, gets grabbed by someone to look over a design and doesn't get back until 10:30. By then you have been asked to pair on a quick and urgent bug. At 11:00 you are both free. After you get the pleasantries out of the way, you start coding. You get 1 pomodoro done and it's 11:45. Your coworkers are yelling at you to run out to the burrito restaurant before it gets busy. You've worked 3 and a half hours and have done 1 pomodoro :-P Unfortunately you need to be really, really disciplined. Pairing starts on time and finishes on time. If someone is late, you make sure that you start ASAP. This takes a lot of practice. Finally, wrt to debugging, there are times when pairs should split. Debugging is usually one of them. It's another great reason to remote pair because it is trivial to split and then come back together again. As soon as you find the problem, you shout at the other person (or ping them on the computer) and you go back to pairing. Another time this happens is when you have to read documentation, or do google searches to figure out how to do the next bit. Having said that, if you spend any non-trivial amount of time debugging, then you are failing at TDD. I say this having written very, very large system before. You virtually never need to debug code that you have TDDed well, because you can write a failing test more easily (the only time you can't is when you can't reproduce the failure, which hopefully will be rare ;-) ). Of course, if you are dealing with legacy code (even if it's your own legacy!) that's of scant help -- so you will have to split to debug. But it should give you at least a small benchmark to see if your TDDing has been effective. Edit: formating

piva00 9y ago

No PR + Code Review process is going to help with the cognitive load of programming. When you begin to juggle multiple open files, moving program flows between them, rewriting or moving tests and methods, etc., those times when you are refactoring part of your architecture, for this kind of task I think there's no better tool than pair programming (or even mob programming) for example. Also you are right on it: it takes discipline. It's exhausting by the end of the day but some of my most productive days were after a 6 hours session of pure pair programming, while refactoring or splitting up a service that grew too big. Or implementing some convoluted business logic where my head couldn't properly hold all of the pieces together. I don't think PR + Code Reviews would help on those cases, if done properly it can probably come to the same end result but with a muuuch longer feedback loop.

Gonzih 9y ago

You can avoid a lot of back tracking that happens during PR process by just simple applying human contact and clear communication during the feature implementation. I really don't like when people who are unable to work with others force everyone in to asocial PR mindset.

firepoet 9y ago

I much prefer pair programming because: 1) I am sharing a thought process in-the-moment, and bringing my unique thoughts. This drives out a lot of the biases that engage when reviewing someone else's thinking after-the-fact. 2) Conversely with #1, my code is actually much better when I have paired with someone. They challenge me in-the-moment so I am able to have more powerful insights about what's a better way to go. I think better with someone who knows how to pair. 3) The results of a pair programming session are that both of us are intimately familiar with the codebase we just created. This is great for the business -- no silos. When I review someone's code, I have passing familiarity, but since I spent a fraction of the time with it, I haven't built up a strong memory stream of why, what, and how we built what we built. So if my partner or I end up needing to go somewhere else, there is no real hit to the organization. I feel like I brought a high level of professionalism and can leave with a clear conscience. And more. There really is no substitute that I've found.