8 ms·

Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it. I

Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it. I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. I definitely see the value in pairing for imbalanced situations (junior and senior, new engineer and tenured), but such sessions should have the goal of getting each person to operate independently, hopefully sooner than later. Pairing just for the sake of pairing is an encroachment on many things I love about software (the ability to think about a problem deeply and quietly, the ability to work independently, the ability to check my Twitter feed as often as I damn please). I’m really glad the pairing fad seems to be dying down in general!

slaymaker1907 5y ago
You missed what I consider to be the greatest strength of pair programming: debugging. If one person gets stuck on something, the other person often still has some ideas on how to proceed. Even if you don't pair program, you absolutely should be debugging with someone else if possible.
jordanbeiber 5y ago
In, for example, an enterprise setting you rarely want individually clever and creative solutions. You generally want domain expertise shared in a team, and continuously molded to perfection over time. Mobs and pairs can really shine here, but it all depends on the individuals. In teams where it works well it’s an enormous value add, in my experience, and the hive mind you reach after a year or two within a team is fantastic. As a dev manager I let the teams decide, but looking at team flow over time, it looks hard to beat a well functioning pair or mob team. IMHO & YMMV, and so on.
epolanski 5y ago
I have recently switched teams and I'm in one where most programming but trivial tasks are done in pair. I can see lots of pros and few cons: - knowledge sharing, especially business, domain, old code, etc. The biggest stopper in writing software in large organizations is rarely technical difficulty but context - focus. If I'm alone I get distracted much more, music, youtube, socials, I know this is on me, but getting distracted while pairing is hard and rude. I'm also much more organized and a coworker is much better than a rubber duck. cons: - you are blocked from working if a coworkers schedule is not aligned Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.
- blindmute 5y ago
  Con: almost no one likes doing this and you'll bleed talent Con: you're spending literally double on engineers for the same amount of work done
- eikenberry 5y ago
  > Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming. I think this is the key takeaway with one missed point. IMO it definitely does produce more work vs. solo programming but that work is sub-par. The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.
  - gregkerzhner 5y ago
    The part of my brain which thinks deeply and produces elegant solutions simply shuts down when I constantly have to explain my thought process to someone else. I actually have the same problem in pair programming interviews - my brain tends to freeze up and comes up with strange, hacky workarounds at best. Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who produce their best work when they can focus, alone. If pairing works for you, then that’s great, but it needs to be consensual and optional. The problem with pairing is that it tends to be championed and enforced by more social workers (especially managers), and forced on the less social ones, who are often not in a position to refuse.
    - RHSeeger 5y ago
      > If pairing works for you, then that’s great, but it needs to be consensual and optional. This is the key in my mind. Pair programming doesn't work for me, based on past experience. Pair design works great, and rubber ducking into a slack channel (that people expect that kind of thing to be in); those are things I find highly useful. But when it comes time to actually write code, I tend to work best alone. I think part of the reason for this is that I tend to work through designs and possible implementations in my head, but by writing code. Then I'll discuss those designs to come up with some possible issues (pros/cons/etc). Then I'll work on implementing what seems likely to be the best choice (which is may not be once coding starts). By the time I get to coding, most of the impact of someone else being involved is just going to be catching typos. Or possibly code written in a hard to maintain way... but code reviews will catch that just as well (probably more so, because the person reviewing it _wasn't_ there when it was written).
jatins 5y ago
Google's Jeff and Sanjay are famous for pairing together, and most would think they are fairly competent people. Pairing brings a new perspective to the problem and, for me, the social element is also valuable in that you also build relationships by pairing. Though it's completely possible what you and I think when we say "pairing" might be different. For example, the ability to not check Twitter feed would only be an issue if you are pairing for hours at stretch. While my pairing sessions are rarely longer than an hour.
- soneca 5y ago
  If they are pairing to do high level design, then you are not disagreeing with GP
  - coryrc 5y ago
    I was just looking at their changes recently, plenty of regular improvements to code.
- brandall10 5y ago
  Some companies do a strict all-day XP style pairing session, where a paired team works on a synced schedule (clock-in/clock-out/meetings/lunch). Pivotal Labs in particular follows this model.
lenkite 5y ago
Pair Programming always has some ramp-up "friction" time with a new partner where you get over the awkwardness and embarrassing phases (ashamed to make mistakes in front on each other). And there are some partners you will simply be unable to pair with unless both of you take the time to give each other significant space/time. (ugghh..that sounds like some corny relationship therapy). But when it's going smoothly, wow, you can code large blocks of code in a few sessions and the structure/design of code comes out looking really good. You can refine each others ideas as you code or even arrive at something better when the flaws are pointed out in the individual approaches. I have also tried tri-programming also where a third guy joins in for miscellaneous stuff like quick exploration, how-to-do-that's or research activity while the primary pair focuses on the main backlog. This is helpful because when you are in the groove, you really don't want to get side-tracked. I am a social, introverted recluse and even I found pair-programming objectively useful. It all sucks doing it remotely though and frankly not worth it.
- koide 5y ago
  I've paired remotely and haven't found it particularly problematic. Even without plugins, which tend to suck. Driver shares the screen with the ide, zooms it up, and it's good enough to be useful in my experience.
- XorNot 5y ago
  > It all sucks doing it remotely though and frankly not worth it. I find this perspective wild. I cannot possibly imagine pair programming as productive, or tolerable if it was being done in person. Whereas doing it using screen sharing tools from the comfort of my home (or private office but who's had one of those recently?) - well I've actually done this, and it worked great. No body hygiene or smell issues to get with, no one snacking or drinking near you, no crowding or extra CO2 and sweat - just a nice tight feedback loop which people can dip in and out of without disruption, join and stop easily etc. The idea of pair programming with other people physically in the room with you...I can't think of anything more unpleasant.
psysharp 5y ago
When a problem is new and fresh for each participant, pairing can be a great tool to connect with both the problem and each other's innate skillset, IMO.
kqr 5y ago
> I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. Are you against co-pilots in aircraft for the same reason?
- sgillen 5y ago
  I think this is a false equivalence. If a programmer has a medical emergency during their working hours that’s terrible but doesn’t put others in danger.
  - kqr 5y ago
    A co-pilot isn't just useful for medical emergencies. They can double-check judgments, decisions, and plans as well. Because people sometimes interpret signals incorrectly or misunderstand contexts. That can happen to a programmer just as much as a pilot, and it can be even more destructive. You could argue software generally isn't life and death, but who knows? You might end up working on something like curl or sqlite which may well have played part in the implementation of emergency services in some country.
    - jenscow 5y ago
      That's what code reviews are for. Unless you're working directly on a live server.
      - kqr 5y ago
        And I would be 120 % with you if you said > I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and requires a second pair of eyes e.g. through code review or pairing to produce quality work. But that's not what the comment I responded to said!
ryanbrunner 5y ago
> I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more well designed product. You could use the same argument you're using to say we shouldn't do code reviews, because we should trust that every developer is competent. Also, at least in my experience, design isn't primarily or even mostly confined to an initial design phase. Most of the 'design' of a problem occurs when you're actually coding.
- vidarh 5y ago
  My experience is that pairing is deeply disruptive to my exploration of a design. It forces me to slow down and verbalise something that I can clearly visualise in my mind, when the fastest way to externalise it for me is often to write the code and show it. I'm happy to walk people through a prototype afterwards and discuss it and if necessary throw the thing away and start over or significant revise it. I'm not happy to have someone disrupt my thinking about a problem while I'm trying to focus. Fundamentally I tend to think that people who insist pairing is ok to impose on people think everyone is like them, and don't see that it's forcing out people with different ways of thinking and processing problems. Ultimately I think it's bordering on discriminatory in that it's selecting for extroverts who don't burn out by the extensive amount of interpersonal contact pairing forces rather than selecting for results. For my part I will never work somewhere that imposes pairing. I'd rather leave software development altogether than suffer through that, because it's not worth the exhaustion and the reduction in throughput other than occasionally (e.g. while training someone or walking people through a prototype). Thankfully I have the luxury of not having to take that shit.
  - pydry 5y ago
    Mine is the exact opposite. Slowing down and explaining design firstly helps to clarify things in my own mind and the pairer will usually see things that I missed as I explain. I also find that getting stuck alone on a problem kicks me into a procrastination spiral whereas I tend to find it easier to push on when I'm stuck with someone. It also helps prevent me from getting into a spiral of second guessing every technical decision ive made in the last month. I dont really think people take to pairing or not on the basis of its prima facie effectiveness though, but rather whether they enjoy programming as a solitary or social activity. Really, I think teams should be set up to ensure people who like pairing to be together and vice versa, coz i feel just as miserable working alone all day every day as you do pairing.
jenscow 5y ago
That's your problem with pairing - you're able to think deeply, so pairing is a hindrance to you. The majority of developers, in enterprise at least, tend to write the first piece of code that enters their head, and they only consider the immediate problem. The code Just Works, so pairing is sufficient for them. Whenever I've driven a pair session, I tend to go back and finish it - fill in the blanks: handle edge cases, tests, security, a11y, etc. Pairing is a good tool for creating prototypes or combining ideas, and in imbalanced situations like you say. But for long-term stable production, code reviews are generally more suitable.
vidarh 5y ago
I hate it enough for day to day use that I'd leave a job over it if I was forced to. It's fine occasionally for training, as you suggest, or for explaining a design to people, but like you I feel it's an encroachment. Thankfully I'm experienced enough that I can afford to refuse to take jobs that impose it.
dimmke 5y ago
I have to pair program all the time at my job. It's just the nature of a lot of the work I do. However, all the pair programming I do is over screensharing where we aren't physically next to each other. The tips in this article are excellent. The two big ones that will make me hate pair programming with you: Leaping on errors too quickly and giving low-level instructions. The big sin I commit: Driving too fast When pair programming is going well, it really does speed up development time and increases the amount of people who know about a section of a codebase which is always good. But when it's bad, it's really really bad.
wowokay 5y ago
I am of the same mind, I found value in pairing on small tasks, or maybe a code review/training, but generally I find it promotes 2 negative concepts. 1. That all developers can do/produce the same results. 2. That some people become dependent on others to write code. #1 fuels the management misconception that hiring or moving devs will result in more work getting done. #2 makes some individuals short change the PR review process. (I.E I was there when it was written, or I trust that pair thought through all the steps. I think it’s great in a lot of situations, where something new is being started or for KTing, but as a daily practice it reminds me of those old school group projects where 1 person does all the work and the other gets the credit.
girafffe_i 5y ago
I've been trying to collect more sentiments on when people dislike pairing, and for what underlying reasons. Very curious to hear if you've thought about ego being apart of your position: if two minds can work through a design or implementation faster, but at the cost "I didn't get to figure this out myself" then you are prioritizing some personal puzzle solving pride over overall project efficacy. Maybe this doesn't matter working for"the man" but, if you started your own business and it's empirical that working with others helps solve problems faster, would you have a different position?
- ParetoOptimal 5y ago
  > you are prioritizing some personal puzzle solving pride over overall project efficacy. Esteem and self-actualization are a part of maslows hierarchy of needs, I don't think this case is as simple as "pride".
Mezzie 5y ago
It's SO task dependent. I'm happy to work this way when I'm doing UI/UX or end-user touching work; so much of that boils down to 'predicting the ways in which the chaos apes will behave' that having another perspective is useful. When I'm doing database design, don't talk to me unless I ask you to: All it does is make me want to choke you and take me out of the flow.
nkingsy 5y ago
I’ll agree that two senior engineers pairing can feel painful and slow compared to each working solo. I’m currently doing pairing sessions with two junior engineers and it’s been great for everyone. I’m also pairing for 2 hrs/wk with the other senior engineer on the team to explore an ambitious new project, and it feels like we just constantly grate on each other with slightly different designs in our heads. I will say, though, that the conflict our pairing generates is valuable as it often illuminates decision points that would be good to escalate to the larger working group.
karmakaze 5y ago
Pairing doesn't have to be all or nothing. For tasks that clearly work better individually such as initial deep thought into an area, do that. For other tasks, getting in the habit of pairing has many secondary benefits that are only appreciated after doing it a lot for a while. Even after appreciating these benefits, it's far too easy in this age of remote work to ignore pairing, so it takes intentional action to maintain unless your team has already developed automatic pairing patterns. I especially like pairing with less senior devs that actually ask every question they think of. When I hear it, I try to pause and think what's this actually about and give as deep an answer as I can. Often this leads to discoveries that can simplify understanding, design and/or implementation. You get out of it what you put into it.
beebmam 5y ago
It's funny, I have the opposite perspective. For me, I think design, or brainstorming, is best done independently after long periods of time of thinking unconsciously about the problem.

slaymaker1907 5y ago

You missed what I consider to be the greatest strength of pair programming: debugging. If one person gets stuck on something, the other person often still has some ideas on how to proceed. Even if you don't pair program, you absolutely should be debugging with someone else if possible.

jordanbeiber 5y ago

In, for example, an enterprise setting you rarely want individually clever and creative solutions. You generally want domain expertise shared in a team, and continuously molded to perfection over time. Mobs and pairs can really shine here, but it all depends on the individuals. In teams where it works well it’s an enormous value add, in my experience, and the hive mind you reach after a year or two within a team is fantastic. As a dev manager I let the teams decide, but looking at team flow over time, it looks hard to beat a well functioning pair or mob team. IMHO & YMMV, and so on.

epolanski 5y ago

I have recently switched teams and I'm in one where most programming but trivial tasks are done in pair. I can see lots of pros and few cons: - knowledge sharing, especially business, domain, old code, etc. The biggest stopper in writing software in large organizations is rarely technical difficulty but context - focus. If I'm alone I get distracted much more, music, youtube, socials, I know this is on me, but getting distracted while pairing is hard and rude. I'm also much more organized and a coworker is much better than a rubber duck. cons: - you are blocked from working if a coworkers schedule is not aligned Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.

blindmute 5y ago
Con: almost no one likes doing this and you'll bleed talent Con: you're spending literally double on engineers for the same amount of work done
eikenberry 5y ago
> Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming. I think this is the key takeaway with one missed point. IMO it definitely does produce more work vs. solo programming but that work is sub-par. The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.
- gregkerzhner 5y ago
  The part of my brain which thinks deeply and produces elegant solutions simply shuts down when I constantly have to explain my thought process to someone else. I actually have the same problem in pair programming interviews - my brain tends to freeze up and comes up with strange, hacky workarounds at best. Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who produce their best work when they can focus, alone. If pairing works for you, then that’s great, but it needs to be consensual and optional. The problem with pairing is that it tends to be championed and enforced by more social workers (especially managers), and forced on the less social ones, who are often not in a position to refuse.
  - RHSeeger 5y ago
    > If pairing works for you, then that’s great, but it needs to be consensual and optional. This is the key in my mind. Pair programming doesn't work for me, based on past experience. Pair design works great, and rubber ducking into a slack channel (that people expect that kind of thing to be in); those are things I find highly useful. But when it comes time to actually write code, I tend to work best alone. I think part of the reason for this is that I tend to work through designs and possible implementations in my head, but by writing code. Then I'll discuss those designs to come up with some possible issues (pros/cons/etc). Then I'll work on implementing what seems likely to be the best choice (which is may not be once coding starts). By the time I get to coding, most of the impact of someone else being involved is just going to be catching typos. Or possibly code written in a hard to maintain way... but code reviews will catch that just as well (probably more so, because the person reviewing it _wasn't_ there when it was written).

jatins 5y ago

Google's Jeff and Sanjay are famous for pairing together, and most would think they are fairly competent people. Pairing brings a new perspective to the problem and, for me, the social element is also valuable in that you also build relationships by pairing. Though it's completely possible what you and I think when we say "pairing" might be different. For example, the ability to not check Twitter feed would only be an issue if you are pairing for hours at stretch. While my pairing sessions are rarely longer than an hour.

soneca 5y ago
If they are pairing to do high level design, then you are not disagreeing with GP
- coryrc 5y ago
  I was just looking at their changes recently, plenty of regular improvements to code.
brandall10 5y ago
Some companies do a strict all-day XP style pairing session, where a paired team works on a synced schedule (clock-in/clock-out/meetings/lunch). Pivotal Labs in particular follows this model.

lenkite 5y ago

Pair Programming always has some ramp-up "friction" time with a new partner where you get over the awkwardness and embarrassing phases (ashamed to make mistakes in front on each other). And there are some partners you will simply be unable to pair with unless both of you take the time to give each other significant space/time. (ugghh..that sounds like some corny relationship therapy). But when it's going smoothly, wow, you can code large blocks of code in a few sessions and the structure/design of code comes out looking really good. You can refine each others ideas as you code or even arrive at something better when the flaws are pointed out in the individual approaches. I have also tried tri-programming also where a third guy joins in for miscellaneous stuff like quick exploration, how-to-do-that's or research activity while the primary pair focuses on the main backlog. This is helpful because when you are in the groove, you really don't want to get side-tracked. I am a social, introverted recluse and even I found pair-programming objectively useful. It all sucks doing it remotely though and frankly not worth it.

koide 5y ago
I've paired remotely and haven't found it particularly problematic. Even without plugins, which tend to suck. Driver shares the screen with the ide, zooms it up, and it's good enough to be useful in my experience.
XorNot 5y ago
> It all sucks doing it remotely though and frankly not worth it. I find this perspective wild. I cannot possibly imagine pair programming as productive, or tolerable if it was being done in person. Whereas doing it using screen sharing tools from the comfort of my home (or private office but who's had one of those recently?) - well I've actually done this, and it worked great. No body hygiene or smell issues to get with, no one snacking or drinking near you, no crowding or extra CO2 and sweat - just a nice tight feedback loop which people can dip in and out of without disruption, join and stop easily etc. The idea of pair programming with other people physically in the room with you...I can't think of anything more unpleasant.

psysharp 5y ago

When a problem is new and fresh for each participant, pairing can be a great tool to connect with both the problem and each other's innate skillset, IMO.

kqr 5y ago

sgillen 5y ago
I think this is a false equivalence. If a programmer has a medical emergency during their working hours that’s terrible but doesn’t put others in danger.
- kqr 5y ago
  A co-pilot isn't just useful for medical emergencies. They can double-check judgments, decisions, and plans as well. Because people sometimes interpret signals incorrectly or misunderstand contexts. That can happen to a programmer just as much as a pilot, and it can be even more destructive. You could argue software generally isn't life and death, but who knows? You might end up working on something like curl or sqlite which may well have played part in the implementation of emergency services in some country.
  - jenscow 5y ago
    That's what code reviews are for. Unless you're working directly on a live server.
    - kqr 5y ago
      And I would be 120 % with you if you said > I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and requires a second pair of eyes e.g. through code review or pairing to produce quality work. But that's not what the comment I responded to said!

ryanbrunner 5y ago

> I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more well designed product. You could use the same argument you're using to say we shouldn't do code reviews, because we should trust that every developer is competent. Also, at least in my experience, design isn't primarily or even mostly confined to an initial design phase. Most of the 'design' of a problem occurs when you're actually coding.

vidarh 5y ago
My experience is that pairing is deeply disruptive to my exploration of a design. It forces me to slow down and verbalise something that I can clearly visualise in my mind, when the fastest way to externalise it for me is often to write the code and show it. I'm happy to walk people through a prototype afterwards and discuss it and if necessary throw the thing away and start over or significant revise it. I'm not happy to have someone disrupt my thinking about a problem while I'm trying to focus. Fundamentally I tend to think that people who insist pairing is ok to impose on people think everyone is like them, and don't see that it's forcing out people with different ways of thinking and processing problems. Ultimately I think it's bordering on discriminatory in that it's selecting for extroverts who don't burn out by the extensive amount of interpersonal contact pairing forces rather than selecting for results. For my part I will never work somewhere that imposes pairing. I'd rather leave software development altogether than suffer through that, because it's not worth the exhaustion and the reduction in throughput other than occasionally (e.g. while training someone or walking people through a prototype). Thankfully I have the luxury of not having to take that shit.
- pydry 5y ago
  Mine is the exact opposite. Slowing down and explaining design firstly helps to clarify things in my own mind and the pairer will usually see things that I missed as I explain. I also find that getting stuck alone on a problem kicks me into a procrastination spiral whereas I tend to find it easier to push on when I'm stuck with someone. It also helps prevent me from getting into a spiral of second guessing every technical decision ive made in the last month. I dont really think people take to pairing or not on the basis of its prima facie effectiveness though, but rather whether they enjoy programming as a solitary or social activity. Really, I think teams should be set up to ensure people who like pairing to be together and vice versa, coz i feel just as miserable working alone all day every day as you do pairing.

jenscow 5y ago

That's your problem with pairing - you're able to think deeply, so pairing is a hindrance to you. The majority of developers, in enterprise at least, tend to write the first piece of code that enters their head, and they only consider the immediate problem. The code Just Works, so pairing is sufficient for them. Whenever I've driven a pair session, I tend to go back and finish it - fill in the blanks: handle edge cases, tests, security, a11y, etc. Pairing is a good tool for creating prototypes or combining ideas, and in imbalanced situations like you say. But for long-term stable production, code reviews are generally more suitable.

vidarh 5y ago

I hate it enough for day to day use that I'd leave a job over it if I was forced to. It's fine occasionally for training, as you suggest, or for explaining a design to people, but like you I feel it's an encroachment. Thankfully I'm experienced enough that I can afford to refuse to take jobs that impose it.

dimmke 5y ago

I have to pair program all the time at my job. It's just the nature of a lot of the work I do. However, all the pair programming I do is over screensharing where we aren't physically next to each other. The tips in this article are excellent. The two big ones that will make me hate pair programming with you: Leaping on errors too quickly and giving low-level instructions. The big sin I commit: Driving too fast When pair programming is going well, it really does speed up development time and increases the amount of people who know about a section of a codebase which is always good. But when it's bad, it's really really bad.

wowokay 5y ago

I am of the same mind, I found value in pairing on small tasks, or maybe a code review/training, but generally I find it promotes 2 negative concepts. 1. That all developers can do/produce the same results. 2. That some people become dependent on others to write code. #1 fuels the management misconception that hiring or moving devs will result in more work getting done. #2 makes some individuals short change the PR review process. (I.E I was there when it was written, or I trust that pair thought through all the steps. I think it’s great in a lot of situations, where something new is being started or for KTing, but as a daily practice it reminds me of those old school group projects where 1 person does all the work and the other gets the credit.

girafffe_i 5y ago

I've been trying to collect more sentiments on when people dislike pairing, and for what underlying reasons. Very curious to hear if you've thought about ego being apart of your position: if two minds can work through a design or implementation faster, but at the cost "I didn't get to figure this out myself" then you are prioritizing some personal puzzle solving pride over overall project efficacy. Maybe this doesn't matter working for"the man" but, if you started your own business and it's empirical that working with others helps solve problems faster, would you have a different position?

ParetoOptimal 5y ago
> you are prioritizing some personal puzzle solving pride over overall project efficacy. Esteem and self-actualization are a part of maslows hierarchy of needs, I don't think this case is as simple as "pride".

Mezzie 5y ago

It's SO task dependent. I'm happy to work this way when I'm doing UI/UX or end-user touching work; so much of that boils down to 'predicting the ways in which the chaos apes will behave' that having another perspective is useful. When I'm doing database design, don't talk to me unless I ask you to: All it does is make me want to choke you and take me out of the flow.

nkingsy 5y ago

I’ll agree that two senior engineers pairing can feel painful and slow compared to each working solo. I’m currently doing pairing sessions with two junior engineers and it’s been great for everyone. I’m also pairing for 2 hrs/wk with the other senior engineer on the team to explore an ambitious new project, and it feels like we just constantly grate on each other with slightly different designs in our heads. I will say, though, that the conflict our pairing generates is valuable as it often illuminates decision points that would be good to escalate to the larger working group.

karmakaze 5y ago

Pairing doesn't have to be all or nothing. For tasks that clearly work better individually such as initial deep thought into an area, do that. For other tasks, getting in the habit of pairing has many secondary benefits that are only appreciated after doing it a lot for a while. Even after appreciating these benefits, it's far too easy in this age of remote work to ignore pairing, so it takes intentional action to maintain unless your team has already developed automatic pairing patterns. I especially like pairing with less senior devs that actually ask every question they think of. When I hear it, I try to pause and think what's this actually about and give as deep an answer as I can. Often this leads to discoveries that can simplify understanding, design and/or implementation. You get out of it what you put into it.

beebmam 5y ago

It's funny, I have the opposite perspective. For me, I think design, or brainstorming, is best done independently after long periods of time of thinking unconsciously about the problem.