4 ms·

As a "senior" the thing I find about pair programming is that it forces code review - it's waaay too easy to blip over code in a review. It really is higher qu

As a "senior" the thing I find about pair programming is that it forces code review - it's waaay too easy to blip over code in a review. It really is higher quality code review but boy it smashes productivity with a frying pan and keeps hitting it. Pair programming - bad for startups that want to hammer out quick code, bad for enterprises that want to hit deadlines on stretched resources. It's a tough one to argue for. Edit: Things I want to try - Tennis Programming - sit next to each other, one writes the tests, one writes the code, swap round often, run on shared disk space or something. Spending ages watching someone else code is just being a human syntax checker. Swapping and diving in to code after ten minutes might be more interesting. It's like writing a joke or a scene in a movie then handing the paper to your writing partner. You need fast feedback.

Consultant32452 7y ago
I work for an enterprise and use pair programming sparingly. It's particularly useful with juniors who are eager to work hard but don't know how to think about writing software. It allows a fair amount of narration. I've mentored a few people this way and it resulted in their productivity and skill level skyrocketing. It's worth noting this never came from a top down mandate or anything. It's just one more tool in the tool belt. I think that's key to success, adapt to what works best on an individual level.
- lifeisstillgood 7y ago
  I see that as mentoring - really valuable for the team and the mentee, and more of a job for the mentor. I am reaching for something that actually rocket boosts both people in the pair (and implies some degree of equality of skill). I have had that experience a couple of times - basically lock good people in a room with a clear tight mission and keep distractions away. Building that in a cube farm with project reporting requirements is almost impossible...
Ididntdothis 7y ago
The tennis thing may actually work. You get quick review and if something is difficult you can do some pair programming.
zrail 7y ago
I’ve done ping pong / tennis programming before and it was honestly one of the most enjoyable experiences at that particular job. It helped that I was a junior developer pairing with one of the most senior developers at the company, who also happened to be very enthusiastic about what we were working on.
- craig 7y ago
  Yeah, I hadn't heard of that style before, it soundw really fun and seems like a good approach when you have a well defined feature you want to get done quickly.
cgarvis 7y ago
I used pair programming at a startup with a heavy junior engineering team. I loved it cause I could pair with any one of them and that “mentoring session” would be retaught without me having to do it. Our junior engineers progressed really fast in a short amount of time and I didn’t lose my mind having to reteach the same lessons over and over.
- flurdy 7y ago
  I find pairing works well for onboarding new members. Let them watch for a bit (no more than a few hours) to learn how things work. Then let them drive. Let them explore, make mistakes, but accomplish something and push to prod. This should make sure all the gaps get filled in quickly. And not 2 weeks later they still don't know how to connect to the database or something basic. Quickly the new members are full team members that can join the normal pairing schedule of the experienced team members.
hinkley 7y ago
It's good for transferring code ownership and development culture to a new maintainer, though. Writing very clear code is not just a skill but an investment in resources. There are diminishing returns (a couple of my employers have had a much lower pain-point than I do), and making it fairly clear followed by explaining the rest is usually more effective. Admitting a fault expresses empathy, and honesty, and sometimes inspires the other person to get invested by proposing a solution, and who wants code owners that aren't invested in the code? Besides, zero gotchas is perfection, and we all know what perfect is the enemy of. In scaling up a team, the alternative to getting new people to high competence on existing systems is to let them become highly competent on new systems. Over time though the old people only know the old stuff and the new people the new stuff, and eventually nobody knows what's going on. People only figure this out after the old people have already left. Old problems that haven't been fixed don't get talked about every day so it may be six weeks or a couple months before you figure out John was the only one who knew some bit of information and he's happy at his new job, and Sheila, the only other person who knew, has been gone for 8 months. And the person who wrote the thing just showed up on LinkedIn for getting a promotion at wherever they've been for 2 years. I wonder if they'd forward my resume to HR? I want the new guy to eventually be able to do everything I can do so that I don't feel guilty about wandering off to do something else, internally or externally. These people can also take over answering for old arguments that I'm tired of having. Being able to tag out on that sort of stuff does wonders for my sanity. I can certainly do all of this without pairing, but a lot of the time it's much faster and more illuminating for both of us. Especially when I can see how they stumble. Out of the mouths of babes, as it were. Maybe my assumptions were wrong. Maybe there's a simpler way to do this, or at least a more consistent one. Does that mean that I've occasionally been the Jim in "Why the hell did they lay Jim off?? We needed him." conversation? Yes, yes I have. But I can tell you, being laid off feels a lot better than going down with the ship. Survivor guilt, being the last employee who still knows how to do onerous tasks, wondering who'll be next, constant existential crises feeling like it's on you to save the ship... It's all awful, and much, much later you start to recognize the scar tissue. Lay me off with a nice severance while there's still some money and a sense of guilt left, please and thank you. If you don't see my value it's because you're too busy looking in the rear-view mirror rather than what to do next anyway.

Consultant32452 7y ago

I work for an enterprise and use pair programming sparingly. It's particularly useful with juniors who are eager to work hard but don't know how to think about writing software. It allows a fair amount of narration. I've mentored a few people this way and it resulted in their productivity and skill level skyrocketing. It's worth noting this never came from a top down mandate or anything. It's just one more tool in the tool belt. I think that's key to success, adapt to what works best on an individual level.

lifeisstillgood 7y ago
I see that as mentoring - really valuable for the team and the mentee, and more of a job for the mentor. I am reaching for something that actually rocket boosts both people in the pair (and implies some degree of equality of skill). I have had that experience a couple of times - basically lock good people in a room with a clear tight mission and keep distractions away. Building that in a cube farm with project reporting requirements is almost impossible...

Ididntdothis 7y ago

The tennis thing may actually work. You get quick review and if something is difficult you can do some pair programming.

zrail 7y ago

I’ve done ping pong / tennis programming before and it was honestly one of the most enjoyable experiences at that particular job. It helped that I was a junior developer pairing with one of the most senior developers at the company, who also happened to be very enthusiastic about what we were working on.

craig 7y ago
Yeah, I hadn't heard of that style before, it soundw really fun and seems like a good approach when you have a well defined feature you want to get done quickly.

cgarvis 7y ago

I used pair programming at a startup with a heavy junior engineering team. I loved it cause I could pair with any one of them and that “mentoring session” would be retaught without me having to do it. Our junior engineers progressed really fast in a short amount of time and I didn’t lose my mind having to reteach the same lessons over and over.

flurdy 7y ago
I find pairing works well for onboarding new members. Let them watch for a bit (no more than a few hours) to learn how things work. Then let them drive. Let them explore, make mistakes, but accomplish something and push to prod. This should make sure all the gaps get filled in quickly. And not 2 weeks later they still don't know how to connect to the database or something basic. Quickly the new members are full team members that can join the normal pairing schedule of the experienced team members.

hinkley 7y ago

It's good for transferring code ownership and development culture to a new maintainer, though. Writing very clear code is not just a skill but an investment in resources. There are diminishing returns (a couple of my employers have had a much lower pain-point than I do), and making it fairly clear followed by explaining the rest is usually more effective. Admitting a fault expresses empathy, and honesty, and sometimes inspires the other person to get invested by proposing a solution, and who wants code owners that aren't invested in the code? Besides, zero gotchas is perfection, and we all know what perfect is the enemy of. In scaling up a team, the alternative to getting new people to high competence on existing systems is to let them become highly competent on new systems. Over time though the old people only know the old stuff and the new people the new stuff, and eventually nobody knows what's going on. People only figure this out after the old people have already left. Old problems that haven't been fixed don't get talked about every day so it may be six weeks or a couple months before you figure out John was the only one who knew some bit of information and he's happy at his new job, and Sheila, the only other person who knew, has been gone for 8 months. And the person who wrote the thing just showed up on LinkedIn for getting a promotion at wherever they've been for 2 years. I wonder if they'd forward my resume to HR? I want the new guy to eventually be able to do everything I can do so that I don't feel guilty about wandering off to do something else, internally or externally. These people can also take over answering for old arguments that I'm tired of having. Being able to tag out on that sort of stuff does wonders for my sanity. I can certainly do all of this without pairing, but a lot of the time it's much faster and more illuminating for both of us. Especially when I can see how they stumble. Out of the mouths of babes, as it were. Maybe my assumptions were wrong. Maybe there's a simpler way to do this, or at least a more consistent one. Does that mean that I've occasionally been the Jim in "Why the hell did they lay Jim off?? We needed him." conversation? Yes, yes I have. But I can tell you, being laid off feels a lot better than going down with the ship. Survivor guilt, being the last employee who still knows how to do onerous tasks, wondering who'll be next, constant existential crises feeling like it's on you to save the ship... It's all awful, and much, much later you start to recognize the scar tissue. Lay me off with a nice severance while there's still some money and a sense of guilt left, please and thank you. If you don't see my value it's because you're too busy looking in the rear-view mirror rather than what to do next anyway.