It’s not that terrible, usually… but it does come with some of the same embarrassment and pressure to perform as a live-coding interview. In a good environment with someone you can trust, that can spark results… but I completely agree that it’s not a comfortable thing to do or something I would want to do all the time.
So, I don’t think I’m a bad coder. I think I’m decent, maybe even good.
You make me live code in front of someone, I will forget how to type.
Plus, my usual creative process looks a lot like slacking off. I’ll browse something only tangentially related, get up and pace around, maybe bounce a ball on my desk for a bit…and then bust out a good amount of work. I feel like that would not be possible in a pair programming situation.
Seconding quad. I’ve had both exhausting and invigorating pair sessions, often with the same person on the same piece of work.
I identify entirely too much with your creative process, too. I push hard for regular breaks during pairing sessions (ideally at least every 45 minutes) so that I can have that “slacking off” behavior and because such heavy interpersonal interaction exhausts me.
Pairing is to coding what improv is to acting: It may look nigh-impossible from the outside, is surprisingly simple and yet deep from the inside, and can’t be sustained for more than short bursts.
My most creative work during my years of pairing was conceived outside of the pairing activity. I was and remain unable to think whilst pairing. I conceived of all my best work solo; I presented, improved, and made it whilst pairing.
I’m not convinced that this is something I could learn. Which is too bad, because I can definitely see that there could be benefits. But I find just being around people already exhausting if I have to do it for a whole day. It gets much worse if I also have to talk to them, so I don’t have much hope that a process like pairing would be easier. The pandemic caused a lot of hardship for a lot of people, but for me it was a godsend to work even more days at home than I already did.
For me it is not about being vulnerable. That’s something I learned over the years and now I don’t have a problem with that anymore. It is just that being engaged with someone else requires an incredible amount of energy that takes me a lot of time to recover from. I can do it and I like to do it, but my brain just has very limited capacity for that.
There is a middle ground though. I’ve found that it can be very enlightening if you set up a meeting with the person who is going to review your code when you’re still in the middle of the task. Show the rough sketches of your solution, have a relaxed back and forth on your work so far and possible alternatives. Just take some time (an hour, maybe two even) to have a laid back conversation, maybe type in some outlines and then continue on your own. Then you still have some of the the good parts of pairing, but none of the bad.
But I find just being around people already exhausting if I have to do it for a whole day. It gets much worse if I also have to talk to them, so I don’t have much hope that a process like pairing would be easier. The pandemic caused a lot of hardship for a lot of people, but for me it was a godsend to work even more days at home than I already did.
The pandemic normalized remote work at my place of employment to a point where they decided to make that a permanent part of the way we work even post-pandemic. To me that is a net win, and coupled with the exact same experience as you both I feel really bad when I think about how good this all has been to me (considering it’s an effing pandemic, I mean)
The author even points out that XP only says we should pair on production code. If you’re pairing 8 hours (or more!) per day, you’re being overworked and exploited, or you aren’t doing your whole job.
I have seen very few gigs where there isn’t at least an hour a day of email and other administrative tasks to do. Then there’s a lunch break, and bathroom breaks, trying out a new thing, reading some documentation, answering questions from colleagues.
If you’re pairing more than 4-6. hours in a given day, you aren’t doing your job as a software developer. You’re being exploited as a code typist.
Pivotal is well known for this kind of thing. They strategically schedule their “famous breakfast” to get people to show up earlier. And also strategically order not-quite-enough food so people are encouraged to show up early, so they get some.
When you “require” eight hours of pairing per day, you’re getting all of the administrative time “for free,” or you’re preventing your people from doing their whole job. It’s toxic, and the only thing I don’t understand is why some people are surprised at the burnout.
This is an excellent, empathic piece of writing. I cut my professional teeth in a strictly-XP pairing environment, but always working remote (shared tmux workplace). I even wrote a little thing on the topic of remote pairing, but this post really shines light on the totalitarian, cultish aspect of the practice when done in-person.
I think what made my experience pleasurable was that I was pairing with people who I considered (and still consider) close friends and mentors, making my workdays very enjoyable. I can imagine that having to pair program day-in, day-out with people you dislike really burns you out. Much like creating music, if you’re doing it with someone with whom you have some kind of emotional affinity, the process can continue fruitfully for a very long time. But you just can’t play/create well with people you feel antipathy for, it’s absolutely draining. At least in my experience.
The story of technology development has been engineers using some system to do something cool, then turning up the volume knob to 11 and beating the living hell out of it until they’re sick of doing it.
It occurs to me that instead of coming up with yet more examples of cool tools, processes, practices and such, it might be a lot better to come up with guidelines for when you’re taking one of these things too far. After all, that’s much more of a problem than missing something. We all have lots of things we can use for a problem. Very few of us have good metrics when to put something down and walk away from it.
I mean honestly, modern programming sucks. At the end of the day you’re just editing text. It’s a means to an end. If editing text didn’t give me power over nature I wouldn’t do it. It does a lot of damage to my brain and body. I have to fill my head with a bunch of bullshit (most of the time) and I have to stare at a LCD screen and put my arms in front of me for extended periods like I’m a T-Rex.
It’s basically the same thing as typing into a word document. Why don’t we see people pushing “pair typewriting” like they do with pair programming? Have somebody stare over the other person’s shoulder, telling them what to type paragraph-by-paragraph, pointing out typos and grammar errors along the way. Sounds like fun!
Yep. I turn off spellcheck when I write prose in order to avoid exactly that pain, saving it until after I’ve finished the drafting process. If one’s pair partner is working as a human linter and type system checker, though, that’s far worse. We have automated solutions for those problems. In a healthy pairing session the person at the keyboard is like a driver behind the wheel and their partner serves as the navigator. The latter shouldn’t be doing any work that a GPS can already do and they certainly shouldn’t be telling the driver how to turn the wheel or work the peddles. They can, however, look out for interesting road stops opportunities, update the GPS when plans or traffic change, research restaurant options on their phone, or simply rest their eyes until it’s their turn.
This complaint also reminds me of degenerate forms of tabletop roleplaying or collaborative board games: While nobody wants to have another player telling them exactly which moves to make in Pandemic, the game can turn euphoric when everyone’s actually collaborating. FOSS and Crafts just released an episode discussing exactly this.
Haha, I was reading your comment and thinking “neat, this sounds like the kind of thing we like to talk about on our podcast… zeitgeist!” And then you actually linked to that podcast episode! :)
Honestly I like working in groups of three or four better than in pairs. You can be in the background for part of the time while two others go back and forth; you can get up and leave for a bit without disrupting anything.
One-on-one situations are more stressful to me. I never get a break from being the direct focus of the other person’s attention.
This is so contextual. Generally my experience is the opposite, but only because my pairing sessions are voluntary, laid back, and last only as long as they need to be. I have never had a good experience with any kind of group programming beyond a pair. There is too much time wasted considering people’s feelings and negotiating social dynamics. A good pair can be intimate and almost as relaxed as programming solo.
All that said, I get how this is a very individual thing, influenced your own personality, the culture in which it takes place, and many more things, and it’s interesting how varied people’s experiences are.
It’s definitely a subjective experience. I think it’s important that teams be able to work out their own process to suit individuals’ needs, even discarding group work entirely if it’s not effective for them.
That said, I don’t think time spent considering your teammates’ feelings is wasted time. When social dynamics are recognized they can perhaps be addressed directly.
To clarify, I wasn’t saying considering people’s feelings is waste of time. It’s essential. My point is that managing the O(n^2) politics of a group – even a group of friends – while trying to do deep programming work just makes everything less effective. And, for me, a lot less fun. There is no amount of trust or addressing of issues that can minimize the dynamics to a point where it works harmoniously with the focus required to program well. Again, YMMV. This is just a subjective report and not a prescription.
I paired 40+ hours a week at ThoughtWorks for four years. That was five years ago now. I’ve given up the hope that I’ll get back to my past ability to self-regulate.
I’d be interested in hearing more about this as a current ThoughtWorker, though this already resonates with previous jobs that demonstrably burned me out.
As a developer who was basically “raised” on pairing I find it indespensible, but only when done with someone good at it otherwise I have to spend the time training them to pair (which training I am not good at…)
You can’t pair or mob and have it be healthy without psychological safety in the team environment. The people in the process have to believe it’s OK to take breaks, OK to make a mistake or show work in progress, OK not to know the answer yet, OK to experiment with the process and mutate it, OK to reject it outright having given it a try. A manager can’t just tell people to work in a group and expect anything better than your average group work in school.
I also just don’t see a great amount of value in pairing or mobbing with just other developers. The benefits are greater when it’s a cross-discipline group, and you can reduce handoffs by merging or overlapping stages of workflow.
I’m up far too late already or else I’d expound more, but programmers (and managers) have a lot they can learn from improv. Pair programming, mobbing, and soloing have direct parallels to acting: two-person improv is a different experience than group improv and both are radically different from free-form monologues.
What I’ve settled on as seeming to work best for me is: working solo by default, but pairing when help is needed on a specific problem. I could be giving or receiving the help. The pairing stops once the problem is solved, and sometimes even earlier than that (when a time box is agreed on by both parties, usually bounded by other calendar entries). The notion of pairing at all times by default doesn’t seem appealing, and, as this article argues, sounds like it’d be unhealthy.
Pair programming can be soul crushing, or it can be a pleasurable experience, but there’s no in-between. Unfortunately, it depends on how well the people mesh personality-wise. If you just throw two people together, it’s likely to be an absolute nightmare. It’s not a comfortable thing to do, like others have said, but if you pair with a developer who has empathy and patience, it can be an enjoyable experience.
I typically work solo, like a lot of people. At one employer when I was much more junior, we dabbled in pair programming. I was lucky enough to get with another person who was significantly older than me, but he was kind and willing to take the time to explain to me the things that flew right over my head. This was at a small startup, so we were fortunate enough to have a pretty strong camradarie.
At the larger orgs I’ve been at, we also experimented with pairing, and it absolutely failed. Personality conflicts were common, so we scrapped it in favor of solo development mixed with a healthy amount of Agile.
Pair programming was invented so that organisation can dispose of any one developer without fear of losing knowledge. The alternative is, of course, treating developers well so they don’t pull the rug from under you. But we all know that’s never an option.
The two times pairing is beneficial is when one person is bringing another person up to speed e.g. junior-senior. The other is when you really like the other guy, then it is just a lot of fun.
When you have a board of names of the manager just pull 2 names at random then you are in for some pain.
Pair programming sounds like absolute hell to me. I absolutely work best by myself, in a zone, and then with reviews or meetings later.
It’s not that terrible, usually… but it does come with some of the same embarrassment and pressure to perform as a live-coding interview. In a good environment with someone you can trust, that can spark results… but I completely agree that it’s not a comfortable thing to do or something I would want to do all the time.
So, I don’t think I’m a bad coder. I think I’m decent, maybe even good.
You make me live code in front of someone, I will forget how to type.
Plus, my usual creative process looks a lot like slacking off. I’ll browse something only tangentially related, get up and pace around, maybe bounce a ball on my desk for a bit…and then bust out a good amount of work. I feel like that would not be possible in a pair programming situation.
Pairing is hard— even “hell”— at first. It comes with practice. And it is entirely different than your (or anyone’s!) usual creative process.
Do it exclusively for years, it’s unsurprising that the skill to work solo atrophies.
Seconding quad. I’ve had both exhausting and invigorating pair sessions, often with the same person on the same piece of work.
I identify entirely too much with your creative process, too. I push hard for regular breaks during pairing sessions (ideally at least every 45 minutes) so that I can have that “slacking off” behavior and because such heavy interpersonal interaction exhausts me.
Pairing is to coding what improv is to acting: It may look nigh-impossible from the outside, is surprisingly simple and yet deep from the inside, and can’t be sustained for more than short bursts.
My most creative work during my years of pairing was conceived outside of the pairing activity. I was and remain unable to think whilst pairing. I conceived of all my best work solo; I presented, improved, and made it whilst pairing.
Pairing was an incredible boost for “my” output.
I’m not convinced that this is something I could learn. Which is too bad, because I can definitely see that there could be benefits. But I find just being around people already exhausting if I have to do it for a whole day. It gets much worse if I also have to talk to them, so I don’t have much hope that a process like pairing would be easier. The pandemic caused a lot of hardship for a lot of people, but for me it was a godsend to work even more days at home than I already did.
For me it is not about being vulnerable. That’s something I learned over the years and now I don’t have a problem with that anymore. It is just that being engaged with someone else requires an incredible amount of energy that takes me a lot of time to recover from. I can do it and I like to do it, but my brain just has very limited capacity for that.
There is a middle ground though. I’ve found that it can be very enlightening if you set up a meeting with the person who is going to review your code when you’re still in the middle of the task. Show the rough sketches of your solution, have a relaxed back and forth on your work so far and possible alternatives. Just take some time (an hour, maybe two even) to have a laid back conversation, maybe type in some outlines and then continue on your own. Then you still have some of the the good parts of pairing, but none of the bad.
Are you me? 🥺
I’ve worked from home for 10+ years. It’s great.
I do occasionally go work-from-restaurant with a friend (well, pre-COVID), to get some socialization.
If you’re ever in Austin, I’ll buy you a beer and enjoy hanging out for a bit…and then spend two weeks recovering from the interaction.
The pandemic normalized remote work at my place of employment to a point where they decided to make that a permanent part of the way we work even post-pandemic. To me that is a net win, and coupled with the exact same experience as you both I feel really bad when I think about how good this all has been to me (considering it’s an effing pandemic, I mean)
The author even points out that XP only says we should pair on production code. If you’re pairing 8 hours (or more!) per day, you’re being overworked and exploited, or you aren’t doing your whole job.
I have seen very few gigs where there isn’t at least an hour a day of email and other administrative tasks to do. Then there’s a lunch break, and bathroom breaks, trying out a new thing, reading some documentation, answering questions from colleagues.
If you’re pairing more than 4-6. hours in a given day, you aren’t doing your job as a software developer. You’re being exploited as a code typist.
Pivotal is well known for this kind of thing. They strategically schedule their “famous breakfast” to get people to show up earlier. And also strategically order not-quite-enough food so people are encouraged to show up early, so they get some.
When you “require” eight hours of pairing per day, you’re getting all of the administrative time “for free,” or you’re preventing your people from doing their whole job. It’s toxic, and the only thing I don’t understand is why some people are surprised at the burnout.
This is an excellent, empathic piece of writing. I cut my professional teeth in a strictly-XP pairing environment, but always working remote (shared tmux workplace). I even wrote a little thing on the topic of remote pairing, but this post really shines light on the totalitarian, cultish aspect of the practice when done in-person.
I think what made my experience pleasurable was that I was pairing with people who I considered (and still consider) close friends and mentors, making my workdays very enjoyable. I can imagine that having to pair program day-in, day-out with people you dislike really burns you out. Much like creating music, if you’re doing it with someone with whom you have some kind of emotional affinity, the process can continue fruitfully for a very long time. But you just can’t play/create well with people you feel antipathy for, it’s absolutely draining. At least in my experience.
The story of technology development has been engineers using some system to do something cool, then turning up the volume knob to 11 and beating the living hell out of it until they’re sick of doing it.
It occurs to me that instead of coming up with yet more examples of cool tools, processes, practices and such, it might be a lot better to come up with guidelines for when you’re taking one of these things too far. After all, that’s much more of a problem than missing something. We all have lots of things we can use for a problem. Very few of us have good metrics when to put something down and walk away from it.
I mean honestly, modern programming sucks. At the end of the day you’re just editing text. It’s a means to an end. If editing text didn’t give me power over nature I wouldn’t do it. It does a lot of damage to my brain and body. I have to fill my head with a bunch of bullshit (most of the time) and I have to stare at a LCD screen and put my arms in front of me for extended periods like I’m a T-Rex.
It’s basically the same thing as typing into a word document. Why don’t we see people pushing “pair typewriting” like they do with pair programming? Have somebody stare over the other person’s shoulder, telling them what to type paragraph-by-paragraph, pointing out typos and grammar errors along the way. Sounds like fun!
A lot of English is produced in a paired fashion, with people bouncing ideas back and forth as they commit them to the document.
Yep. I turn off spellcheck when I write prose in order to avoid exactly that pain, saving it until after I’ve finished the drafting process. If one’s pair partner is working as a human linter and type system checker, though, that’s far worse. We have automated solutions for those problems. In a healthy pairing session the person at the keyboard is like a driver behind the wheel and their partner serves as the navigator. The latter shouldn’t be doing any work that a GPS can already do and they certainly shouldn’t be telling the driver how to turn the wheel or work the peddles. They can, however, look out for interesting road stops opportunities, update the GPS when plans or traffic change, research restaurant options on their phone, or simply rest their eyes until it’s their turn.
This complaint also reminds me of degenerate forms of tabletop roleplaying or collaborative board games: While nobody wants to have another player telling them exactly which moves to make in Pandemic, the game can turn euphoric when everyone’s actually collaborating. FOSS and Crafts just released an episode discussing exactly this.
Haha, I was reading your comment and thinking “neat, this sounds like the kind of thing we like to talk about on our podcast… zeitgeist!” And then you actually linked to that podcast episode! :)
Honestly I like working in groups of three or four better than in pairs. You can be in the background for part of the time while two others go back and forth; you can get up and leave for a bit without disrupting anything.
One-on-one situations are more stressful to me. I never get a break from being the direct focus of the other person’s attention.
This is so contextual. Generally my experience is the opposite, but only because my pairing sessions are voluntary, laid back, and last only as long as they need to be. I have never had a good experience with any kind of group programming beyond a pair. There is too much time wasted considering people’s feelings and negotiating social dynamics. A good pair can be intimate and almost as relaxed as programming solo.
All that said, I get how this is a very individual thing, influenced your own personality, the culture in which it takes place, and many more things, and it’s interesting how varied people’s experiences are.
It’s definitely a subjective experience. I think it’s important that teams be able to work out their own process to suit individuals’ needs, even discarding group work entirely if it’s not effective for them.
That said, I don’t think time spent considering your teammates’ feelings is wasted time. When social dynamics are recognized they can perhaps be addressed directly.
To clarify, I wasn’t saying considering people’s feelings is waste of time. It’s essential. My point is that managing the O(n^2) politics of a group – even a group of friends – while trying to do deep programming work just makes everything less effective. And, for me, a lot less fun. There is no amount of trust or addressing of issues that can minimize the dynamics to a point where it works harmoniously with the focus required to program well. Again, YMMV. This is just a subjective report and not a prescription.
I paired 40+ hours a week at ThoughtWorks for four years. That was five years ago now. I’ve given up the hope that I’ll get back to my past ability to self-regulate.
It’s relieving to know I’m not the only one.
I’d be interested in hearing more about this as a current ThoughtWorker, though this already resonates with previous jobs that demonstrably burned me out.
As a developer who was basically “raised” on pairing I find it indespensible, but only when done with someone good at it otherwise I have to spend the time training them to pair (which training I am not good at…)
relevant story about guy steele pairing with rms: http://cycle-gap.blogspot.com/2007/09/extreme-pair-programming-guy-steele-and.html
Reminds me a lot of intense improv experiences. The mild-meld in those are surreal.
You can’t pair or mob and have it be healthy without psychological safety in the team environment. The people in the process have to believe it’s OK to take breaks, OK to make a mistake or show work in progress, OK not to know the answer yet, OK to experiment with the process and mutate it, OK to reject it outright having given it a try. A manager can’t just tell people to work in a group and expect anything better than your average group work in school.
I also just don’t see a great amount of value in pairing or mobbing with just other developers. The benefits are greater when it’s a cross-discipline group, and you can reduce handoffs by merging or overlapping stages of workflow.
Is “mob programming” a thing?
In Swedish, it would be a very unfortunate term as “mobbning” (mobbing) is the generic term for bullying.
It is a thing. As far as I know, the term hasn’t had a popular revision, but some Americans I know do feel that it needs one.
At my job we use the term “ensemble” to refer to working groups in which the members represent different specialties.
I’m up far too late already or else I’d expound more, but programmers (and managers) have a lot they can learn from improv. Pair programming, mobbing, and soloing have direct parallels to acting: two-person improv is a different experience than group improv and both are radically different from free-form monologues.
What I’ve settled on as seeming to work best for me is: working solo by default, but pairing when help is needed on a specific problem. I could be giving or receiving the help. The pairing stops once the problem is solved, and sometimes even earlier than that (when a time box is agreed on by both parties, usually bounded by other calendar entries). The notion of pairing at all times by default doesn’t seem appealing, and, as this article argues, sounds like it’d be unhealthy.
Pair programming can be soul crushing, or it can be a pleasurable experience, but there’s no in-between. Unfortunately, it depends on how well the people mesh personality-wise. If you just throw two people together, it’s likely to be an absolute nightmare. It’s not a comfortable thing to do, like others have said, but if you pair with a developer who has empathy and patience, it can be an enjoyable experience.
I typically work solo, like a lot of people. At one employer when I was much more junior, we dabbled in pair programming. I was lucky enough to get with another person who was significantly older than me, but he was kind and willing to take the time to explain to me the things that flew right over my head. This was at a small startup, so we were fortunate enough to have a pretty strong camradarie.
At the larger orgs I’ve been at, we also experimented with pairing, and it absolutely failed. Personality conflicts were common, so we scrapped it in favor of solo development mixed with a healthy amount of Agile.
Hey, a former co-worker! I wonder how many ex-pivots are here.
Several of us, I’d assume.
Pair programming was invented so that organisation can dispose of any one developer without fear of losing knowledge. The alternative is, of course, treating developers well so they don’t pull the rug from under you. But we all know that’s never an option.
The two times pairing is beneficial is when one person is bringing another person up to speed e.g. junior-senior. The other is when you really like the other guy, then it is just a lot of fun.
When you have a board of names of the manager just pull 2 names at random then you are in for some pain.
Also it saves money on
surveillance“employee performance monitoring” software, by having employees “monitor” each other.Is there an OS or IDE that lets two or more users with their own mice/kbds operate on the same desktop? It seems like that might help.
Never would I do that.