3 ms·

I worked on a team pair programming for about 3 years. I really enjoyed it. Now that I've moved on to a different company and am working solo again, I really mi

I worked on a team pair programming for about 3 years. I really enjoyed it. Now that I've moved on to a different company and am working solo again, I really miss pairing. I feel that most of the problems my team has now would be easily solved by pairing. Things like shared standards (not just syntax but architectural approaches that are hard to automate), testing (you keep each other honest), and faster code review. Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed. People don't have a good idea what anyone else is working on (beyond the few that seem to do most of the code reviews). Swapping pairs every day or two easily solves these problems. Things like on boarding new employees is just so much faster that it's a no brainer to pair, especially when they're starting out. Junior developers learn so much faster by working directly with a senior developer. Sure, it might slow the senior down (very little in my experience) but it makes the junior developer so much more productive in the long run. Pairing is mentally exhausting at first and I can understand that it isn't for everyone. Most people hate it at first, especially if they have a bad setup. Most people I work with seem to think it means 2 people crowded around a single laptop. Setting up real pairing station with multiple BIG monitors and 2 keyboards and mice is crucial. After you get comfortable with it, the "always on" feeling goes away and it just becomes an enjoyable day working closely with your colleagues. If you really give it time, I feel it's the "right" way to develop software. Switching a team to pairing might not be the right decision for everyone. Some people are just uncomfortable working with others. I'm not sure those people will be super strong members of most teams anyway, but they can certainly be successful in some organizations. If you build your team around pairing and select for it in your interview process, you can have really great results.

maxxxxx 8y ago
You are right, pairing often fails because companies don't bother to set up the right environment and processes and fine tune them. It's probably the same with things like scrum or remote work. They can work well if the company puts some honest effort into making them work. Most of the time they don't so everything falls apart though
latchkey 8y ago
This 1000 times. It should be the top comment on the page. The desktop setup is crucial. 90% of the time when I ask companies if they do pairing and I ask them to describe the setup, it is two people crowded around one laptop and that never works. I can't imagine watching someone type like that. I'd add a few other things that help a lot... a very good PM writing stories that pairs can pickup and run with (and a good management tool everyone knows how to use properly, like Pivotal Tracker), a Monday iteration planning meeting, a Friday retrospective (with whiskey!) and ping pong tables to blow off steam, as a pair. It sounds so cultish meta silly .com programmer... and it is... but it also works really well as long as the majority buys into it. One way I found to introduce this sort of system into a company is to just start with one pairing station (the computer setup described above). Tell people that when they want to pair, they can use it all they want. My experience is that soon enough, you'll be getting requests for more stations.
sanderjd 8y ago
Your experience is not universal. I paired for long enough to get comfortable with it. It never stopped stressing me out. I believe (and have years of performance reviews that suggest) I'm a very strong team member. But I work better asynchronously through text than synchronously through speech. It gives me time to get my thoughts in order before writing them down, rather than racing to simultaneously form thoughts and interject them into the flow of conversation. I believe all of the benefits you list are real, but that pairing is not the only way, and in my opinion not the best way, to achieve them (with the exception of on-boarding junior employees). I have found architectural standards to be well served by a lightweight design documentation and review process. This has the advantage that the design artifact continues existing somewhere, rather than just being a communicated consensus between pairing partners. People can be kept honest in testing through good code review. I don't think the goal of code review is to make it fast. I think of a good code review as an asynchronous low pressure pairing session. I'd like to just be happy for people to pair if they enjoy it, but sometimes it seems like advocates for pairing don't feel the same in the reverse. For instance, your reasonable seeming comment suggested that those of us who don't enjoy it so much are weak team members who should be weeded out during interviews.
wvenable 8y ago
> Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed. I think it's admirable to want to spread knowledge around as much as possible, I think having individual developers "own" specific applications or features is a net benefit. Sure if a developer leaves, they take their knowledge with him and someone else has to get up to speed, but that will necessarily happen anyway. There is only so much room in your brain; the more features or projects you work on, the less you remember about any of them. Being able to go to the feature X "guy" most likely means the problem will be solved significantly faster. That person's caches are already primed, the pages are loaded from disk, and they can hit ground running. That is a much better case to optimize for than the off chance somebody gets hit by a bus. We also know that multitasking is bad for productivity so the less people have to focus on the better.
- RandallBrown 8y ago
  I think what's really nice with pairing is that you can have feature ownership and spread knowledge really easily. The way I've done it in the past is that a feature will have an "anchor" or someone who owns it. They'll work on most of it and be in charge of interfacing with product on how it should work. That person would switch pairs every day, working with a few people who then pick up some of that context. Being hit by a bus is the classic example, but a more realistic one is that the person goes on vacation. Now, instead of just being 1 person with deep context on that feature, there's potentially a few others that will know it well enough to solve the problem. The people that are constantly switching will eventually own a feature and won't have to multitask all the time. Also, when you're pairing with someone, you get to share some of the focus with that other person, which I've found to make switching contexts a lot easier.
BurningFrog 8y ago
I'm in the same boat. After pairing for many years I've been soloing for a year now. It's been good in some ways to (re)learn to work on my own, but man, it's such a dumber, slower and duller way to work. I understand it's not for everyone, and that's perfectly fine. I just wish there was an easy way when job hunting to find the pair programming jobs! Why is it so hard??
ribs 8y ago
I loved pairing and I want to do it again. Now I work as a sales engineer and look at other peoples’ code all the time, but don’t write much myself. My personality seems to be one that gets more energy from interaction with other people. I think they call that extroversion. I’d imagine that for folks like me, pairing is great. It’s probably not that simple. But surely there are personalities that take well to it and those that don’t.

maxxxxx 8y ago

You are right, pairing often fails because companies don't bother to set up the right environment and processes and fine tune them. It's probably the same with things like scrum or remote work. They can work well if the company puts some honest effort into making them work. Most of the time they don't so everything falls apart though

latchkey 8y ago

This 1000 times. It should be the top comment on the page. The desktop setup is crucial. 90% of the time when I ask companies if they do pairing and I ask them to describe the setup, it is two people crowded around one laptop and that never works. I can't imagine watching someone type like that. I'd add a few other things that help a lot... a very good PM writing stories that pairs can pickup and run with (and a good management tool everyone knows how to use properly, like Pivotal Tracker), a Monday iteration planning meeting, a Friday retrospective (with whiskey!) and ping pong tables to blow off steam, as a pair. It sounds so cultish meta silly .com programmer... and it is... but it also works really well as long as the majority buys into it. One way I found to introduce this sort of system into a company is to just start with one pairing station (the computer setup described above). Tell people that when they want to pair, they can use it all they want. My experience is that soon enough, you'll be getting requests for more stations.

sanderjd 8y ago

Your experience is not universal. I paired for long enough to get comfortable with it. It never stopped stressing me out. I believe (and have years of performance reviews that suggest) I'm a very strong team member. But I work better asynchronously through text than synchronously through speech. It gives me time to get my thoughts in order before writing them down, rather than racing to simultaneously form thoughts and interject them into the flow of conversation. I believe all of the benefits you list are real, but that pairing is not the only way, and in my opinion not the best way, to achieve them (with the exception of on-boarding junior employees). I have found architectural standards to be well served by a lightweight design documentation and review process. This has the advantage that the design artifact continues existing somewhere, rather than just being a communicated consensus between pairing partners. People can be kept honest in testing through good code review. I don't think the goal of code review is to make it fast. I think of a good code review as an asynchronous low pressure pairing session. I'd like to just be happy for people to pair if they enjoy it, but sometimes it seems like advocates for pairing don't feel the same in the reverse. For instance, your reasonable seeming comment suggested that those of us who don't enjoy it so much are weak team members who should be weeded out during interviews.

wvenable 8y ago

> Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed. I think it's admirable to want to spread knowledge around as much as possible, I think having individual developers "own" specific applications or features is a net benefit. Sure if a developer leaves, they take their knowledge with him and someone else has to get up to speed, but that will necessarily happen anyway. There is only so much room in your brain; the more features or projects you work on, the less you remember about any of them. Being able to go to the feature X "guy" most likely means the problem will be solved significantly faster. That person's caches are already primed, the pages are loaded from disk, and they can hit ground running. That is a much better case to optimize for than the off chance somebody gets hit by a bus. We also know that multitasking is bad for productivity so the less people have to focus on the better.

RandallBrown 8y ago
I think what's really nice with pairing is that you can have feature ownership and spread knowledge really easily. The way I've done it in the past is that a feature will have an "anchor" or someone who owns it. They'll work on most of it and be in charge of interfacing with product on how it should work. That person would switch pairs every day, working with a few people who then pick up some of that context. Being hit by a bus is the classic example, but a more realistic one is that the person goes on vacation. Now, instead of just being 1 person with deep context on that feature, there's potentially a few others that will know it well enough to solve the problem. The people that are constantly switching will eventually own a feature and won't have to multitask all the time. Also, when you're pairing with someone, you get to share some of the focus with that other person, which I've found to make switching contexts a lot easier.

BurningFrog 8y ago

I'm in the same boat. After pairing for many years I've been soloing for a year now. It's been good in some ways to (re)learn to work on my own, but man, it's such a dumber, slower and duller way to work. I understand it's not for everyone, and that's perfectly fine. I just wish there was an easy way when job hunting to find the pair programming jobs! Why is it so hard??

ribs 8y ago

I loved pairing and I want to do it again. Now I work as a sales engineer and look at other peoples’ code all the time, but don’t write much myself. My personality seems to be one that gets more energy from interaction with other people. I think they call that extroversion. I’d imagine that for folks like me, pairing is great. It’s probably not that simple. But surely there are personalities that take well to it and those that don’t.