Pairing at Work: the Weaponization of Coder Vulnerability
May 12, 2021 8:37 PM Subscribe
What did we miss out on, by failing to make more space for people not to pair? By treating this pairing culture as something so fragile, and so precious? Pairing requires being vulnerable, to another human being, for hours at a time. Intimacy, both physical and mental. I had to share space, decisions, thought processes, and often feelings with this person.
via https://pinboard.in/popular/
I had no idea of the emotional costs of this coding methodology.
Also: "The Shame of Pair Programming" which explicitly invokes Brene Brown.
I had no idea of the emotional costs of this coding methodology.
Also: "The Shame of Pair Programming" which explicitly invokes Brene Brown.
During the pandemic, I've had to have a bunch of versions of this fight at my workplace - we're a small organization, and we do a lot of things well but something we do very badly is understanding the effect we have on people. We've lost a few really, really good people due to brain chemistry mismatch - not "they did something wrong", but "our demand that they behave in a neurotypical way burned them out and caused them to quit".
I am not without sin here - I've also been guilty of this with my team at various points in time, though I'm hoping that I've learned some lessons from it. My team, at least when we talked about this last, did indicate that this is the case - but it's also because of learning these lessons (and protecting my team from some "innovations") that I'm no longer the team lead of my team, and now we have two traditional managers instead (one project manager, one people manager) running things.
Pre-pandemic, this was something that was easier to manage, as mentioned in the article. Even for me, who's been WFH since 2016, the pandemic absolutely changed how I'm managed. In fact, the biggest flashpoint at my office was actually not pair programming, though it has been one, but rather cameras on zoom during company wide meetings - our honestly very nice, but very extroverted HR manager insists that she can't trust people if she can't see their faces reacting in the "right" way. This has been a flashpoint before - I've had multiple uncomfortable meetings with her that started off with "everyone is happy with your performance, and the clients love you, but I think you're doing badly at your job because of your face". Usually after I'd worked 18+ hours straight and was exhausted.
Because I'm one of the employees with the longest tenure, and because I am the lead for a significant money making product within our company, I get away with saying "no" to that a lot more than other people do. A lot of my role has become other members of my team having me throw myself in front of these busses for them, since I have the organizational capital to survive it, and they believe they don't - and I'm happy to do it, because it's important for our team that we can do our jobs.
But it's exhausting. I'm now honestly completely burned out from dealing with this mountain of "your team isn't neurotypical enough" problems from upper management. The fact I'm considering looking for a new job is not entirely unrelated to any of this.
(Note: My company is not all bad! In fact, they're a lot good! They said to me "why don't you just do WFH" when I moved to another country to be with my now-wife and was telling them I was panning to resign. And, in particular, when I became disabled by a chronic pain problem, they let me work part time, which I still do, 3.5 days/week. Most IT companies would not put up with any of that!)
posted by jaymzjulian at 9:00 PM on May 12, 2021 [28 favorites]
I am not without sin here - I've also been guilty of this with my team at various points in time, though I'm hoping that I've learned some lessons from it. My team, at least when we talked about this last, did indicate that this is the case - but it's also because of learning these lessons (and protecting my team from some "innovations") that I'm no longer the team lead of my team, and now we have two traditional managers instead (one project manager, one people manager) running things.
Pre-pandemic, this was something that was easier to manage, as mentioned in the article. Even for me, who's been WFH since 2016, the pandemic absolutely changed how I'm managed. In fact, the biggest flashpoint at my office was actually not pair programming, though it has been one, but rather cameras on zoom during company wide meetings - our honestly very nice, but very extroverted HR manager insists that she can't trust people if she can't see their faces reacting in the "right" way. This has been a flashpoint before - I've had multiple uncomfortable meetings with her that started off with "everyone is happy with your performance, and the clients love you, but I think you're doing badly at your job because of your face". Usually after I'd worked 18+ hours straight and was exhausted.
Because I'm one of the employees with the longest tenure, and because I am the lead for a significant money making product within our company, I get away with saying "no" to that a lot more than other people do. A lot of my role has become other members of my team having me throw myself in front of these busses for them, since I have the organizational capital to survive it, and they believe they don't - and I'm happy to do it, because it's important for our team that we can do our jobs.
But it's exhausting. I'm now honestly completely burned out from dealing with this mountain of "your team isn't neurotypical enough" problems from upper management. The fact I'm considering looking for a new job is not entirely unrelated to any of this.
(Note: My company is not all bad! In fact, they're a lot good! They said to me "why don't you just do WFH" when I moved to another country to be with my now-wife and was telling them I was panning to resign. And, in particular, when I became disabled by a chronic pain problem, they let me work part time, which I still do, 3.5 days/week. Most IT companies would not put up with any of that!)
posted by jaymzjulian at 9:00 PM on May 12, 2021 [28 favorites]
I just never really understood the emotional component of coding, and obviously, in hindsight, neurodiversity plays a big role in all of this. It feels like a book is going to drop any day now, 'The Emotional Coder." A proper post would have explored gender as well. And I just discovered Coding with Empathy. This is a good can of worms.
posted by mecran01 at 9:16 PM on May 12, 2021 [5 favorites]
posted by mecran01 at 9:16 PM on May 12, 2021 [5 favorites]
I’ve been self learning code for two or three years now and don’t even personally know a software developer. The isolation of coding on your own means a lot of reinventing the wheel, or following dead end design patterns. From over here, the experience of writing code collaboratively seems amazing, but stressful.
posted by iamck at 9:17 PM on May 12, 2021 [6 favorites]
posted by iamck at 9:17 PM on May 12, 2021 [6 favorites]
I knew this was going to be about Pivotal without even clicking! Better approaches to software engineering are interesting but this one always struck me as a bit cultish in how seriously they took it.
My problem is that these environments force people to consistently behave in a particular way, rather than using this as a tool for mentorship and building skills with the continuing consent of both parties.
Also, I just want to listen to death metal and read twitter sometimes...
posted by temancl at 9:23 PM on May 12, 2021 [3 favorites]
My problem is that these environments force people to consistently behave in a particular way, rather than using this as a tool for mentorship and building skills with the continuing consent of both parties.
Also, I just want to listen to death metal and read twitter sometimes...
posted by temancl at 9:23 PM on May 12, 2021 [3 favorites]
Pair programming became popular as an alternative to getting stuck in an infinity of dead ends and bad habits which only came back to bite you far enough in the future that your past self became some ignorant buffoon who deserved scorn. Effective pairing brings the "generate" and "edit/revise" stages of creation much closer together in time.
But again, it was an antidote for "ugh fuck it I'll hard code that for now..." and over time can become a supportive relationship because everyone needs an editor, those who believe they don't doubly so.
This is an article about mental illness and probably well-meaning but blinkered management monoculture. That is not a judgment on the piece, and pairing feels very uncomfortable for many engineers for many reasons. Those are not inherently invalid views, but can be hard to distinguish from distaste for a particular form of creative process that does not center the cowboy god-royalty of the solitary genius.
But this piece is about burn out, pairing is the stimulus that seems to incite the recoil response, not the cause. Presenting it otherwise is clickbait.
posted by abulafa at 9:33 PM on May 12, 2021 [11 favorites]
But again, it was an antidote for "ugh fuck it I'll hard code that for now..." and over time can become a supportive relationship because everyone needs an editor, those who believe they don't doubly so.
This is an article about mental illness and probably well-meaning but blinkered management monoculture. That is not a judgment on the piece, and pairing feels very uncomfortable for many engineers for many reasons. Those are not inherently invalid views, but can be hard to distinguish from distaste for a particular form of creative process that does not center the cowboy god-royalty of the solitary genius.
But this piece is about burn out, pairing is the stimulus that seems to incite the recoil response, not the cause. Presenting it otherwise is clickbait.
posted by abulafa at 9:33 PM on May 12, 2021 [11 favorites]
Thanks, I hate this!
This is the first time I (non-programmer) have read about this practice and I'm surprised by how violently averse even to thinking about it I am. This seems like an baroque means of mutual bullying. Makes me physically recoil. What difference is there in this to the kind of job where your boss watches you type over your shoulder, listens into your phone calls, and picks you up on all your spelling errors? There's a reason the Foucauldians say the things they do about the effects of hyper-surveillance on people's mental health!
Thinking of work in teams, the best teams work with communal and mutually understood practices. The opposite of 'pairing' isn't Godlike solo genius auterism, it's a healthy workplace of people thinking through the task. Pay attention to an experienced team of tradespeople and watch them anticipate each others' steps, but never, ever step on each others' toes.
posted by Fiasco da Gama at 9:45 PM on May 12, 2021 [10 favorites]
This is the first time I (non-programmer) have read about this practice and I'm surprised by how violently averse even to thinking about it I am. This seems like an baroque means of mutual bullying. Makes me physically recoil. What difference is there in this to the kind of job where your boss watches you type over your shoulder, listens into your phone calls, and picks you up on all your spelling errors? There's a reason the Foucauldians say the things they do about the effects of hyper-surveillance on people's mental health!
Thinking of work in teams, the best teams work with communal and mutually understood practices. The opposite of 'pairing' isn't Godlike solo genius auterism, it's a healthy workplace of people thinking through the task. Pay attention to an experienced team of tradespeople and watch them anticipate each others' steps, but never, ever step on each others' toes.
Programmers are supposed to be smart, really-crazy-smartAnd this is really the key point, isn't it, that working cultures create expectations of what people 'should' be? Most people—by definition—aren't extraordinary. It's incredible pretension for programming culture to pretend that its modes of production are somehow different and special, for unique people with special superpower intellectual talents, and it only serves profit. If you create systems that require extraordinary or 'extreme' practices for it just to work , you're not just setting up your systems to fail, but you're creating systems that push guilt for that failure onto the people trapped in them, and forced to fail. Now those, those I'm very familiar with, as is anyone who's worked the lunch rush of a fast food kitchen.
These forces were only tenuously under management control.Oh sure man. Sure.
posted by Fiasco da Gama at 9:45 PM on May 12, 2021 [10 favorites]
Pair program came to us largely from the “Extreme Programming” movement where it was coupled with the practice of working at a sustainable pace. The pace that they’re working in this programmer’s group is clearly not sustainable for them.
I’ve done a fair amount of pairing in my career and I wish I could do a lot more of it. It can be so joyfully, collaboratively creative and productive. It’s also totally exhausting. You really can’t be doing pairing and lots of overtime. For a given team and project, you might find that four or six hours a day is all you can do.
posted by chrchr at 10:04 PM on May 12, 2021 [15 favorites]
I’ve done a fair amount of pairing in my career and I wish I could do a lot more of it. It can be so joyfully, collaboratively creative and productive. It’s also totally exhausting. You really can’t be doing pairing and lots of overtime. For a given team and project, you might find that four or six hours a day is all you can do.
posted by chrchr at 10:04 PM on May 12, 2021 [15 favorites]
All of my pairing experiences have been all of the good things (and I'm fortunate enough to have generally only paired with people who didn't have massive egos and something to prove) -- but, it absolutely drains me. That sustained attention with little to no space for momentary lapses is one of the most psychically draining things I've ever done. If I'd attempted to do full time for even 6 months I think I would have been as burned out as the author. You know that feeling when you start a new job and you have to pay attention and make sense of EVERYTHING EVERYONE is telling you all day long, even while you're trying to piece together the context they have in their heads? It's a very similar feeling of exhaustion at the end of the day (at least it was for me).
My takeaway is that's it can be something enormously beneficial in small doses and when done for the right reasons. But treating it like a religion and making it obligatory sounds like expecting everyone to be running cognitive marathons day in and day out.
posted by treepour at 10:06 PM on May 12, 2021 [2 favorites]
My takeaway is that's it can be something enormously beneficial in small doses and when done for the right reasons. But treating it like a religion and making it obligatory sounds like expecting everyone to be running cognitive marathons day in and day out.
posted by treepour at 10:06 PM on May 12, 2021 [2 favorites]
If you create systems that require extraordinary or 'extreme' practices for it just to work , you're not just setting up your systems to fail, but you're creating systems that push guilt for that failure onto the people trapped in them, and forced to fail.There's a miserable twist - we-the-industry know that these practices aren't required for success, and in fact typically make succeeding (for any reasonable definition of "succeeding") harder.
We simply aren't very good at making complex systems (of any sort), and exceptionally bad at getting any better.
posted by nonlocal at 10:09 PM on May 12, 2021 [4 favorites]
Pair program came to us largely from the “Extreme Programming” movement where it was coupled with the practice of working at a sustainable pace.
One of the criticisms of the Extreme Programming movement is that all of it only seemed to work when you did all of it, which made it difficult to transition to and implied that it only worked for that team because of a specific combination of personality, management and project. (And maybe didn't work - it's notable that the project where XP was invented was terminated after seven years.)
The OP explains how pair programming encourages someone to work beyond a sustainable pace because it operationalises peer pressure.
posted by Merus at 10:49 PM on May 12, 2021 [2 favorites]
One of the criticisms of the Extreme Programming movement is that all of it only seemed to work when you did all of it, which made it difficult to transition to and implied that it only worked for that team because of a specific combination of personality, management and project. (And maybe didn't work - it's notable that the project where XP was invented was terminated after seven years.)
The OP explains how pair programming encourages someone to work beyond a sustainable pace because it operationalises peer pressure.
posted by Merus at 10:49 PM on May 12, 2021 [2 favorites]
This is super interesting. I'm not in tech, I was very tech interested then decided not to go that route at all for a variety of personal reasons that don't really matter.
But I work in a field that requires about of intense work with people and spend years learning how to do so safely, and effectively. It isn't pairing, social work is all power differentials, and I have whole tool sets around personal disclosure, and learning to do the intense focus that the article describes because it absolutely is a skill.
. I've trained students and provided professional clinical supervision to people trying to obtain their licensure, and both require moving people into a space where the reflective personal growth can happen to be a better more aware person. But it never would have the intensity of what is described for that significant period of time.
In those situations I've also spent tons of time specifically fostering an enviroment where that work can happen. I've intentionally built a safe place for self discovery when I've trained through a variety of intentional interactions over time with some very formalized wording and notes. I've also given students options to do that with someone else if needed. Even so, there is a ton of vulnerability in that. It is absolutely not intuitive and some people it can take a long time to get there, if at all. And really, for me the important thing is that the work happens, not that it happens with me, which is something I make clear.
Pairing like this would absolutely wreck me. The skills around when to break are just as important as when to pair, and understanding that these should be intentional moments with intentional goals is vital. Relationships are complicated. Corporate pairing inherently has power structures built in, without any of the tools to navigate AND with the threat of loss of employment or some other discipline action if not successful. I guarantee power differentials impact the pairing experience, and that there aren't formalized structures to acknowledge and handle those dynamics at play.
Also the lack of understanding just the differences in human personalities and sensory needs? You do not have to move into anything nonnuerotypical to find people who absolutely could not do this work and would need time to just be alone. Or couldn't pay attention in the way that partners need, it couldn't utilize the time in an effective manner.
Pairing like this is a work construct, and in this cases it needs very clear bounds. Yeah there is some vulnerability in working closely with another, and yet at the same time there should absolutely be clearly defined ways to sort out specific differences without it being about the self? Needing time alone, or needing to be respected, or having limits to attention span aren't vulnerabilities? Approaching things from different ways is part of what makes people human? If you are not starting with a foundation that is affirming of differences and aknowedging that , and tools to work through that stuff, then pairing can't be successful overall.
posted by AlexiaSky at 10:54 PM on May 12, 2021 [6 favorites]
But I work in a field that requires about of intense work with people and spend years learning how to do so safely, and effectively. It isn't pairing, social work is all power differentials, and I have whole tool sets around personal disclosure, and learning to do the intense focus that the article describes because it absolutely is a skill.
. I've trained students and provided professional clinical supervision to people trying to obtain their licensure, and both require moving people into a space where the reflective personal growth can happen to be a better more aware person. But it never would have the intensity of what is described for that significant period of time.
In those situations I've also spent tons of time specifically fostering an enviroment where that work can happen. I've intentionally built a safe place for self discovery when I've trained through a variety of intentional interactions over time with some very formalized wording and notes. I've also given students options to do that with someone else if needed. Even so, there is a ton of vulnerability in that. It is absolutely not intuitive and some people it can take a long time to get there, if at all. And really, for me the important thing is that the work happens, not that it happens with me, which is something I make clear.
Pairing like this would absolutely wreck me. The skills around when to break are just as important as when to pair, and understanding that these should be intentional moments with intentional goals is vital. Relationships are complicated. Corporate pairing inherently has power structures built in, without any of the tools to navigate AND with the threat of loss of employment or some other discipline action if not successful. I guarantee power differentials impact the pairing experience, and that there aren't formalized structures to acknowledge and handle those dynamics at play.
Also the lack of understanding just the differences in human personalities and sensory needs? You do not have to move into anything nonnuerotypical to find people who absolutely could not do this work and would need time to just be alone. Or couldn't pay attention in the way that partners need, it couldn't utilize the time in an effective manner.
Pairing like this is a work construct, and in this cases it needs very clear bounds. Yeah there is some vulnerability in working closely with another, and yet at the same time there should absolutely be clearly defined ways to sort out specific differences without it being about the self? Needing time alone, or needing to be respected, or having limits to attention span aren't vulnerabilities? Approaching things from different ways is part of what makes people human? If you are not starting with a foundation that is affirming of differences and aknowedging that , and tools to work through that stuff, then pairing can't be successful overall.
posted by AlexiaSky at 10:54 PM on May 12, 2021 [6 favorites]
Doing something badly doesn’t work out well. A development process that’s poorly implemented and burns people out also doesn’t work well. Focusing on the process more than the results doesn’t work well and goes against the principles of agile development. How are people still surprised about these things?
I started doing pair programming and paired dev/test in 1997 and I’ve found it to be a valuable skill ever since. It’s not always the right way to find a solution and it doesn’t have to be. It doesn’t have to be the way everyone works, though I think there is tremendous power in the openness and discovery when there’s support and kindness. Work with jerks and you’re going to have a bad time, no matter the process.
posted by Revvy at 11:00 PM on May 12, 2021 [2 favorites]
I started doing pair programming and paired dev/test in 1997 and I’ve found it to be a valuable skill ever since. It’s not always the right way to find a solution and it doesn’t have to be. It doesn’t have to be the way everyone works, though I think there is tremendous power in the openness and discovery when there’s support and kindness. Work with jerks and you’re going to have a bad time, no matter the process.
posted by Revvy at 11:00 PM on May 12, 2021 [2 favorites]
it's notable that the project where XP was invented was terminated after seven yearsThat is a wildly successful project lifetime in programming.
Other systems that productively operationalize peer pressure: civil society.
I'm not exaggerating, programming solo can truly be a godlike act of creation (or feel like one because of both the flexibility and enormity of potential solutions to any given problem). Positive, editorial pressure to not cut that corner or at least stay honest and come back to that thing you hacked creates better, more readable and maintainable work.
A lot of the complaints about this method sound like they arise from a level of perceived personal autonomy and infallibility that really deserves some introspection. Of course it's exhausting - doing it as the only way six plus hours a day is fucking cultish insanity - and so is a Stepford neighborhood of contrived peer pressure to cut your lawn the same way.
But standards of treating others fairly and picking up after your dog are also operationalized peer pressure applied with generally positive outcomes.
Operationalizing cultism in pursuit of money is bad. Operationalizing peer pressure to make better code by spreading the hard creative and analytic work required for some parts of programming is way better than what it replaced, which was often essentially hope you hire the right creators and spend lots on QA to find out if you gambled well years down the line.
posted by abulafa at 11:05 PM on May 12, 2021 [7 favorites]
> One of the criticisms of the Extreme Programming movement is that all of it only seemed to work when you did all of it
AlexiaSky explains why this is pretty well. You have to change the power structures and social dynamics in the office to something else for it to work. Everyone who tries to manage creative people figures out similar lessons don't they? "Hmm, as long as they *want* to get this done it seems like the more we micro-manage we worse things go ... lets try very little management and little hierarchy ... hey its working!"
I've done a lot of pairing (which is just called "working closely with another person" in other fields btw, this is software consultant talk) and it's been great. Nothing like this story at all. This is obvious right? "Close cooperation in a team solves problems well" wouldn't be shocking to anyone.
I had never considered how bad the combination of lots of pairing with startup cult behaviour would be. It is predictably awful. I have experienced startup cult workplaces like this and they had much worse incidents, but it wasn't all day every day. I guess I was a bit lucky there.
posted by Infracanophile at 11:24 PM on May 12, 2021 [7 favorites]
AlexiaSky explains why this is pretty well. You have to change the power structures and social dynamics in the office to something else for it to work. Everyone who tries to manage creative people figures out similar lessons don't they? "Hmm, as long as they *want* to get this done it seems like the more we micro-manage we worse things go ... lets try very little management and little hierarchy ... hey its working!"
I've done a lot of pairing (which is just called "working closely with another person" in other fields btw, this is software consultant talk) and it's been great. Nothing like this story at all. This is obvious right? "Close cooperation in a team solves problems well" wouldn't be shocking to anyone.
I had never considered how bad the combination of lots of pairing with startup cult behaviour would be. It is predictably awful. I have experienced startup cult workplaces like this and they had much worse incidents, but it wasn't all day every day. I guess I was a bit lucky there.
posted by Infracanophile at 11:24 PM on May 12, 2021 [7 favorites]
What this FPP's title brought to mind is the weaponization of almost all our vulnerabilities becoming the norm for technology UX these days.
posted by infini at 12:03 AM on May 13, 2021 [4 favorites]
posted by infini at 12:03 AM on May 13, 2021 [4 favorites]
pairing is terrific. it takes effort to learn how; it's not just staring at the screen (when not driving) and interjecting a lot of negatives. nor is it silently typing at top speed and hoping the non-driver can keep up. you have to be able to trade on a dime, explain what you're doing, ask questions of each other, teach tricks and learn tricks, pause for each other to let the wheels turn...
it's the only real code review possible. all scenarios where you wait until a feature is complete to review will fail. because even if you find significant flaws, by the time you're reviewing it's too late to back up and start fresh.
the most resistance I've seen (by a factor of 10) is from cowboys. the second most from devs with stage fright. I've never seen a cowboy transition into being a good pair. devs get over stage fright all the time.
and you don't have to pair all the time. I wouldn't want to. when you begin a feature, when it gets complex, and when you're finishing up. learn to identify the onset of complexity and you can avoid blind alleys and dead ends.
now I'll rtfa.
posted by j_curiouser at 12:09 AM on May 13, 2021 [11 favorites]
it's the only real code review possible. all scenarios where you wait until a feature is complete to review will fail. because even if you find significant flaws, by the time you're reviewing it's too late to back up and start fresh.
the most resistance I've seen (by a factor of 10) is from cowboys. the second most from devs with stage fright. I've never seen a cowboy transition into being a good pair. devs get over stage fright all the time.
and you don't have to pair all the time. I wouldn't want to. when you begin a feature, when it gets complex, and when you're finishing up. learn to identify the onset of complexity and you can avoid blind alleys and dead ends.
now I'll rtfa.
posted by j_curiouser at 12:09 AM on May 13, 2021 [11 favorites]
Unfortunately I can't read this article until I'm off my work VPN but from what I'm seeing in this thread it sounds as though it provides interesting analysis of something I've been meaning to dig into for a while now: why is it that I have been so resistant to pairing in my current job when I've had great success with it in the past?
On reflection, past pairing exercises have happened naturally - I've built up close relationships with colleagues to the point where discussions about how to solve problems would naturally evolve into pair-programming exercises as we explore different solutions in increasing detail. This has always been amazingly productive and I can see why there is an appetite for formalising that process in some way but it suddenly seems obvious to me that therein lies the problem: it's not a formal process like that. You need to build appropriate relationships, where you trust others with your vulnerabilities, before you start doing this, and you need to do it when it feels right, not all the time or at a prescribed time. That requires a certain kind of team culture that has been missing at my current workplace, though interestingly it now seems to be developing and that goes along with other recent changes in the way they want us to do things, including trying to get people to pair more. Perhaps I should hope this is more than coincidence.
I look forward to reading the article!
posted by merlynkline at 12:37 AM on May 13, 2021 [3 favorites]
On reflection, past pairing exercises have happened naturally - I've built up close relationships with colleagues to the point where discussions about how to solve problems would naturally evolve into pair-programming exercises as we explore different solutions in increasing detail. This has always been amazingly productive and I can see why there is an appetite for formalising that process in some way but it suddenly seems obvious to me that therein lies the problem: it's not a formal process like that. You need to build appropriate relationships, where you trust others with your vulnerabilities, before you start doing this, and you need to do it when it feels right, not all the time or at a prescribed time. That requires a certain kind of team culture that has been missing at my current workplace, though interestingly it now seems to be developing and that goes along with other recent changes in the way they want us to do things, including trying to get people to pair more. Perhaps I should hope this is more than coincidence.
I look forward to reading the article!
posted by merlynkline at 12:37 AM on May 13, 2021 [3 favorites]
My experiences on this vary - I'm not really a coder, but I do write code. At best, it's a good way to level up and increase accountability and think around what could go wrong. Good ideas can spread around and the little bits of know-how (what keyboard shortcuts does the other person have memorised? What windows are open?) that don't get discussed in meetings can percolate. But the trick is what language teachers call "comprehensible input". If I'm unfamiliar with the language or toolkit or problem domain, I might end up watching something I can barely parse while listening to the machine-gun patter of a mechanical keyboard. Or if I'm perceived as more senior, I might have difficulty getting the pair balanced, and squash the confidence of my partner with a few thoughtless "obviously"s (and then write some bugs that didn't get caught because the other person thought I must know what I'm doing). I don't think you can formalise those issues out: you need to have a safe, high-trust, environment.
Cross-reference: Code reviews are for improving code quality and morale
For those that have never done it, a chance to try: Code Retreat
posted by Wrinkled Stumpskin at 2:40 AM on May 13, 2021
Cross-reference: Code reviews are for improving code quality and morale
For those that have never done it, a chance to try: Code Retreat
posted by Wrinkled Stumpskin at 2:40 AM on May 13, 2021
I'm a big fan of pairing strategically applied in small doses. Is there a big, daunting task that requires some design decisions and is going to be annoying to do, that everyone is avoiding? That's a good time for pairing. Two people can bounce ideas off each other, which makes it less likely that one person will come up with a byzantine design which nobody else likes but everyone is stuck with. And although I'm an introvert, I've found that it helps to have another person work with you on something unpleasant, so that you aren't stuck doing it alone.
That isn't really some magical, unique insight specific to programming. Sometimes it's easier to do something difficult by working as a team, especially if it's something that would benefit from input from multiple people. That doesn't mean it's efficient to do everything in pairs or groups all of the time.
Pair programming all the time, 24/7, for years?! Hell, no! The drawback of pairing is that it's exhausting. I'm not talking about emotional exhaustion; I mean literal physical exhaustion. When you're working alone, you take breaks to have some tea, check your email, go to the bathroom, reply to email, look at some funny cat memes, etc.. I don't mean that people slack off when they're alone; I mean that this is a completely normal level of rest for people to insert in between doing their work. But if you're working directly with someone on a task, you don't do any of that. You're focused and engaged on the task 100% of the time. It's like being underwater and resurfacing occasionally when you remember that humans need to eat and go to the bathroom.
So my skin was crawling the whole time I was reading that article. I wouldn't even want to pair for multiple days in a row without breaks in between. I'm amazed that this person lasted as long as they did without their brain melting completely.
posted by confluency at 3:10 AM on May 13, 2021 [11 favorites]
That isn't really some magical, unique insight specific to programming. Sometimes it's easier to do something difficult by working as a team, especially if it's something that would benefit from input from multiple people. That doesn't mean it's efficient to do everything in pairs or groups all of the time.
Pair programming all the time, 24/7, for years?! Hell, no! The drawback of pairing is that it's exhausting. I'm not talking about emotional exhaustion; I mean literal physical exhaustion. When you're working alone, you take breaks to have some tea, check your email, go to the bathroom, reply to email, look at some funny cat memes, etc.. I don't mean that people slack off when they're alone; I mean that this is a completely normal level of rest for people to insert in between doing their work. But if you're working directly with someone on a task, you don't do any of that. You're focused and engaged on the task 100% of the time. It's like being underwater and resurfacing occasionally when you remember that humans need to eat and go to the bathroom.
So my skin was crawling the whole time I was reading that article. I wouldn't even want to pair for multiple days in a row without breaks in between. I'm amazed that this person lasted as long as they did without their brain melting completely.
posted by confluency at 3:10 AM on May 13, 2021 [11 favorites]
For completeness: there are ways for multiple people to cooperate closely on the same area of code which are less tightly coupled than pairing. I've had some good experiences at code jams of people working in the same place at the same time, with regular merges of each other's work. I think that there are workplace situations that could benefit from this kind of process as well. It's still highly collaborative, but much less intense and tiring.
posted by confluency at 3:21 AM on May 13, 2021 [1 favorite]
posted by confluency at 3:21 AM on May 13, 2021 [1 favorite]
Not much to add to the fantastic comments here already, but, if you are pair-programming with someone, insist on a 15-minute break after every 45 minutes of work. Seriously. And if your company culture won't handle that, you should be very worried.
posted by sixohsix at 3:44 AM on May 13, 2021 [9 favorites]
posted by sixohsix at 3:44 AM on May 13, 2021 [9 favorites]
>But this piece is about burn out, pairing is the stimulus that seems to incite the recoil response, not the cause. Presenting it otherwise is clickbait.
>and you don't have to pair all the time.
8 hours a day of weaponised peer pressure -- you don't have to work together all the time and the presentee-ism of being there will be a killer. Where's the space for reading the code tree to make tactical choices right now and to document strategic moves for mid to far horizon?
I've even advocated peer pressure when you have a dashboard showing red/amber/green for lots of tests failing; some; and no tests failing, respectively -- but it's just going to hurt people to have the main mode of working all-day every-day paired up with a colleague.
posted by k3ninho at 3:48 AM on May 13, 2021
>and you don't have to pair all the time.
8 hours a day of weaponised peer pressure -- you don't have to work together all the time and the presentee-ism of being there will be a killer. Where's the space for reading the code tree to make tactical choices right now and to document strategic moves for mid to far horizon?
I've even advocated peer pressure when you have a dashboard showing red/amber/green for lots of tests failing; some; and no tests failing, respectively -- but it's just going to hurt people to have the main mode of working all-day every-day paired up with a colleague.
posted by k3ninho at 3:48 AM on May 13, 2021
I feel a bit like when I read an article on orthorexia or obsessive exercise.
Pair progamming is something basically good for you, and most people don't do enough of, but can be taken to harmful extremes like this.
Articles about people who took it to harmful extremes are more pleasant to read because you can shake your head and feel superior, when really you should still probably be doing a bit more yourself.
posted by TheophileEscargot at 4:13 AM on May 13, 2021 [10 favorites]
Pair progamming is something basically good for you, and most people don't do enough of, but can be taken to harmful extremes like this.
Articles about people who took it to harmful extremes are more pleasant to read because you can shake your head and feel superior, when really you should still probably be doing a bit more yourself.
posted by TheophileEscargot at 4:13 AM on May 13, 2021 [10 favorites]
This seems like an baroque means of mutual bullying. Makes me physically recoil. What difference is there in this to the kind of job where your boss watches you type over your shoulder, listens into your phone calls, and picks you up on all your spelling errors?
The company I worked for previously tried pair programming for two weeks, hated it for these very reasons, and quit doing it. Code got written 3-4 times slower, it wasn't actually better, and everyone was exhausted and emotionally drained.
Code reviews are good, pair programming sucks.
posted by Foosnark at 4:44 AM on May 13, 2021 [4 favorites]
The company I worked for previously tried pair programming for two weeks, hated it for these very reasons, and quit doing it. Code got written 3-4 times slower, it wasn't actually better, and everyone was exhausted and emotionally drained.
Code reviews are good, pair programming sucks.
posted by Foosnark at 4:44 AM on May 13, 2021 [4 favorites]
I'm a filmmaker, not a coder. How does pair programming differ from other kinds of collaborative creation? In filmmaking, all the stages are done in teams, and it's one of the great strengths of the approach. I do almost everything in a collaborative context, and I love it.
Is it because it's a flat hierarchy? Because the personality types that coding appeals to are more introverted?
posted by MythMaker at 5:46 AM on May 13, 2021 [2 favorites]
Is it because it's a flat hierarchy? Because the personality types that coding appeals to are more introverted?
posted by MythMaker at 5:46 AM on May 13, 2021 [2 favorites]
i daresay arrogance, narrow-mindedness, and stubborness are greater in software dev than in film.
posted by j_curiouser at 5:57 AM on May 13, 2021 [1 favorite]
posted by j_curiouser at 5:57 AM on May 13, 2021 [1 favorite]
Pairing is so much easier now with tools like Zoom. You don't have to sit next to each other; you just share a screen.
posted by octothorpe at 6:04 AM on May 13, 2021 [3 favorites]
posted by octothorpe at 6:04 AM on May 13, 2021 [3 favorites]
I recently moved to a different part of my org that loves pairing. As an only school Dev - I got into this business because I love quiet afternoons - pairing just seems weird. The kids love it though...
Especially now, I really try and limit my zoom time. It’s exhausting
posted by ph00dz at 6:07 AM on May 13, 2021 [1 favorite]
Especially now, I really try and limit my zoom time. It’s exhausting
posted by ph00dz at 6:07 AM on May 13, 2021 [1 favorite]
They employ neurodiverse geeks with superpowers, and then Kryptonite them with pairing, and wonder why they all get ill and leave.
There's a reason we chose to work with machines in the first place.
posted by Cardinal Fang at 7:02 AM on May 13, 2021 [6 favorites]
There's a reason we chose to work with machines in the first place.
posted by Cardinal Fang at 7:02 AM on May 13, 2021 [6 favorites]
Pair progamming is something basically good for you, and most people don't do enough of
It's very hard to know how to respond to this without sounding unpleasant. The best I can do is to say that I find it a bit othering toward neurodiverse people.
posted by Cardinal Fang at 7:08 AM on May 13, 2021 [5 favorites]
It's very hard to know how to respond to this without sounding unpleasant. The best I can do is to say that I find it a bit othering toward neurodiverse people.
posted by Cardinal Fang at 7:08 AM on May 13, 2021 [5 favorites]
I knew this was going to be about Pivotal without even clicking!
- She did pair programming for five years, though it seems to have become clear to her very early that it didn't work for her.
- She uses company jargon without irony (she's a 'Pivot').
- She says she missed the company breakfast. Work-life balance red flag.
- That final sentence - 'failing to make more space for people not to pair' - as if pairing were the normal and natural way, and any deviation from it should have been better managed.
What I read here is an article that's 10% pairing and 90% Stockholm syndrome.
posted by Cardinal Fang at 7:17 AM on May 13, 2021 [6 favorites]
- She did pair programming for five years, though it seems to have become clear to her very early that it didn't work for her.
- She uses company jargon without irony (she's a 'Pivot').
- She says she missed the company breakfast. Work-life balance red flag.
- That final sentence - 'failing to make more space for people not to pair' - as if pairing were the normal and natural way, and any deviation from it should have been better managed.
What I read here is an article that's 10% pairing and 90% Stockholm syndrome.
posted by Cardinal Fang at 7:17 AM on May 13, 2021 [6 favorites]
I am a hard, hard nope on pairing. Though I have friends who are smarter than me who love it.
When I create I cannot stand to have someone looking over my shoulder. I lose substantial critical processing capabilities to dealing with the proximity of someone else in my space, especially if they are evaluating what I am doing. I need all the brain I can get.
I don't mind doing non-creative things with people. But when I have to operate creatively, I must be unobserved.
posted by seanmpuckett at 7:26 AM on May 13, 2021 [8 favorites]
When I create I cannot stand to have someone looking over my shoulder. I lose substantial critical processing capabilities to dealing with the proximity of someone else in my space, especially if they are evaluating what I am doing. I need all the brain I can get.
I don't mind doing non-creative things with people. But when I have to operate creatively, I must be unobserved.
posted by seanmpuckett at 7:26 AM on May 13, 2021 [8 favorites]
pairing is terrific
in my experience also. Taught me heaps. Taught him a thing or two as well. And our code ended up really clean and once we'd found our mutual groove we were knocking it out at a pace that I wouldn't have believed possible.
But upper management put an end to it before we got anywhere close to burnout. The bean counters just couldn't deal with the idea of paying two engineers for one task and prohibited the project lead from deploying people that way.
posted by flabdablet at 7:27 AM on May 13, 2021 [2 favorites]
in my experience also. Taught me heaps. Taught him a thing or two as well. And our code ended up really clean and once we'd found our mutual groove we were knocking it out at a pace that I wouldn't have believed possible.
But upper management put an end to it before we got anywhere close to burnout. The bean counters just couldn't deal with the idea of paying two engineers for one task and prohibited the project lead from deploying people that way.
posted by flabdablet at 7:27 AM on May 13, 2021 [2 favorites]
I am a hard, hard nope on pairing. Though I have friends who are smarter than me who love it.
I'm mixed on pairing. On novel, new tasks and logic sequences, and in short increments? Yes.
The rest of the time - it's so insanely boring. Watching someone code is like watching them watch tv. What the heck do you do? And if I'm not the typer, I instantly zone out. Can you edit someone's work on the fly? Can you talk through your logic while you are typing? Most of the time I can't.
posted by The_Vegetables at 7:58 AM on May 13, 2021 [1 favorite]
I'm mixed on pairing. On novel, new tasks and logic sequences, and in short increments? Yes.
The rest of the time - it's so insanely boring. Watching someone code is like watching them watch tv. What the heck do you do? And if I'm not the typer, I instantly zone out. Can you edit someone's work on the fly? Can you talk through your logic while you are typing? Most of the time I can't.
posted by The_Vegetables at 7:58 AM on May 13, 2021 [1 favorite]
My current employer is big on pairing, to the point that we have elaborate tooling designed around it with tmux and development instances in AWS.
It's historically not been a thing that operations people do but it's occasionally been beneficial to work on implementations directly with someone on another team that has more of a history working in the current subject area, or someone on your own team where you can riff off each other and call out potential benefits or drawbacks in a solution.
That being said I can only tolerate it at most a couple of hours a day since my own work methodology has always revolved around holding a lot of context in my head, iterating on it, and then getting it down. Talking to someone else throughout anything complex just fries my brain and kills my attention span. Any benefits of my own ability to intensely focus are completely out the window and I end up exhausted.
posted by mikesch at 8:12 AM on May 13, 2021 [2 favorites]
It's historically not been a thing that operations people do but it's occasionally been beneficial to work on implementations directly with someone on another team that has more of a history working in the current subject area, or someone on your own team where you can riff off each other and call out potential benefits or drawbacks in a solution.
That being said I can only tolerate it at most a couple of hours a day since my own work methodology has always revolved around holding a lot of context in my head, iterating on it, and then getting it down. Talking to someone else throughout anything complex just fries my brain and kills my attention span. Any benefits of my own ability to intensely focus are completely out the window and I end up exhausted.
posted by mikesch at 8:12 AM on May 13, 2021 [2 favorites]
I've been in the software industry for 25 years - I'm now a principal engineer, working on "greenfield" projects for critical domains that have a lot of very complex and subtle behaviors. Due to organizational history and dynamics I'm having to bootstrap this with contractors, most of whom have not worked here before and all of whom are working remotely. Pairing (combined with other agile engineering practices) are one of the few good tools I have available to make sure this doesn't turn into a complete clusterfuck. We're screening ahead of time for pairing compatibility - it helps neither my company nor the contractor to flame out. And we're (IMO) keeping it reasonable - "lone wolf" is fine for cookie-cutter work, and we implemented sustainable cadences.
I think of it like any other "work safety" consideration, similar to heavy lifting. People with bad backs shouldn't take lifting-intensive jobs, just as people who are neurodivergent in certain ways may not be able to safely take pairing roles. But as a leader I also need to ensure that we're not pushing the people that _are_ task-compatible people too far, so that they can continue to do that task.
posted by microscone at 8:33 AM on May 13, 2021 [3 favorites]
I think of it like any other "work safety" consideration, similar to heavy lifting. People with bad backs shouldn't take lifting-intensive jobs, just as people who are neurodivergent in certain ways may not be able to safely take pairing roles. But as a leader I also need to ensure that we're not pushing the people that _are_ task-compatible people too far, so that they can continue to do that task.
posted by microscone at 8:33 AM on May 13, 2021 [3 favorites]
I guess this is where I share my idea that programming computers requires a form of brain damage because you need to be able to reshape the vastness of human possibility to speak to very literal machines (often via various forms of abstractions).
Said by someone who's been doing this longer than I care to admit
posted by kokaku at 9:53 AM on May 13, 2021
Said by someone who's been doing this longer than I care to admit
posted by kokaku at 9:53 AM on May 13, 2021
Pairing always sounded like a special kind of hell to me. Not only would I have to sit there and watch someone else code, I'd also have someone standing over my shoulder while I code, telling me, "ya missed a spot!"
Hard pass.
posted by panama joe at 10:10 AM on May 13, 2021 [6 favorites]
Hard pass.
posted by panama joe at 10:10 AM on May 13, 2021 [6 favorites]
This, or it's academic precedents, is more or less why I became a scientist instead of an engineer. I don't say this flippantly: given a choice between busking on street corners and working like this, I'd absolutely choose the former. What an absolute, screaming nightmare.
posted by eotvos at 10:58 AM on May 13, 2021 [2 favorites]
posted by eotvos at 10:58 AM on May 13, 2021 [2 favorites]
Trying to explain this to non-programmers:
If your task is to implement a particular feature, the design can matter, but the specific nitty-gritty isn't that important as long as:
- it doesn't crash, or destroy data
- it's secure (this depends on the application)
- it does the correct thing (within some degree of accuracy that depends a lot on the application)
- it performs quickly (in some cases this is critical, in others it's pretty forgiving)
- it's maintainable (understandable and editable by future programmers)
Pairing, however, puts every single micro decision under scrutiny. It's like if you're writing an essay with someone over your shoulder asking you to justify why you wrote the word "cerulean" when you could have used "azure" -- breaking your train of thought while you were thinking on a different level of the problem, instead of reading the finished product. Or they'll point out that you have one too many parentheses, which is a thing the compiler will do for free better than a human can, and without interrupting your flow. It's frustrating to the person at the keyboard, and to the person sitting there itching to do things their own way.
Coding is also an iterative process. Often you rough in a simple or partial version, test that, and refine it, maybe even redesigning along the way. If you're soloing you can do this without having to justify yourself. If you're pairing, you have to explain your process as well as your design choices.
Code reviews, unit tests, regression tests, automated and manual UI tests, etc. can be extremely valuable, without putting you continually on the defensive and dictating a particular working method. If your supervisor doesn't like the word "cerulean" they can ask you to change it then.
I think there are aspects of design where collaboration is helpful, but pair programming itself is probably more harmful than beneficial for many coders (neurotypical or not).
posted by Foosnark at 11:02 AM on May 13, 2021 [15 favorites]
If your task is to implement a particular feature, the design can matter, but the specific nitty-gritty isn't that important as long as:
- it doesn't crash, or destroy data
- it's secure (this depends on the application)
- it does the correct thing (within some degree of accuracy that depends a lot on the application)
- it performs quickly (in some cases this is critical, in others it's pretty forgiving)
- it's maintainable (understandable and editable by future programmers)
Pairing, however, puts every single micro decision under scrutiny. It's like if you're writing an essay with someone over your shoulder asking you to justify why you wrote the word "cerulean" when you could have used "azure" -- breaking your train of thought while you were thinking on a different level of the problem, instead of reading the finished product. Or they'll point out that you have one too many parentheses, which is a thing the compiler will do for free better than a human can, and without interrupting your flow. It's frustrating to the person at the keyboard, and to the person sitting there itching to do things their own way.
Coding is also an iterative process. Often you rough in a simple or partial version, test that, and refine it, maybe even redesigning along the way. If you're soloing you can do this without having to justify yourself. If you're pairing, you have to explain your process as well as your design choices.
Code reviews, unit tests, regression tests, automated and manual UI tests, etc. can be extremely valuable, without putting you continually on the defensive and dictating a particular working method. If your supervisor doesn't like the word "cerulean" they can ask you to change it then.
I think there are aspects of design where collaboration is helpful, but pair programming itself is probably more harmful than beneficial for many coders (neurotypical or not).
posted by Foosnark at 11:02 AM on May 13, 2021 [15 favorites]
My first co-op job in undergrad had me and the other co-op student basically be treated as a unit. Our supervisor was usually out of the office and would give us tasks to complete. We ended up doing a lot of pair programming and we both enjoyed it. A lot of it likely stemmed from the fact that this was both of our first jobs so having another set of eyes looking at our code gave us some additional confidence that we were doing things correctly, or at least weren't totally messing things up. If we both knew exactly what we were doing and had years of experience then I could imagine the non-coding person would get bored fairly quickly, or start to give a lot of unnecessary input like Foosnark's examples in order to feel like they're contributing though.
posted by any portmanteau in a storm at 11:10 AM on May 13, 2021
posted by any portmanteau in a storm at 11:10 AM on May 13, 2021
Operationalizing peer pressure to make better code by spreading the hard creative and analytic work required for some parts of programming is way better than what it replaced
Crucifixion? Could be worse...
posted by Cardinal Fang at 11:12 AM on May 13, 2021
Crucifixion? Could be worse...
posted by Cardinal Fang at 11:12 AM on May 13, 2021
Teams had half as many workstations as they had engineers.
Did people even do routine things like answer emails while pairing?
posted by HiddenInput at 11:15 AM on May 13, 2021 [1 favorite]
Did people even do routine things like answer emails while pairing?
posted by HiddenInput at 11:15 AM on May 13, 2021 [1 favorite]
This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software. It also burned me out. [...] “Sorry… how did that sentence start? What were we talking about?” burnout.
I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management.
This is the 2nd time in 2 weeks I've read about a techie overworking themselves into a brain malfunction. Here's the other one. That's terrifying.
And no, this was clearly not one of the best things the author ever did for herself. She's not a coal miner in the 1920s - disability isn't just an expected risk of the job. The company did this to her.
I've never pair-programmed in my 20+ years of web dev, but the idea reminds me of that infamous scene in NCIS.
posted by frogstar42 at 11:17 AM on May 13, 2021 [2 favorites]
I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management.
This is the 2nd time in 2 weeks I've read about a techie overworking themselves into a brain malfunction. Here's the other one. That's terrifying.
And no, this was clearly not one of the best things the author ever did for herself. She's not a coal miner in the 1920s - disability isn't just an expected risk of the job. The company did this to her.
I've never pair-programmed in my 20+ years of web dev, but the idea reminds me of that infamous scene in NCIS.
posted by frogstar42 at 11:17 AM on May 13, 2021 [2 favorites]
It's like if you're writing an essay with someone over your shoulder asking you to justify why you wrote the word "cerulean" when you could have used "azure" -- breaking your train of thought while you were thinking on a different level of the problem, instead of reading the finished product. Or they'll point out that you have one too many parentheses, which is a thing the compiler will do for free better than a human can, and without interrupting your flow. It's frustrating to the person at the keyboard, and to the person sitting there itching to do things their own way.
Or it can be like two skilled professionals respecting each other enough to treat the process of software construction as if it were a civilised conversation, leaving each other enough room to think, being sensitive to each other's attention spans, waiting for natural pauses to ask for or suggest clarifications and generally being interested enough in what the other is doing to keep the whole process locked solidly in a flow state for hours at a stretch.
At its best, done by a pair prepared to leave their egos at home and help each other to make the collaboration succeed, building clean and correct software with somebody else is just fun. And yes, it does involve a weird kind of intimacy and a considerable degree of trust and no, some people are not happy being that exposed in the workplace.
And just like every other way good programmers have ever successfully made good software, senior management will fuck this one up by making pairing either mandatory or forbidden. Because obviously an MBA knows far more about making good software than a mere software engineer ever could.
posted by flabdablet at 12:34 PM on May 13, 2021 [8 favorites]
Or it can be like two skilled professionals respecting each other enough to treat the process of software construction as if it were a civilised conversation, leaving each other enough room to think, being sensitive to each other's attention spans, waiting for natural pauses to ask for or suggest clarifications and generally being interested enough in what the other is doing to keep the whole process locked solidly in a flow state for hours at a stretch.
At its best, done by a pair prepared to leave their egos at home and help each other to make the collaboration succeed, building clean and correct software with somebody else is just fun. And yes, it does involve a weird kind of intimacy and a considerable degree of trust and no, some people are not happy being that exposed in the workplace.
And just like every other way good programmers have ever successfully made good software, senior management will fuck this one up by making pairing either mandatory or forbidden. Because obviously an MBA knows far more about making good software than a mere software engineer ever could.
posted by flabdablet at 12:34 PM on May 13, 2021 [8 favorites]
If you're pairing, you have to explain your process as well as your design choices.
And this is exactly why pairing, done well by willing people, makes for such good software. I've always found that explaining stuff to somebody else is the single best way to get true clarity on it myself.
Of course it helps a lot if your pair is quick enough on the uptake not to need much explaining to.
Main key to success, though, is that both participants are humble enough and secure enough to understand that their way isn't necessarily the way and that remaining open to discovering improvements is a good thing regardless of skill level. The best part of pairing is when process and design improvements just emerge in ways that neither half would have anticipated or achieved alone.
posted by flabdablet at 12:41 PM on May 13, 2021 [6 favorites]
And this is exactly why pairing, done well by willing people, makes for such good software. I've always found that explaining stuff to somebody else is the single best way to get true clarity on it myself.
Of course it helps a lot if your pair is quick enough on the uptake not to need much explaining to.
Main key to success, though, is that both participants are humble enough and secure enough to understand that their way isn't necessarily the way and that remaining open to discovering improvements is a good thing regardless of skill level. The best part of pairing is when process and design improvements just emerge in ways that neither half would have anticipated or achieved alone.
posted by flabdablet at 12:41 PM on May 13, 2021 [6 favorites]
the most resistance I've seen (by a factor of 10) is from cowboys. the second most from devs with stage fright. I've never seen a cowboy transition into being a good pair. devs get over stage fright all the time.
I too have been in tech for a long time, worked for a bunch of companies, seen pairing work, and seen it not work. I don't really disagree with most of your statements, but I do object to this framing that basically boils down to "if you don't like pairing, you're not a good developer (or something is wrong with you)." I respect that you're just speaking from your experience, but I wish you would acknowledge that people work and think in different ways, and just because someone doesn't work well in a pairing situation it doesn't mean they're a cowboy (pretty derogatory in the industry definition) or have stage fright (meaning they need to "just get over it," aka "just change how their brain works"). Yes, pairing well takes some practice, and many (or most) people who have a hard time with it up front can learn to deal with it. But I promise that it's possible to be a good and successful, non-cowboy team player developer whose style is simply incompatible with pair programming. It's possible that makes those people a bad fit for your team, which is fine (I think...), but that doesn't mean they don't exist and can't be successful elsewhere.
posted by primethyme at 12:45 PM on May 13, 2021 [11 favorites]
I too have been in tech for a long time, worked for a bunch of companies, seen pairing work, and seen it not work. I don't really disagree with most of your statements, but I do object to this framing that basically boils down to "if you don't like pairing, you're not a good developer (or something is wrong with you)." I respect that you're just speaking from your experience, but I wish you would acknowledge that people work and think in different ways, and just because someone doesn't work well in a pairing situation it doesn't mean they're a cowboy (pretty derogatory in the industry definition) or have stage fright (meaning they need to "just get over it," aka "just change how their brain works"). Yes, pairing well takes some practice, and many (or most) people who have a hard time with it up front can learn to deal with it. But I promise that it's possible to be a good and successful, non-cowboy team player developer whose style is simply incompatible with pair programming. It's possible that makes those people a bad fit for your team, which is fine (I think...), but that doesn't mean they don't exist and can't be successful elsewhere.
posted by primethyme at 12:45 PM on May 13, 2021 [11 favorites]
Pairing can work for some, and for others it doesn't. I think probably this isn't something that needs to have a calvary charging in? With bugles?
posted by seanmpuckett at 1:51 PM on May 13, 2021 [3 favorites]
posted by seanmpuckett at 1:51 PM on May 13, 2021 [3 favorites]
Pairing, however, puts every single micro decision under scrutiny. It's like if you're writing an essay with someone over your shoulder asking you to justify why you wrote the word "cerulean" when you could have used "azure" -- breaking your train of thought while you were thinking on a different level of the problem
if this is your experience, you've never had a good pair. or, as flabdalet says, there's a basic mutual respect and civility missing.
just because someone doesn't work well in a pairing situation it doesn't mean they're a cowboy
causation is the other direction; if someone is a cowboy, they won't be a good pair.
stage fright (meaning they need to "just get over it," aka "just change how their brain works")
i don't think that subtext is on target. I'm not trivializing it. a lot of stage fright, i think, is getting used to having your knowledge gaps on display. dropping the ego a bit in the workplace can be tough. i started pairing with crippling stage fright. i acknowledge it's harder for some than others.
(I'll defer to seanmpuckett. putting the cavalry back in the drawer, sry!)
posted by j_curiouser at 2:01 PM on May 13, 2021
if this is your experience, you've never had a good pair. or, as flabdalet says, there's a basic mutual respect and civility missing.
just because someone doesn't work well in a pairing situation it doesn't mean they're a cowboy
causation is the other direction; if someone is a cowboy, they won't be a good pair.
stage fright (meaning they need to "just get over it," aka "just change how their brain works")
i don't think that subtext is on target. I'm not trivializing it. a lot of stage fright, i think, is getting used to having your knowledge gaps on display. dropping the ego a bit in the workplace can be tough. i started pairing with crippling stage fright. i acknowledge it's harder for some than others.
(I'll defer to seanmpuckett. putting the cavalry back in the drawer, sry!)
posted by j_curiouser at 2:01 PM on May 13, 2021
I (a senior SDE) worked on a 100% pairing team of 8 different SDEs over two years, with all production code written in pairs and pairs being split and reassigned foor each user story. Our interviews were pair exercises between the interviewer and interviewee -- that was how hard we paired.
With 2 of those folks, pairing was a dream, my pair and I produced software that neither could produce on our own, and we exchanged learnings. We got in sync, traded off thoughts. Real nice experience. I keep trying to recruit those folks into my present company.
With 4 of those folks, it was neutral, whatever, probably a net negative since we were spending two engineers on one task.
The other two were actively unpleasant. You haven't paired until you've paired with a misanthropic kid who sincerely believes they are the smartest person in the room, that they are being held back by everyone else in the company, and who thinks 5% faster (but not 5% better) than you. The other person was an okay coder and collaborator but she had a wicked bad BO problem that was manageable in an office or a meeting room, but not when our shoulders were touching.
Whenever someone tell me they want to run a pairing team, I tell them that full-time pairing is like taking an 8-hour roadtrip daily in a weirdly narrow car with dual controls and no stereos, and if they're confident they can find 4-7 other people who would be 100% good roadtrip buddies while also being at least competent SDEs, then godspeed to them. Otherwise, no.
posted by Sauce Trough at 2:05 PM on May 13, 2021 [5 favorites]
With 2 of those folks, pairing was a dream, my pair and I produced software that neither could produce on our own, and we exchanged learnings. We got in sync, traded off thoughts. Real nice experience. I keep trying to recruit those folks into my present company.
With 4 of those folks, it was neutral, whatever, probably a net negative since we were spending two engineers on one task.
The other two were actively unpleasant. You haven't paired until you've paired with a misanthropic kid who sincerely believes they are the smartest person in the room, that they are being held back by everyone else in the company, and who thinks 5% faster (but not 5% better) than you. The other person was an okay coder and collaborator but she had a wicked bad BO problem that was manageable in an office or a meeting room, but not when our shoulders were touching.
Whenever someone tell me they want to run a pairing team, I tell them that full-time pairing is like taking an 8-hour roadtrip daily in a weirdly narrow car with dual controls and no stereos, and if they're confident they can find 4-7 other people who would be 100% good roadtrip buddies while also being at least competent SDEs, then godspeed to them. Otherwise, no.
posted by Sauce Trough at 2:05 PM on May 13, 2021 [5 favorites]
forgot the conclusion: now that I have suction in these matters, my team will not be a pairing team.
posted by Sauce Trough at 2:09 PM on May 13, 2021 [3 favorites]
posted by Sauce Trough at 2:09 PM on May 13, 2021 [3 favorites]
Or it can be like two skilled professionals respecting each other enough to treat the process of software construction as if it were a civilised conversation
Which is kind of the point. In a healthy working environment, this will happen naturally - two (or more) geeks getting enthusiastic about a problem, helping each other solve it, sometimes even having to be told to quieten down or get a room.
Don't give it a name. Don't make it a process.
posted by Cardinal Fang at 2:30 PM on May 13, 2021 [7 favorites]
Which is kind of the point. In a healthy working environment, this will happen naturally - two (or more) geeks getting enthusiastic about a problem, helping each other solve it, sometimes even having to be told to quieten down or get a room.
Don't give it a name. Don't make it a process.
posted by Cardinal Fang at 2:30 PM on May 13, 2021 [7 favorites]
I think probably this isn't something that needs to have a calvary charging in
Like I said. Crucifixion...
posted by Cardinal Fang at 2:30 PM on May 13, 2021 [1 favorite]
Like I said. Crucifixion...
posted by Cardinal Fang at 2:30 PM on May 13, 2021 [1 favorite]
> How does pair programming differ from other kinds of collaborative creation? In filmmaking, all the stages are done in teams, and it's one of the great strengths of the approach. I do almost everything in a collaborative context, and I love it.
It doesn't differ, except in the setting. Collaboration is difficult or impossible if the suits are tracking every step of the work, every change judged and scored and that score gets assigned to a specific person who is judged to be responsible for it.
Since software is also an exploratory and creative exercise, part of the process of ending up with something good involves a lot of dissection and critique of the work done so far. The difference in what that is like in a team that talks about "the code" and how "we" are going to get the next part done can be wildly different than being in a team where "your code" is going to get dissected and critiqued in front of everyone as a direct judgement of your skill like a daily public performance review.
Software also attracts a lot of very introverted people for cultural reasons, which can be cruel given how making software is necessarily an intensely collaborative process.
If I was going for short and flippant I would say: It's the same, but you get to do your collaboration in a culture of artists and we get to choose between finance dude culture or startup dude culture. Also the last couple years you gotta work out who the literal nazis are when you start working at a new place because there's probably a bunch.
posted by Infracanophile at 5:07 PM on May 13, 2021 [2 favorites]
It doesn't differ, except in the setting. Collaboration is difficult or impossible if the suits are tracking every step of the work, every change judged and scored and that score gets assigned to a specific person who is judged to be responsible for it.
Since software is also an exploratory and creative exercise, part of the process of ending up with something good involves a lot of dissection and critique of the work done so far. The difference in what that is like in a team that talks about "the code" and how "we" are going to get the next part done can be wildly different than being in a team where "your code" is going to get dissected and critiqued in front of everyone as a direct judgement of your skill like a daily public performance review.
Software also attracts a lot of very introverted people for cultural reasons, which can be cruel given how making software is necessarily an intensely collaborative process.
If I was going for short and flippant I would say: It's the same, but you get to do your collaboration in a culture of artists and we get to choose between finance dude culture or startup dude culture. Also the last couple years you gotta work out who the literal nazis are when you start working at a new place because there's probably a bunch.
posted by Infracanophile at 5:07 PM on May 13, 2021 [2 favorites]
We were Pivots, and one of the things that made us Pivots was that we paired.Two relatively young people get together, and instead of conceiving and birthing a baby, or adopting one, and then raising it, they are given a "project" to nurture, devote themselves to, and bring to fruition.
One of the great and terrible things about XP, is that it operationalizes peer pressure. It harnesses drives that humans have, drives for identity and belonging, in the service of producing software. These forces were only tenuously under management control.
So I paired all day, most days, for about five years. This had a lot of upsides, far more than I can list here. There’s a standard list of benefits and drawbacks to pairing that you might be familiar with, but the impact of pairing, especially pairing that much, goes much deeper than its impact on the code, on the particular work the team delivers that week.
Only a generation which has convinced itself that there is no such thing as human nature beyond the simplest models of physiology and and genetics, and therefore don't recognize that there could be anything humans are preprogrammed to be willing to make almost any sacrifice for, often including their very lives, could fail to grasp what's being done to them here.
Do the architects of 'pivoting' grasp it?
Don't be absurd; of course they do.
posted by jamjam at 6:25 PM on May 13, 2021 [3 favorites]
I've always found that explaining stuff to somebody else is the single best way to get true clarity on it myself.
For bug fixes or problem solving , in the absence of an effective collaborator, you can get 90% of this effect by taking notes in a problem, observations, hypothesis, supporting evidence format.
posted by bdc34 at 6:20 AM on May 14, 2021 [1 favorite]
For bug fixes or problem solving , in the absence of an effective collaborator, you can get 90% of this effect by taking notes in a problem, observations, hypothesis, supporting evidence format.
posted by bdc34 at 6:20 AM on May 14, 2021 [1 favorite]
Explaining it to somebody else works about three times as fast, in my experience. They have to be genuinely interested, though. Explaining stuff to somebody whose eyes are glazing over helps nobody.
The best part about having somebody else to explain stuff to is that they will ask the questions I didn't know I'd forgotten to.
posted by flabdablet at 6:58 AM on May 14, 2021 [3 favorites]
The best part about having somebody else to explain stuff to is that they will ask the questions I didn't know I'd forgotten to.
posted by flabdablet at 6:58 AM on May 14, 2021 [3 favorites]
I've never done pair programming, but just sitting here thinking about it has me on the verge of a panic attack. And I cannot fathom how anything ever gets done this way. Wouldn't it take an hour to write ten lines of code?
(I'm also kinda tired of seeing "cowboy" used as a pejorative. I promise you that an experienced, competent developer who is given sufficient freedom can produce very clean, maintainable code, very quickly.)
posted by escape from the potato planet at 4:17 PM on May 14, 2021 [5 favorites]
(I'm also kinda tired of seeing "cowboy" used as a pejorative. I promise you that an experienced, competent developer who is given sufficient freedom can produce very clean, maintainable code, very quickly.)
posted by escape from the potato planet at 4:17 PM on May 14, 2021 [5 favorites]
Wouldn't it take an hour to write ten lines of code?
nope. you still work iteratively. and the non-driver doesn't have to comment right away if it's an early iteration. just keep a running list of candidate-refactors. or use smart, searchable reminders in comments. when you switch in 45 minutes you can propose refactors, get feedback, and implement.
the team or the pair can also agree a priori on code design goals. are we using SOLID? all principles? which ones? No manager, helper or utility types. are you approaching it with an architectural pattern à la fowler? and so on.
posted by j_curiouser at 12:40 PM on May 15, 2021 [2 favorites]
nope. you still work iteratively. and the non-driver doesn't have to comment right away if it's an early iteration. just keep a running list of candidate-refactors. or use smart, searchable reminders in comments. when you switch in 45 minutes you can propose refactors, get feedback, and implement.
the team or the pair can also agree a priori on code design goals. are we using SOLID? all principles? which ones? No manager, helper or utility types. are you approaching it with an architectural pattern à la fowler? and so on.
posted by j_curiouser at 12:40 PM on May 15, 2021 [2 favorites]
I promise you that an experienced, competent developer who is given sufficient freedom can produce very clean, maintainable code, very quickly.
we'll have to differ. at least a pair could help guard against shitty non-descriptive type and variable names. clean code guideline #1: naming. step one in maintainability.
posted by j_curiouser at 12:44 PM on May 15, 2021 [2 favorites]
we'll have to differ. at least a pair could help guard against shitty non-descriptive type and variable names. clean code guideline #1: naming. step one in maintainability.
posted by j_curiouser at 12:44 PM on May 15, 2021 [2 favorites]
Thankfully I was largely spared this during the 12+ years I was a programmer. I was asked to experiment with it in my first FT job after college. Even with a semi-decent partner, I hated it. Thankfully I was never required to do it again.
Part of the reason I hated it is because I'm an introvert and it was too draining for me.
But part of it, probably the bigger part, is because most of the programmers I've ever worked with are egotistical monsters in the worst stereotypically male way. To them, coding is a whip-out-your dick contest where you prove how your way is always better. Most of them don't even listen to others, especially to female coworkers, because they Already Know Everything. Pair programming with them would be soul destroying. It was already bad enough having to work with the motherfuckers.
posted by Flock of Cynthiabirds at 6:29 PM on May 15, 2021 [1 favorite]
Part of the reason I hated it is because I'm an introvert and it was too draining for me.
But part of it, probably the bigger part, is because most of the programmers I've ever worked with are egotistical monsters in the worst stereotypically male way. To them, coding is a whip-out-your dick contest where you prove how your way is always better. Most of them don't even listen to others, especially to female coworkers, because they Already Know Everything. Pair programming with them would be soul destroying. It was already bad enough having to work with the motherfuckers.
posted by Flock of Cynthiabirds at 6:29 PM on May 15, 2021 [1 favorite]
> I'm also kinda tired of seeing "cowboy" used as a pejorative. I promise you that an experienced, competent developer who is given sufficient freedom can produce very clean, maintainable code, very quickly.This is a strawperson. If you were saying that "cowboy" shouldn't be used in this way because in actuality cowboys care about working together or the ease of someone coming after them to maintain or build on what they've done, that's something. But not all developers working solo are "cowboys". There are those who work as you say. There are also cowboys.
I find I do my best work with collaboration, but that doesn't mean always pairing. Sometimes pairing can be nicer than working alone. Sometimes it's more productive. Often it's draining, and I want to be on my own for a bit. But I do value and honestly require consideration in some forms for various reasons. Two major reasons being a) I don't think I can understand all aspects of a problem (and therefore come up with the best solution) on my own, and b) I don't want to be the only person who understands the system (and therefore is completely responsible for its maintenance).
posted by cardioid at 12:17 PM on May 16, 2021 [2 favorites]
> My current employer is big on pairing, to the point that we have elaborate tooling designed around it with tmux and development instances in AWS.
Hey fellow Treep!
I learned to pair in the bootcamp that I attended, didn't formally pair (lots of informal pairing) for a few years across various jobs, and am now back to formal pairing at my current job, using the system mikesch describes. I've got some fun brain chemistry issues, like a lot of people in programming, but I find the level of condemnation pairing is getting here a little odd, and the idea that it's something that only NTs could possibly do or like is just wrong. I do think a lot of it relies on working with good people who are flexible and non-dogmatic about the best way to get things done, but I think that's true about any model of working. Pivotal definitely appears to be among the most dogmatic pairing shops out there, and this is not the first, fifth, or tenth time I've heard about someone burning out of there because the pairing culture is way over the top.
My current workplace is pairing-heavy, but at least on my team, there's a good balance between pairing time and solo time, and good balance during pairing time around taking breaks and being respectful of people's limits. I certainly find pairing more draining than solo work, but I also feel like pairing has helped me get to know my teammates better and has me writing better code at higher velocity than previous jobs. It's not a magic bullet, it has tradeoffs, etc., but it's not the devil the way some folks seem to think.
posted by protocoach at 1:48 PM on May 16, 2021 [3 favorites]
Hey fellow Treep!
I learned to pair in the bootcamp that I attended, didn't formally pair (lots of informal pairing) for a few years across various jobs, and am now back to formal pairing at my current job, using the system mikesch describes. I've got some fun brain chemistry issues, like a lot of people in programming, but I find the level of condemnation pairing is getting here a little odd, and the idea that it's something that only NTs could possibly do or like is just wrong. I do think a lot of it relies on working with good people who are flexible and non-dogmatic about the best way to get things done, but I think that's true about any model of working. Pivotal definitely appears to be among the most dogmatic pairing shops out there, and this is not the first, fifth, or tenth time I've heard about someone burning out of there because the pairing culture is way over the top.
My current workplace is pairing-heavy, but at least on my team, there's a good balance between pairing time and solo time, and good balance during pairing time around taking breaks and being respectful of people's limits. I certainly find pairing more draining than solo work, but I also feel like pairing has helped me get to know my teammates better and has me writing better code at higher velocity than previous jobs. It's not a magic bullet, it has tradeoffs, etc., but it's not the devil the way some folks seem to think.
posted by protocoach at 1:48 PM on May 16, 2021 [3 favorites]
« Older ‘Rationals’ vs. ‘radicals’: | How the Personal Computer Broke the Human Body Newer »
This thread has been archived and is closed to new comments
We don't talk much anymore but it's one of those relationships where if she showed up on my doorstep unexpectedly I'd invite her to come in and stay the night, no questions asked. I don't know that I COULD be that vulnerable and open with a colleague day in and day out. It definitely sounds exhausting.
posted by potrzebie at 8:52 PM on May 12, 2021 [10 favorites]