On Pair Programming
martinfowler.com
martinfowler.com
but boy it smashes productivity with a frying pan and keeps hitting it.
Pair programming - bad for startups that want to hammer out quick code, bad for enterprises that want to hit deadlines on stretched resources.
It's a tough one to argue for.
Edit: Things I want to try - Tennis Programming - sit next to each other, one writes the tests, one writes the code, swap round often, run on shared disk space or something. Spending ages watching someone else code is just being a human syntax checker. Swapping and diving in to code after ten minutes might be more interesting.
It's like writing a joke or a scene in a movie then handing the paper to your writing partner. You need fast feedback.
I am reaching for something that actually rocket boosts both people in the pair (and implies some degree of equality of skill). I have had that experience a couple of times - basically lock good people in a room with a clear tight mission and keep distractions away. Building that in a cube farm with project reporting requirements is almost impossible...
Let them watch for a bit (no more than a few hours) to learn how things work. Then let them drive. Let them explore, make mistakes, but accomplish something and push to prod.
This should make sure all the gaps get filled in quickly. And not 2 weeks later they still don't know how to connect to the database or something basic. Quickly the new members are full team members that can join the normal pairing schedule of the experienced team members.
Writing very clear code is not just a skill but an investment in resources. There are diminishing returns (a couple of my employers have had a much lower pain-point than I do), and making it fairly clear followed by explaining the rest is usually more effective. Admitting a fault expresses empathy, and honesty, and sometimes inspires the other person to get invested by proposing a solution, and who wants code owners that aren't invested in the code? Besides, zero gotchas is perfection, and we all know what perfect is the enemy of.
In scaling up a team, the alternative to getting new people to high competence on existing systems is to let them become highly competent on new systems. Over time though the old people only know the old stuff and the new people the new stuff, and eventually nobody knows what's going on. People only figure this out after the old people have already left. Old problems that haven't been fixed don't get talked about every day so it may be six weeks or a couple months before you figure out John was the only one who knew some bit of information and he's happy at his new job, and Sheila, the only other person who knew, has been gone for 8 months. And the person who wrote the thing just showed up on LinkedIn for getting a promotion at wherever they've been for 2 years. I wonder if they'd forward my resume to HR?
I want the new guy to eventually be able to do everything I can do so that I don't feel guilty about wandering off to do something else, internally or externally. These people can also take over answering for old arguments that I'm tired of having. Being able to tag out on that sort of stuff does wonders for my sanity.
I can certainly do all of this without pairing, but a lot of the time it's much faster and more illuminating for both of us. Especially when I can see how they stumble. Out of the mouths of babes, as it were. Maybe my assumptions were wrong. Maybe there's a simpler way to do this, or at least a more consistent one.
Does that mean that I've occasionally been the Jim in "Why the hell did they lay Jim off?? We needed him." conversation? Yes, yes I have. But I can tell you, being laid off feels a lot better than going down with the ship. Survivor guilt, being the last employee who still knows how to do onerous tasks, wondering who'll be next, constant existential crises feeling like it's on you to save the ship... It's all awful, and much, much later you start to recognize the scar tissue. Lay me off with a nice severance while there's still some money and a sense of guilt left, please and thank you. If you don't see my value it's because you're too busy looking in the rear-view mirror rather than what to do next anyway.
1) They see something you did not, you get past your block, and start being productive again.
2) They see nothing else, so you know that you actually have a thorny problem to solve, so you get to it.
In those small doses, I like pair programming. But I would not care to do it more.
In general I think this article is pretty good. It seems to bias towards "pair programming is better" where as I biased towards "pair programming can be really bad". In the end, it's a tool like anything else. Sometimes pairing is the perfect way to tackle something, and other times it's the last thing you should be doing.
Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of mental resilience, that most people would be okay and that everybody should "give it a go". I don't feel that's true at all, and certainly I'm one of those people that would be made ill by an environment of constant forced pair programming _even though_ I manage to hold down a job, appear "fairly normal" from the outside and do pretty well as a mostly solo programmer.
I was part of a company that went down the road of XP...it was very difficult for the first 6 months but it changed my life.
I am much different now than when I started (I am actually in a role where communication is a big part of my role)...I forced myself to stick it out. Not going to lie there were a lot of tough moments on long train-rides home but I not only learned a ton from those around me, but it changed how I connect and interacted with folks.
Granted it is not for everyone, I would especially say those who want to punch-in, browse reddit, and punch-out...but it is the one thing that I've found which brought up the water-line of a team I was working on.
I'm still not convinced that it would be good for my wellbeing and happiness, given that I've experienced PP for a couple of weeks on and off (not anywhere near 6 months like you!).
I do like to collaborate with co-workers to solve problems, for sure, and we will often share screens and benefit from putting our minds together. But PP for 6 ... 8 hours a day, without periods of quiet contemplation, spent with my own thoughts? When I think about it like that, my heart sinks.
I've only been at one company that has so I'm not sure how other shops do pp. What I find really helps me is actually taking turns at the keyboard with a timer every 10, 15, or 25 (pomodoro work interval) minutes. Take frequent breaks. Also, splitting it into two 2-hr sessions, one in the morning and one in afternoon. Increasing the time between your turns by turning the pair into a mob also helps.
edit: And maybe only 2-3 times a week.
Neither is improving productivity or buy-in. I think pair programming works best when, upon discovering any two independent tasks, you have the pair split up for a while, do the task, and bring back the code to share. This is not about going faster, it's about getting a break from one socially and mentally intense activity. It's similar to the reason I vehemently insist on a 'bathroom break' for any meeting over 90 minutes. Get some air. You'll get to the outcome faster, and often a better outcome.
I know a few people who'd go so far as to suggest that these practices (being volun-told into all-day pair programming, or god help you, mob programming) are discriminatory. I'm not sure I'd go that far but if one wanted to argue that I'm not gonna stop them.
My take: I like it as a training or mentoring activity. I like it as a voluntary activity for slowing down and being careful on trickier bits of code.
But I don't like it nearly so much as a mandatory thing. The social dynamics here are tricky. I'm a pretty severe introvert, and am quickly exhausted by what I experience as socially intense situations. I've been paired with exuberant, highly extraverted people, and the results were, frankly, disastrous. Within no time at all, I would be deliberately letting obvious bugs sail past just to avoid having to have interactions that I was finding to be increasingly mentally and emotionally taxing. And yet I'd still come out of it feeling so worn out that I'd be off my game for days. I guess you could say that that was negligent on my part, but, truth be told, once the cortisol levels in your bloodstream get high enough, you're just not thinking clearly anymore. And, in any case, it would be much easier for me to wait and put a more thoughtfully composed, "Hey, I just noticed..." comment in the async code review than it would to try and clearly verbally explain what I saw to someone who dislikes pauses in a conversation so much that they literally would not allow me 15 seconds to compose my thoughts.
So, don't call it discriminatory, but, still, it can easily end up making people upset and escalating intra-team tensions in return for not much. There's a term of art in some sects of Buddhism that I like to describe these sorts of well-intentioned but poorly executed plans: "Unskillful." Indiscriminately following a prefabricated, one-size-fits-all script often ends up being unskillful.
I think maybe it's a bit like test coverage. More code coverage is good, but, at the same time, I typically see the lowest quality test suites in codebases where it's been set up as an explicit performance metric and measured by some tool. Similarly, when doing Scrum-type-workflows, I find velocity to be a useful concept up until the exact moment when some manager finds out about it and asks for it to be included in a report, at which point it immediately becomes the most harmful thing ever.
That said, and for the sake of contradicting myself repeatedly, it sure is useful sometimes, and I'd hate to work at a place that isn't supportive of developers and teams who want to do it.
This is 100% my experience. I don't do pair programming in any formal capacity, but do occasionally sit nearby while others write code.
I despise telling people they're screwing up at the rate they're screwing up in real time, especially when I'm more senior and they're just not noticing things that I see immediately.
Compounding this, I'm not great at quickly expressing myself verbally, and so it's not always clear what I'm pointing out. Even when I'm perfectly clear there's an element of a flustered typist trying to correct on the fly.
Combine this with introversion and mild social anxiety, and I'd say if my workplace instituted mandatory pairing I'd be looking for a new job the day they announced it.
At first it was terribly exhausting and not very fun but over time it just becomes a part of your day. I think most people can get used to the increased level of social interaction as just something they do as part of work.
What's essential is taking breaks. We had a pomodoro timer running on every team. Some teams took a 15 minute break every hour. Some took breaks more frequently, some took breaks less frequently. I noticed that more introverted teams took breaks more often.
And in the tech world, it's very easy to encounter people more weighted toward the autistic end of the spectrum. Pair one of those with one of the HSP people, and you have a really shitty combination. The HSP will expend most of their energy appeasing and compensating for the needs of the autist. The autist will feel frustrated, and the HSP will feel fully exhuasted.
Pairing is a skill. Practiced regularly it becomes easier and smoother, like any other skill.
Highly sensitive people, however, seem to be given to feeling the emotions of others without even the necessity of verbal indications.
In my experience, they are opposite ends of some spectrum. Perhaps "normal" people fall rather in the middle.
Sure, if your coworkers suck it's going to be horrible. But I've found that most people who go into programming are themselves introverts, so as you get to know your teammates and build trust, you know how to interact with each other, take breaks, not talk over each other, etc.
In fact, I think someone who is more extroverted or someone who is loud/obnoxious, would have a more difficult time pairing since it might be harder for them to listen to the other person and step back a bit.
Pairing causes the social part of my brain to activate which is fine, but I cannot also think analytically in real time while speaking. To do so is somewhat stressful and that stress just mounts up the longer the pairing session lasts.
I was diagnosed autistic at the end of the last year, because I was going to therapy to deal with suicidal ideation caused by the anxiety I was carrying around with me from work. A lot of that is from long sessions of intense pairing leaving me essentially bankrupt of energy to use in my personal life.
There's just so many different non-programming things to keep track of for me as an autistic person while pairing
• Am I giving good input as the coordinator?
• Is my language acceptable?
• Is my tone correct?
• When pairing my mind goes blank for 2-5 seconds at a time and it can strike in the middle of a line, so I forget what I was trying to do and have to re-read the previous lines to remember, does this give my co-workers the impression I'm inept?
• Social anxiety causes hand tremors which make it difficult to type. Expressing thoughts now takes an inordinate amount of time to register via keyboard. Is my coordinator getting frustrated by this? Would it be rude to ask them to take over? Should I do this or is it better to persevere?
Pairing plus frequent high population meetings equals a workplace that's nigh on inhospitable for people like me with sensory processing disorders. Even though I'm sure I'm capable of the meat of the work I cannot do it without the extra steps my company mandates, and these steps reduce my capability in the areas I do exceed!
This happens to me in whiteboard interviews and other high anxiety situations. There is no need to be atypical or suffer any disorder to feel this. Undoubtedly, this likely happens to a big chunk of the population given the disgust most people have for whiteboard interviews and other anxiety inducing situations.
Effectively, in places we are comfortable adding AI style assistance, odd that we shun just the I.
To that end, we agree teams are typically needed. Shame we don't focus our measurements on the team. Feels a great way to kill a team is to measure it's individuals. :(
Being unable to program without a partner is a serious handicap and will happen many times in a year, especially if people are sick or on vacation.
I get that it is a flag. But a lot depends on degree. Sport metaphors are often a stretch, but if they are saying they need their team to play, that isn't super scary on its own.
If they need their full team to practice, that changes. And if they need a specific team member or they refuse to play, that is terrible.
And you simplify the IDE point heavily. Just picking up one is not going to get you productive right away. Might as well have that sick partner. :)
Had a chance to closely observe a session once. Looked through the code later--total garbage.
Apparently it works for some, but you couldn't pay me to do it.
(Also, seems unfair to programmers that can't hear well or need other accommodations.)
It is also a great training tool. Can’t tell you how many times I’ve had junior engineers ask me about something that I thought was common knowledge or wouldn’t have thought to mention cause I thought it was trivial.
It’s a tool in your toolbox. Don’t use it on every problem.
That's pair programming, except the modal dialog box is a smelly human looking over your shoulder.
Some of my best and most important projects have started out as terrible diversions that after a while even I begin to wonder if I shouldn't be doing it.
Frequent peer review and collaboration on important architectural decisions is sufficient. Sitting down and actually writing code together is unnecessary torture.
Imagine some legendary coder like Linus Torvalds or John Carmack writing the Linux Kernel or the Quake engine side by side with another dude at their keyboard all day every day. It's a fucking absurd and infantile concept.
- Interacting with people is exhausting for me. I can't imagine having to be in constant communication with someone sitting right next to me, 7-8 hours a day, every workday.
- Writing software requires deep concentration, and the constant interaction seems like it would destroy the required concentration.
- Having to put everything I'm thinking into words, waiting for a reply, constantly being atuned to social niceties -- how can that be compatible with doing productive work? (Not in general, but for me.) I may stare at the screen for a while, trying to figure something out. A number of ideas go through my head. I run through a bunch of approaches quickly: that's stupid, that can't work, that might work, that's idiotic, ... I go back and reconsider the better ideas in more detail, ... First of all, I am reacting to incompletely formulated thoughts. Forcing those thoughts to be more formulated, to the point that I can describe them, definitely changes the way I would work. Maybe for the better, but definitely different. Second of all, saying "that's idiotic" to a coworker probably isn't a good idea.
In general, pair programming seems like it would take an extremely absorbing and enjoyable actvity, and turn it into torture. For me.
I read a New Yorker (I think) article about how Jeff Dean and Sanjay Ghemawat work together. They seem to do pair programming extremely successfully. Good for them. I have no doubt that it works well for some people. I am quite sure I'm not one of them.
What I did at first was as you describe - chasing down lines of thought quickly, then saying what I thought the answer was. Then I learned to vocalise it through practice. And if I need a moment to think, I can just say "gimme a sec to think" or "can I take a break?" and that's all it takes.
When the design is ready I want to present it to people and they have to prove to me that I produced crap. If they do I am back to a drawing board . If not (and that became the most often outcome after few years in the industry) then f.. off leave me alone and I'will put my design into a code. The last thing I need at this point is someone breathing down my neck.
After the code is finished and I am reasonably happy with it I would like me some code review if condition allow. Not very often as I mostly work either on my own products and do not have people around for code review and/or making some extra dosh doing the same thing as consultant and consultants do not often get this luxury.
All in all I can see no benefits at all in doing pair programming for myself. If someone is happy with it and their boss lets them do it then sure, go full monty. Just please do not force this style on people. Not everyone can tolerate close contact for extended time.
If anyone is hiring I'll apply.
My company (World Wide Technology - Application Services) is hiring -- we have some physical offices across the U.S. and a few in other countries, as well as a growing "virtual office" team (which, while remote, is still in frequent communication and pairs remotely). Email me if you want to talk more or be put in touch with someone about applying (my email address is in my profile).
But it's a complex skillset in its own right, hard to learn from a book. And in turn it requires a degree of corporate sanity and cultural safety that is quite rare. It's also a very humbling experience.
Lots of people have had bad experiences, or believe that they would have a bad experience. I just like to place on the record that my experience of pair programming has been amazing and I look forward to the day when I can return to it.
It's the environment that actively sabotage such way of working, or attempts to mandate it as a ritualistic practice, that is unnatural.
A natural extension of two people in front of a whiteboard, nothing more.
... which is really me distracting myself, because the guest content is usually of a very high quality. Maybe the personal branding is justified here because Martin Fowler curates and edits the pieces?
> As the site got more popular, I felt I could use it to help other people get more visibility for their writing, so I've steadily increased publications from others here. I vet each article before accepting it - and often do a considerable amount of developmental editing too - so there isn't a high rate of publication. I do believe, however, that the quality of the articles matters much more than the quantity.
A lot of dev teams suffer from the iamverysmart problem already, and PP just seems like a way to exacerbate it.
2) You'll pick up his shortcut fluency in about two days of pairing ... I taught my co-founder Emacs and Clojure at the same time in about two days of pairing
Instead of absorbing the concepts behind PP into the mamagement, they'll declare "our team does PP". We're a PP team now. Or Agile. Or Lean. Or whatever. And they'll fit the team to the book, rather than the other way around. It's rife and terrible.
Sure, I "do" PP... maybe a total of an hour a week, to mentor a junior. Which I do without knowing it's "PP", or calling it that, or caring about that as a practice.
When a managerial practice gets a name, it causes more harm than benefit, because every drone manager out there will get all procrustean and damage existing workflows with it.
I think programmers should be considered professionals who can do their own work quite well on their own, and held to that standard.
I've done a lot of pairing and never felt that I was somehow being slighted or considered incapable. I've felt slighted in cases when I wasn't pairing, though.
first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in programming, thinking, speed, brainstorming, etc. it simply does not allow for moments of thoughtful rumination or experimentation. it’s just like having pairs in school. it never works unless the two people are copies of each other or both people have spent time doing and thinking about the task themselves independently beforehand.
i think working in pairs or small groups for design, review (or a post-review discussion), and especially debugging works quite well. it also works well when there’s a new person being ramped up or someone in the pair who is particularly knowledgeable about a portion of the interfacing code or sticky points. but two people sitting at a computer implementing? that only works for a very, very short amount of time, if at all.
i refuse to work for any place that forces this upon workers. it creates just another selection bias in interviews. engineers already look for people just like them, and this just adds to that bias.
and the articles for the benefits does nothing to say what pair programming does to actually enable the benefits listed. all of the benefits can be accomplished by shared design plus individual design, shared review, shared debugging, and individual implementation.
Aviation, some surgeries.
You know, low-stakes stuff.
Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in.
Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!). There is always time to correct your mistakes.
The easiest time to catch mistakes is early.
The easiest time to catch a mistake is when it's made, which is as true of surgery or flight as of software development.
That's why I rely on type systems, tests and whenever I can, someone next to me asking "why?".
pair programming and the articles proposing it do nothing to help catch mistakes early. i would argue that they even delay catching mistakes due to what i'd call deconstructive interference during the implementation process.
there are plenty of much more systematic ways to catch mistakes earlier than just slapping pair programming onto the software process.
Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery.
> if you want to ensure quality, in practice, you will want different eyes to look at the code
Totally agree, but that's an argument for code review, not pair programming. PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code.
> The easiest time to catch mistakes is early. TDD and CI are a more effective way of doing this.
When do they occur?
> PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code.
I'd argue that it is a good way, based on my experience of both methods. Code reviews are better than winging it, but given the choice between a PR-and-review process and pair programming with trunk development, I'd take the latter every time.
I agree with the virtues of TDD and CI, I see pair programming as a useful way to help with TDD.
> I'd argue that it is a good way, based on my experience of both methods.
And with similar experience, I’d disagree. Paired programmers are focused on writing the code not reviewing. The whole point of code reviews is to let someone divorced from the problem solving process objectively the code.
for both pilots and surgeons, no one is doing the same job at the same time. pilots and surgeons, when performing on the same flight or surgery, have different roles, and it's actually extremely important that they stick to and abide by those roles. you know, because it's high-stakes stuff.
however, before and after the flights or surgeries (akin to design or planning in software), or perhaps during sticky situations or emergencies (akin to debugging in software), or during post-flight or surgery reviews (akin to code reviews) they do work together on the same thing. during the sticky situation, emergency, or debugging stage, that thing is the emergency at hand. once it's dealt with, the separate, individual roles are assumed.
so thanks for your examples, as they just serve to further my point.
Do you think pair programmers are literally bashing the keyboard simultaneously?
Your point, as I read it, wasn't that "only programmers do pair programming". That's as trite as "only surgeons do pair surgery" or "only aviators do pair aviation", because it includes the profession. It's that only programmers doing any kind of assigning two minds to cooperatively navigate one problem space, which is demonstrably false.
that's how the article and other articles define it: two people sitting at the same machine writing code. what is your definition?
my point was indeed: what other industry practices "pair <work or implementation>" on the same task?
and why would it be the second? we're literally talking about pair programming here, not just cooperative work.
plus this: pair programming has only been studied / proven to work in a teaching environment, where one student is literally teaching the other and bringing them up to speed.
i don't know of any study that proves that it works in a professional setting with experienced people having more or less the same background, working on the same task
if there is any study, i would like to read it.
For real quality, you need detailed specifications before code is written, an independent verification team, and root cause analysis on every bug. Otherwise, you're still down at CMM level 1 or 2 ("chaos, and slightly better than chaos").
Pair programming is putting a second pair of eyes on chaos to try to emulate an actual process. It's the Hyper-Threading of development processes. We're too cheap to implement what we all know we really need, so here's something that's better than nothing, for a small fraction of the cost, because it repurposes what we have on hand.
Some thoughts based on my own personal experience:
* The biggest win for me is I am much more focused and productive throughout the day. Having an actual person to be accountable to on a continual basis keeps me from meandering down unimportant rabbit holes, unnecessary/premature refactoring or re-organizing, and general procrastinating (reddit, HN, etc)
* Development is definitely at a slower pace on a daily basis than what I'm used to working on my own, but over time I think it evens out in terms of quality of code and maintainability.
* Knowledge sharing is huge -- when I was solo, I could never truly take a vacation because I was the only one responsible for my piece of work. Now I'm on a team where we all pair with each other and switch around every day... if someone is out, it's no big deal. Also makes it much easier to onboard new people (the company I work at is a consultancy so projects are always ending and new ones beginning).
* Despite being an introvert, I feel no more "drained" of energy at the end of the day than I ever did at any other job. One-on-one interactions with people I know and build trust with just doesn't affect me the way other social interactions do.
* Pairing is not a panacea. Some of the comments I've seen here are about how horrible it would be to pair and feel judged all the time or one personality overriding the other... I suppose that's possible but it doesn't happen at my job because my company values and encourages trust. My team is comprised of mature people who all value team cohesion and working together towards a goal over having to be right all the time or proving to someone that we're better or whatever.
* I am never "stuck" pairing with just 1 person for a long time... we switch around every day. I probably pair with any given person only once per week (on a team with 6 developers). But each team has autonomy to structure the pair switching however they want.
Those are just some thoughts off the top of my head. Happy to answer any questions anyone may have (and if it sounds interesting to you, my company is always hiring... we have physical offices around the world, as well as a "virtual office" for remote employees).
Pair programming is a very intense experience and had it stopped a few weeks in that situation then maybe my thoughts on it would be different.
There is no better way to educate a newer team member to code standards and procedures as well as business domain. It also helps to reign in over-engineering and bad approaches. For more senior developers, it can expose them to newer approaches and technologies that they might not be aware of.
I had a great experience pairing on a complex feature request (convert desktop version of an app to a mobile version) that was planned for 3 months. We finished it in a month with full test coverage and every little change to PM, PO, and UX designer could throw at us. Because we both had knowledge of the systems, we could later work independently on simpler tasks and regroup later to combine our efforts.
Typically I find Pair Programming pretty pointless for most tasks. Where it works is when one developer knows the code base and another knows about the new piece they are trying to implement e.g. something external they are interfacing with.
Much like other subjects on Martin Fowlers blog, it will get picked up by some which will religiously adhere to it and not consider where it will be best suited.
The part about "informal hierarchies" threw me off, and comes off a bit sexist and racist to me. I read this as "hierarchies that are generally recognized/accepted by the public". I don't believe Fowler intended it to read this way. I think it's okay however to recognize people may have interpersonal issues, for a wide range of reasons.
It is an approach that probably works quite well in some contexts and some teams. In other team, different approaches work.
In the end what matters is that the team is highly motivated, has a strong sense of ownership and takes appropriate measures to reduce defects. How it achieves that doesn't really matter from a business POV and is more a subjective preference. In my team, we mostly achieve this through extremely thorough code reviews that dig into a lot of details and that works well for us.
edit: another thing that we do is careful discussion and planning of features (where we will sit together in a small group and discuss approaches) and, for more complex things, architecture decision records (similar to RFCs) that get reviewed before they are implemented.
I've done pair programming enough now in my career to be able to say that it stifles me, interrupts my flow, kills my creativity, decreases my productivity, and leaves me exhausted at the end of the day. I don't necessarily think it's a bad idea for certain people, but I resent it when it becomes a blanket policy. In fact, I've left jobs that started requiring pair programming.
There's a reason why it's only received tepid acceptance in industry.
If it works for you, great. But don't force it on me.
For the majority of time, it's just not necessary. If the domain is well understood, the code base is familiar and the requirements are well defined, most units of work (stories, PRs, whatever) shouldn't need two people.
All of your mental maps need to be communicated repeatedly to the other person - and it's slow. It's like the difference between L1 cache lookup and sending an email and waiting for a response.
This would allow one to double check ones actions in order to notice and correct mistakes one made the first time?
To maintain accessibility by remote teams and individuals, most teams will assign an "interrupt pair", who are designated to deal with Slack, walk-by questions and the like.
I have mixed feelings about Slack. It's too addictive. I've enjoyed jousting and joking and forth, but I don't always come out the other side with concrete outcomes.
[1] https://docs.microsoft.com/en-us/visualstudio/liveshare/use/...
Maybe I'm just not good at writing code correctly the first time, but when I program I usually fix at least one error per compile/run. So I have trouble pair programming when eg the other person likes to write larger chunks of code before running/testing.