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!
> 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.
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.
> My experience is that pairing is deeply disruptive to my exploration of a design.
I think it's one of those things where some people are good at it / enjoy it. Some people don't.
As a paradigm, I think pairing is better. Two talented, smart people who are able to work together will produce a better solution than one person alone. As you rotate pairs, context on the code base is shared and permeates the team faster. New onboards get up to speed at a remarkable pace--far better than the "uhhh so checkout the code. Mess around, see if you can get things running. Idk good luck" process I usually see on non-pairing teams.
I've seen a lot of code over the years developed in silos by talented people. The work gets done. But the teams I've been on that embrace pairing produce better code, the team has better shared context, and there's a real joy to the work. This becomes disrupted when someone who does not like pairing joins the team, and actively resists the process, hoarding context and cowboy-ing solutions off on their own.
If I ever run a company, I will select for engineers who aren't just comfortable with pairing, but actively enjoy it.
I think companies can perfectly well operate with lone wolf engineers. But you have to add a lot of process to wrap that mentality--code reviews, design sessions, context share-outs, multiple people singing off on PRs. These are things you can largely do away with if you're doing pairing correctly.
From my experience, it's just better. But hey, I'm biased. I'm one of those people that enjoy it.
> Two talented, smart people who are able to work together will produce a better solution than one person alone.
The issue I have with this statement is that working together does not require pairing. I agree with your statement, but not as support for pair programming.
> As you rotate pairs, context on the code base is shared and permeates the team faster. New onboards get up to speed at a remarkable pace--far better than the "uhhh so checkout the code. Mess around, see if you can get things running. Idk good luck" process I usually see on non-pairing teams.
None of this requires pairing to address. I do address this by sitting down with people and walking through code, to give an overview or when people have a concrete problem. A big problem I see with pairing in this context is that it promotes not learning how to learn from code. I see this often when I'm brought in to troubleshoot code with developers who look like deer in headlights when they are dealing with something out of the ordinary, because they've learned the hot spots of the code rather than actually reading through and understanding the conceptual basis of the system and the design behind it.
> If I ever run a company, I will select for engineers who aren't just comfortable with pairing, but actively enjoy it.
Having run companies, and hired many dozens of engineers, if you do so you'll end actively discriminating against many types of neuro-divergent people. Apart from the issue of whether or not you can actually show any benefits, you'll be one little conflict away from a lawsuit.
> I think companies can perfectly well operate with lone wolf engineers.
This is a false dichotomy. Nobody here has argued for "lone wolf engineers" as far as I can see.
> But you have to add a lot of process to wrap that mentality--code reviews, design sessions, context share-outs, multiple people singing off on PRs. These are things you can largely do away with if you're doing pairing correctly.
If you do away with those things just because you're pairing, you're setting yourself up for massive risks and failures.
I find this hard to believe. Which country’s laws are you thinking of? In the US, at least, companies such as Pivotal and Menlo Innovations, as well as others I’m not at liberty to name, require full-time pairing. They’ve never had an issue. Your statement is also at odds with my understanding of employment law, which is admittedly at a layman’s level, but I have studied it for the purpose of hiring in Oregon.
> setting yourself up for massive risks and failures
You’re losing credibility with me. I’ve done exactly what GP is talking about and it was better than code reviews (etc), not worse. Are you talking from experience, or from personal preference?
> I find this hard to believe. Which country’s laws are you thinking of? In the US, at least, companies such as Pivotal and Menlo Innovations, as well as others I’m not at liberty to name, require full-time pairing. They’ve never had an issue. Your statement is also at odds with my understanding of employment law, which is admittedly at a layman’s level, but I have studied it for the purpose of hiring in Oregon.
I'm in Europe, but I've seen such law suits and threats of lawsuits over issues like this affect companies I've done projects for first hand, including at least one US company. They are very hard to make stick, because most people are not dumb enough to make statements that are clear cut enough to provide proof that the employees failure to get hired is discrimination. But that does not stop people from suing (or threatening to sue). I've seen team paralysed for months [dealing with legal issues surrounding conflicts over discriminatory hiring practices] instead of doing their jobs. I've also personally seen people walk away from threatening lawsuits over issues like this with well over a years worth of compensation just from a threat.
This is separate from the moral issue - personally I've interviewed enough neuro-divergent candidates who were qualified (and hired a few) but who'd struggle with things like pairing and I'm personally not willing to refuse to make reasonable accommodations.
> You’re losing credibility with me. I’ve done exactly what GP is talking about and it was better than code reviews (etc), not worse. Are you talking from experience, or from personal preference?
I'm talking from experience over nearly 3 decades, including direct personal experience in cleaning up the failures of teams who took short cuts because they thought pairing could replace code reviews. They catch different things. Pairing for some teams where people are comfortable with it leads to lower counts of some types of defects assuming a lot of things go right (e.g. the pairs are matched well with people who'll actually speak up and challenge each other), but pairs tends to look themselves blind to many of the same categories of failures as individual developers because they focus on solving a task and steer their view of the code accordingly rather than looking for at breaking it.
It's the same reason developer written test suites does not obviate the need for QA, and internal security reviews does not obviate the need for external pen testers, or having developers try to think about operational issues does not remove the need for SRE's or equivalent.
> Having run companies, and hired many dozens of engineers, if you do so you'll end actively discriminating against many types of neuro-divergent people. Apart from the issue of whether or not you can actually show any benefits, you'll be one little conflict away from a lawsuit.
"We pair program here--that means actively working with another engineer for 8 hours a day. Is this something you're comfortable with?"
"No. But knowing this, I am going to still pursue this job. I will then sue you when I'm unhappy with the requirements you've clearly outlined to me."
A whole lot of unwillingness to make reasonable accommodations for people based on disabilities will open you up to lawsuits.
To imply reasonable accommodations for neuro-divergent people is simply a matter of "comfort" is indeed worth a "what a world" on the same level as refusing to make reasonable accommodations for those who are blind or hard of hearing or in a wheelchair.
> A whole lot of unwillingness to make reasonable accommodations for people based on disabilities will open you up to lawsuits.
I kind of take issue with your assumption that someone with (edit: meant Neurodivergent... NPD is something else) can't pair program.
If your assumption of an effective pair programmer is that they're always bubbly extroverts with politician-level shmoozing capability, I kind of doubt you've spent any length of time doing it.
There's a lot of people who struggle with more "normal" communication that are incredible pair programmers. I've worked with many of them. In many cases, the code and the keyboard becomes a communication medium they're effective at leveraging--more than other means. Actually doing pair programming challenged a lot of my misconceptions about what it takes to be good at it.
It's skill and like any other should be disconnected from stereotypes. I don't see why you can't hire for it like any other. Hopefully I don't run into you in the court room. ;-)
> I kind of take issue with your assumption that someone with NPD can't pair program.
Many can. Many can't. I did not make the assumption you're arguing against here.
> If your assumption of an effective pair programmer is that they're always bubbly extroverts with politician-level shmoozing capability, I kind of doubt you've spent any length of time doing it.
That was not my assumption at all. You're jumping to unwarranted conclusions not at all supported by what I wrote.
> There's a lot of people who struggle with more "normal" communication that are incredible pair programmers.
That's fine, but it does not change the fact that many people struggle with it. Including people who manage to deal with "normal" communication just fine, but who find the intensity of a pairing unbearable. I can do it, but to me it is intensely uncomfortable to the point that as I've pointed out elsewhere I refuse to be pushed into it - for me it's not a problem, as my career has afforded me the luxury of picking and choosing positions where I get to decide what goes -, but I've met many brilliant developers over the years who just could not deal with situations like that at all.
> It's skill and like any other should be disconnected from stereotypes.
This dismissal of what to quite a few people is an inherent part of their neurological makeup as a "skill" comes across to me as incredibly offensive.
> That's fine, but it does not change the fact that many people struggle with it. Including people who manage to deal with "normal" communication just fine, but who find the intensity of a pairing unbearable. I can do it, but to me it is intensely uncomfortable to the point that as I've pointed out elsewhere I refuse to be pushed into it - for me it's not a problem, as my career has afforded me the luxury of picking and choosing positions where I get to decide what goes -, but I've met many brilliant developers over the years who just could not deal with situations like that at all.
I'm not disagreeing that some people don't find it enjoyable, and some people aren't good at it. Like anything else.
I don't see why you just wouldn't work at another company instead of demanding the company change its methodologies for you. I'd say the average dev shop leans more "lone wolf" anyway. Teams and especially companies that pair are the exception, not the norm. You're an experienced guy it seems like--I'm sure you've changed jobs many times in the past to find a culture and working conditions that suited you better.
> This dismissal of what to quite a few people is an inherent part of their neurological makeup as a "skill" comes across to me as incredibly offensive.
I'm sorry my view on this offensive to you. I don't mean to offend you, but simply stating you're offended doesn't change my perspective--I still view pair programming as a skill, and I don't think it's wrong to hire for skills.
> I'm not disagreeing that some people don't find it enjoyable, and some people aren't good at it. Like anything else.
I'm not saying that some people don't find it enjoyable. I'm saying that some people can't do it without risking their health.
> I don't see why you just wouldn't work at another company instead of demanding the company change its methodologies for you.
Most people do, or end up unemployed. This is a widespread problem with the lack of protection of employment opportunities for differently abled, and a reason why I find it immoral to refuse to make reasonable accommodations based on it, the same way I'd rather walk from a job than e.g. refuse to hire someone just because they're blind or deaf. That a whole lot of companies do just fine without pair programming, to me is clear evidence that it's a reasonable accommodation.
> I'd say the average dev shop leans more "lone wolf" anyway.
Either we have very different ideas about what "lone wolf" implies, or I deeply disagree with this. But in terms of not mandating pair programming, sure. I don't see that as an indicator of people being "lone wolf" type programmers, however.
But the existence of less discriminatory environments is not a justification for accepting discrimination.
Note that I have no issue with companies choosing to prefer pair programming. It's their business, though I'd probably still not want to work there (and that's my business). What I do have an issue with are those who outright demand it of everyone and are unwilling to make adjustments.
Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work, meant to encourage brilliance from random water cooler interactions.
In a perfect world, is a fully engaged in-office employee better than a remote one? I’d say probably yes. In the real world, is a disgruntled, commute tired employee better than a happy remote one? Unknown.
Same with paring. If your team is full of perfectly interchangeable humans drinking the same cool aid, then pairing sounds great. But real humans don’t work like that, and for every person who is boosted by pairing there may be another who is held back by it.
In the end, it’s likely best to allow employees to self select the mode of work which works best for them (location, pairing amount, computer choice) so that they are happy and productive. Any kind of top down mandatory policy on those choices will inevitably be worse than each person’s preferred choice.
> Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work
I don’t really disagree with this categorization. And there’s a lot of companies that view it as core to their success and culture to have an in person work force.
I may disagree, and I may work elsewhere that suits me better!
That’s sort of why this digression on denying a company the ability to set their own development practices is strange to me. There’s a plethora of options for the work force. Go where you’re in alignment, don’t force bad alignment on the company!
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.
> 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 absolutely see value in explaining a design, and doing so with code, before you commit to the full project, but for me that step follows getting my initial design ideas down as code. I've had any number of projects where I've explained the high level design in words first, and people don't understand why it matters, and then I've put it down in code and shown the concrete benefits, and it instantly clicks. That doesn't mean that design will be set in stone and perfect, but I find it much easier to have the discussions about the design then.
But that's me. If you prefer writing the initial code as well with someone, you should by all means keep doing that.
> 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.
I think you're right, with a caveat that it's not for me necessarily about not enjoying social aspects of it, but about the granularity of it. I'm happy to walk people through my code, but I want peace and quiet to put in place at least the outline of the design in solitude first.
> 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.
That is absolutely reasonable. I have no issue with people pairing. I do have an issue with teams where becomes an expectation for everyone.
The crux of it is that pairing works for some but not for others. But often, it’s forced on everyone, usually from the top down. This is done in the name of vague benefits like “correctness” and “knowledge sharing”. Have these benifits even been confirmed through unbiased scientific studies?
The problem is that in the tech biz people tend to follow blindly without thinking. There was a point there where just because Pivotal Labs had some success pairing full time, everyone followed blindly. It’s the same with leetcode style interviews,
open offices and ping pong tables - it worked for google and all of the sudden everyone is following blindly.
But personally, I wouldn’t work somewhere which paired heavily even if the benefits could be proved. I simply won’t do it because I don’t enjoy it!
Just like the choice to work remotely, the choice to not pair seems like a basic employee freedom that we should all have. Luckily, the way our industry is moving, such freedoms seem to be increasing.
> Have these benifits even been confirmed through unbiased scientific studies?
Good question. The problem there is that setting up a study of this is rife with problems. E.g. ensuring you're comparing "like for like" developers is hard enough. I have no problems believing that companies like Pivotal that are known to do it get good results from it, for example, because by announcing it they're self-selecting for developers who at least believe they do better in pairs. That may well even be a decent strategy to prevent dead-weights from applying, and so I could also very well see them doing better than a company with poor screening and performance management.
> The problem is that in the tech biz people tend to follow blindly without thinking. There was a point there where just because Pivotal Labs had some success pairing full time, everyone followed blindly. It’s the same with leetcode style interviews, open offices and ping pong tables - it worked for google and all of the sudden everyone is following blindly.
Cargo-culting in other words...
> But personally, I wouldn’t work somewhere which paired heavily even if the benefits could be proved. I simply won’t do it because I don’t enjoy it!
Same here. I'm fine with others doing it, including on teams I run, but other than sessions to teach or communicate a design I'm unwilling to be forced into it.
Pairing doesn't work for me for either. It works fine in short bursts for knowledge sharing, but an understanding of a code base can be conveyed in small fractions of a time it takes to write it.
Pairing was highly encouraged in my previous job. We did it for 5 or so years, even when working remotely using tmux. In my last 2 years there, in an attempt to increase throughput / save time, pairing became something you only do for crucial task.
I could argue that the code quality declined as well as the distribution of knowledge while not seeing significant increase in throughput of work done.
Even more, and due to knowledge sharing, code review time increased.
I recently asked a friend who's a team lead at a FAANG company if and how they do pair programming. His answer was that it is not encouraged, mostly because "performance reviews assess contribution of individuals, and pairing would disrupt this process".
> it's that having multiple perspectives on the code will lead to a higher quality and more well designed product.
Will it though, when those multiple perspectives are enforced through pair programming?
Like a lot of agile cargo-culting, pair programming often seems like software development for extroverts. Those of us who are introverts, and got into software development because it's interesting work which suits our temperaments, don't necessarily appreciate this... at all. I'm not saying I'm unwilling to work with others, or figure out problems together - I have to do this all the time, we all do - but I prefer to program alone.
I think a developer has to earn that privilege. Often times developers use the "just let me do my own thing by myself" line to push code they know is crap, just because they don't get the same level of scrutiny and accountability through an asynchronous code review. Asynchronously, the code reviewer isn't easily able to see the author's thought processes as they constructed their code, so they don't really know whether the author's way of solving the problem is reasonable given the context without putting in significantly more effort into reading the entire context in which the change was written.
After having dealt with mountains and mountains of technical debt in my career, I'm firmly of the opinion that every developer should go through a period of pair programming with a more senior developer. Maybe they can do it for their first quarter with the company. At that point, if the senior developer signs off, they can acquire the right to code independently if they so desire.
"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."
That's what PRs are for. One can't use the same argument to oppose PRs, as you suggest, because of this key difference: in a PR, the person doing the review has (or ought to have) context on the broader picture (e.g. overall architecture, structure of the code in which the change is being made, etc.), but not the specific changes. It's analogous to having a proof reader: one doesn't invite a peer author to review his writings, because the peer has an implicit bias and can easily miss defects.
"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."
This is common, unfortunately, and one of the primary reasons software is so buggy and overly complex. The code isn't the design, or shouldn't be. To draw an analogy to physical/industrial processes, the code is the machinery on the factory floor doing the work--the design is what was used as a blueprint to construct that machinery.
As the design evolves, this stuff should really be communicated to the rest of the team before the PR. The purpose of PRs should be almost entirely about finding bugs and typos.
It should be, but another thing in this industry is the completely subjective design ideas everyone brings. So PRs inevitably have comments about the approach to abstractions, testing, etc. that are really little more than ego-stroking.
If you mean what I think you mean, those are one of the few exceptions. I assume you mean just implementing the feature/bugfix quickly because it helps with the design discussion. Even in that case, I think it's a good idea to have a final non-draft PR (or just have people look at it again with fresh eyes once out of the draft stage) where the main goal is just to verify correctness.
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.
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.
> 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.
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.
> 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).
> 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.
Yeah, I've taken "thinking breaks" during pair sessions for this reason.
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.
Indeed, and this is a problem that can affect other “Agile” practices too. Mandatory/permanent pairing is one example. TDD is another. Both can reflect a more general trend to try to break development down into tiny steps.
It’s not that there is no value in developers working together in real time, or in unit tests, or in incremental development and short feedback loops. All of these can be very useful. In my experience, they are often adopted spontaneously by developers even if there is no formal process in place that requires them.
But it’s also important to look at the big picture. You need a coherent vision for the product. You need a consistent domain model that is well understood and shared by both developers and non-developers. You need a reasonable software architecture that provides useful patterns and abstractions but also isn’t afraid to change them as requirements evolve.
Without these things, it’s easy to take a lot of small steps and create an illusion of progress, yet not move efficiently towards your true goal. Increasingly serious problems tend to get shoved under the carpet (sorry, “added to the backlog” or “labelled as tech debt”) until inevitably quality and productivity start to suffer.
You can’t fix those kinds of problems working in the small with only one or two participants.
> 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.
I know it's anecdotal but this doesn't happen in my team. Our pairing culture isn't oriented at producing more but higher quality code, and it generally tends to achieve both.
Or, to turn it around, rushing tasks doesn't seem to be an issue of solo vs pair or mob programming.
> 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.
I feel like pairing pushes people towards this because both parties feel the need to show they aren't "wasting time" by engines reasonable definition of it.
If you swim upstream and try to work against this, it can cause some friction.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
> 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!
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?
> Pair programming is a skill which must be learned.
> You will not be good at it at first, but consistent practice will yield improvements.
> Don’t give up after a difficult first experience. Don’t assume experienced developers are automatically good pairing partners. Don’t expect to be good without practice.
> Consider reflecting with your pair or asking for feedback after each session. What could have been better?
In my experience (pairing on and off for about 12 years) - this is the biggest thing people misunderstand about pairing. You're not going to be good at it right away, and the team isn't going to benefit right away. It's an investment that pays off in months not days.
That being said - I find that requiring my team to be good at pairing, but not that they pair all day every day, is sufficient. It means that they pair when it's appropriate (onboarding, larger design problems, early stages of a project, etc) and they don't when it's less appropriate (fleshing out an implementation, exploring a new idea, mundane updates).
We find that if we pair all the time, especially on things that don't benefit from pairing, it exhausts us. Pairing is a useful tool, but it can be equally dangerous if overused and cause people to resent it.
Also on the "forgetting it's a skill" track: pair programming isn't just one thing. There aren't just two roles, the one at the keyboard and the one not - there's a bunch of different roles you can take on, depending on who you're pairing with and how they (and you) work.
For example, with one co-worker at the keyboard, I would fully take on a support role: He was a slow typist, so I'd keep an eye out for typos and quietly nudge him instead of having to wait for a compile/run loop, I'd look up documentation so he wouldn't have to keep context switching, and so on. Before that point though we had roughly equal roles at the design stage (he was a very strong proponent of "keep it simple" and made me realize I was drifting into an "architecture astronaut" mindset, so I think we worked really well together overall).
In another, with some co-workers unfamiliar with a codebase but wanting to learn more, I'd take the high-level guidance role where I'd be mentally working a few steps ahead on the overall design/goal while they worked on the nitty-gritty details. They'd be learning how the pieces fit together without having to worry yet about side-effects or other problems because I'd be acting as guardrails, keeping them on the right track and identifying those problems ahead of time so we can deal unavoidable ones right away. Ideally this role doesn't last long with anyone as they'll need to learn those parts on their own, but it works sometimes.
As a step up from that second one is on/off pairing, where they'd be testing their knowledge on their own to come up with a solution, then we'd pair for a while to make sure they're on the right path and maybe get past a spot where they were stuck on how to do something.
+ it doesn't dominate the entire screen, allowing each person to keep their own notes/etc on the side
+ at any point someone can "jump in" and take control of the session
+ interacting in a confined shared space radically reduces "over communication" issues. i.e. if you want to show something it's got to be demonstrable in a small textual window
+ you have a shared command-line, which is more useful than it might initially seem
+ seamlessly scales to in-person and remote pair programming
There are some downsides:
- it requires both users are familiar with a terminal based editor
- it may present security issues for folks operating in locked-down/low-resource environments (e.g. can't spin up a temporary machine with a shared account)
- sharing graphical information requires a separate communication layer
Even considering how easy things are using tmate, it is really challenging because there are a lot of Software Engineers that don't really know how to use a terminal to the point that asking to do a SSH is a bit too much.
So we end sharing the screen over hang outs, that is basically very inefficient and wastes a lot of CPU. But because it is normalized, it is "the standard".
EDIT: my comment was a bit unfair. I guess I could install VS Code, change my daily editor, and use it with the Live Share plugin with those using VS Code. So hang outs it is.
Take that one step better and each should have their own resolution. Just cause your 20 yr old eyes looking at a 4k super widescreen monitor can read it doesn't mean my 30 yr old eyes with glasses on a laptop can read it too (I really like code with me on Pycharm)
I work at a place where we do exclusively pair programming (a software consultancy). A project always has at least one pair.
Each workstation has a computer, 2 monitors, 2 mice and keyboards. When someone can't be at the office then we sometimes use Tuple, and it's a great tool, unfortunately still only works on Macs.
Pairing works for us because it's more efficient than working alone, less bugs and better thought out design, faster spread of knowledge about our tools and the project in general. I joined a year ago and hadn't used Java or IDEA, pairing helped me learn all of it very fast, compared to if I had to work alone and struggle with learning all of the new things.
Pivotal doesn't exist anymore.
It has been acquired by Vmware and now it calls Tanzu Labs: https://tanzu.vmware.com/labs
Btw there are many other companies where you can pair: Thoughtworks and Codurance for example
I'm curious where the pair programming religion came from. There was certainly a time when it didn't exist as a concept. I for sure don't remember anyone suggesting that it would be cool if two folks sat around the ASR-33 and took turns to hunt-n-peck on the keyboard. Perhaps it originated in the brogrammer movement?
Anyway, the sibling article says:
"A pair of programmers tends to produce better code than someone working alone."
Let's assume this is true (I'm reasonably sure it's false). If one programmer can type code that's at quality N, then add a second one to look at what they're typing and perhaps you can say that quality will be >N since the second person might spot errors made by the first. But we just used TWICE as many people to write that "better" code. I expect there are industries where this burning of resources makes sense, but most of the time it won't regardless of the improved code quality achieved. We could write 2x the amount of crappy code and most organizations would opt to do that.
If we're pairing up at the terminal to teach/train/transfer knowledge, that makes much sense and has been done since the ASR-33. Also sometimes it helps to have two or more people stare at a debugging session together to crack a gnarly problem. Designing at the whiteboard has been a thing since Von Neumann and Turing (chalk board...)
Programming however, isn't a thing you do in pairs, imho. It's creepy and weird.
I used to do a fair amount over LiveShare and we would adapt depending on the relationship we had. It got more interesting the more level we were.
One of the more successful patterns that came out was to: talk about the goal, write out the code that acted as interfaces between the two of us, and then split up and tackle two things at once. That might have been code vs tests, backend vs frontend, migration vs adapting existing code. We would often then swap and discuss what we'd done (and we might be asking little questions as we go to help refine each other's approach), add improvements or plug gaps and then finally give it a good end-to-end run through with some exploration.
We were working together on the problem, asynchronously, and you'd be surprised how little there were occasions where a big assumption at the beginning was missed and made us go off in different directions. This was nearly always caught early as we talked whilst we worked on our separate areas and had a quick glance at what the other person was writing. I'm convinced that we caught them faster than if I was alone as we had the opportunity to think about the problem from multiple perspectives at once.
We use live share a lot for pair programming. It works okayish, but the built-in terminal is borderline useless for guests due to its very poor handling of different view port sizes.
I recommend to instead let your pair in through SSH (a reverse proxy, like ngrok, is useful), and then sharing a tmux session.
It’s not always the best fit for a particular task, but I’ve personally had some experiences where pair-programming was a huge productivity boon, as it prevented potentially difficult to diagnose bugs from being committed in the first place. I personally feel it shines when you are working on something very complex and particularly detail-sensitive, where a small mistake could cause a devious bug, and so the benefits of having a second set of eyes on everything in real time are large.
I’m curious to hear what you dislike about pair-programming.
I think it really is complete agony for some people, and when I've seen it in practise, certain people really benefit and others just don't.
Speaking for myself, when I'm working on something complex and detail-sensitive, the very last thing I want to do is spend any time at all with anyone else. I want to be able to think properly about the problem without the pressure of having someone else involved.
I’ve always wanted to try this out in practice. It seems like it would be a great way to find gaps in the specification.
There was some research in the early 90’s over multiple implementations as a way to avoid bugs. I still feel like it was dismissed prematurely or could be revisited.
I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More and more I wish that code had been written via pair programming, where the other (hopefully more senior and judicious) developer could have, perhaps by only their mere presence, prevented the hack dev from doing what they did.
That's what code reviews are for. You don't need pair programing for that. Places like google go even beyond by having a 'readibility' pass score for the code to be able to ship.
Pair programing is something from the early 2000s, where code review tools were non-existent (I remember, people would just email diffs to each other), back in the day.
In my experience, code review often becomes a rubber stamping exercise. Reviewers only add trivial feedback and stop short of adding actual constructive criticism or feedback, either because they don't want to look like an arsehole, or because they don't have time.
That said, it's not an intrinsic problem with code review, but a team culture problem.
> Code reviews prevent this as well, without all the overhead incurred by pair programming.
I'm a big believer in correcting errant behavior in the moment. Simply the presence of an overseer can coerce a developer to avoid taking shortcuts with the hope that it might go overlooked in an asynchronous code review.
I am on a team of two, and yet, I rarely have time to audit code that my fellow has written, simply because the rest of the day demands other tasks to be focused upon
I'd be interested in such a write up for remote pair programming. Being remote the likelihood is much higher that the navigator loses focus and answers emails or slack instead.
Switching roles more quickly might be the solution. We've tried tools like mob.sh, but the most efficient way seems to be using something like VSCodes liveshare. Unfortunately half of my team uses Intellij and the other half VSCode.
I don't see pair programming as a disruption to the individual mind of the single programmer.
Then I believe something is wrong in culture of the organisation. It should definitely not be enforced but encouraged.
The reasons I believe that is because the human psychology is also based around success and praise from our relations.
The benefits you get from sharing thoughts and possible options to a challenge can hardly, imo, be bad.
Pair programming has taken place in my career, in cultures that encourages a pace to get work done, in a manner where quality is measured by how well a team works together and how well the team is capable of understanding eachother - but as a team.
I also believe that if you cannot explain in words, how you would go about solving a challenge, then it's premature to start coding on it. Then you are moving to fast.
Pair programming is like any other thing. It should be applied when necessary and not be enforced on 80% of the work because it's perhaps only valid for the hard 20%.
I have really thought about making a pair programming service for years, where people can connect and program as a pair, for the hard parts.
I'm not sure about pair programming. I never really understood why we stop at two people. Why not have 3 or 5 people working together? And indeed that's what we do when for example doing system design and it's incredibly useful.
Writing mundane code in pairs sounds like a brute force solution that should be solved by training, higher quality code scanners or other code quality tools.
Having larger groups collaborate like that is called "mob programming". I'm not sure how popular it actually is but I see it talked about on HN and Reddit all the time.
I've done plenty of pair programming informally when one of us were stuck on some hairy bit of code and needed another pair of eyes and some extra brain power to get to a solution but I've never done it in an ongoing formal context. What I've always wondered is if you get the doubling of productivity required to justify having two resources working on the same bit of code? Certainly in blocking situations you can get a huge multiplier on productivity (I'm including quality and correctness in my definition of productivity) but lots of code is mundane stuff that just needs someone to push through and knock it out. Can a pair get the mundane stuff done in half the time of a solo developer?
The benefit of a pair in this situation is figuring out the design flaws that make programming repetitive/mundane. If you’re doing a lot of repetitive work, there may be an abstraction you’re missing.
How about just not having a navigator and driver. Having gone through a "wing-it" approach to pairing extensively, it really is an awful experience for those who hate having to fight for control.
Great resource I agree. The guide is concise and could seem obvious to many peeps, but it made me reflect about my own pair programming sessions and notice I likely failed at a bunch of those points.
The same. I've been pairing for probably close to a decade now, and this guide helped me to reflect on my own style, and gave me a few points to refine as well.
As an aside, one of the things I make sure to do with new hires is to cover "beginner's mind". Just because you've got ten years on the iron doesn't mean you can't learn something new, and that something new might just be from the grass-green new guy that joined last week.
Likewise, for the new guys that think they're hot shit because they've got a degree from McSmartypants University doesn't mean you actually know anything. Don't just take things on an "I said so" basis, but also don't discount the value of experience.
When you run into a new idea: use active listening to ensure you understand it, and explore its ramifications. Poke and see where it falls down, and where it doesn't. You'll avoid a lot of bullshit this way.
As someone who has programmed for a very long time but only done pair-programming a lot last few years, the big things in my opinion is:
- If you're the driver (handles the typing), don't allow yourself to be stressed and just type things someone else tells you to type.
- Language is really bad at comunicating where to make a change on a gigantic screen of text, expect yourself and others to become a bit frustrated at times, but it's at the difficulty of communicating things, not that the other person is dumb. "And change the type to bool. No not that one. Go to the end of the line, then back to the last bracket. No, the line you were at. Yes. Now go to the last bracket. Change to bool." And then take a second to understand why, asking if necessary, becuase it might get more difficult to understand later.
- It's extremely difficult not to get lost when someone else is navigating between tabs, especially if you don't know the code well (and sometimes even if you do).
KTANE even has (to a greater extent, and for humour) the ambiguities that can trouble talking to somebody about programming, like offering "YES", "AND", "&" and "NO" as options somebody needs to pick quickly.
Only pair with people who are genuinely interested in learning new stuff, want to do better and who are able to listen to other viewpoints and exchange ideas. Pairing with people who don’t care to learn or are super opinionated is a nightmare. Ideally you would have hired only people of the former kind but in the real world that is often not the case.
I would quit if I was forced to pair program. Pair programming is loved by incompetent software developers because they can hide in the shadow of more competent developers. That's my experience anyway. YMMV of course.
Can someone point me to a great work of software that was written by two people simualtaneously collaborating like Lennon and McCarthy writing songs? I never see any evidence given that pair programming is a better way to code.
The article paints them like a married couple doing a mind meld. That's impossible to duplicate by making programmers work as a pair. I'd expect the opposite to happen much more often; two programmers forced to share the same monitor and keyboard would start to dislike each other intensely.
Based on my connecting multiple boards, I think it’s plug and play. The hard part is if you want to distinguish between what board a keystroke came from.
Technically it works directly, but with e.g. multi-pointer X you can bind HIDs to a pointer (aka cursor), and control them independently and concurrently as long as you don't confuse the applications you're interacting with. I think Emacs is tolerant in that respect, but beyond that, some trickery is likely required to make this work (i.e., multiple browser instances).
“Allowing unproductive distractions” is one of the major reason why I think home office is fundamentally less productive, no matter how much people have come to like it. Pair programming through screen sharing works fine on a technical level, but you can’t turn off children.
'“Allowing unproductive distractions” is one of the major reason why I think going in to the office is fundamentally less productive, no matter how much people have come to like it. Pair programming on-site works fine on a technical level, but you can’t turn off co-workers or your managers.'
You can't turn off disruptive co-workers either. When I used to go in to an office of sorts one day a week, I eventually wrote that day off and just accepted that day was for socialising and design meetings. Throughput consistently tanked on those days, so better to accept it and use it for activities that didn't require the same mental focus.
If you don't have someone else watching your children while you work, you're probably not going to have a good time working remote regardless of coding style. Most of us working from home have addressed childcare and aren't just leaving food and water bowls out while they run around doing as they please...
I haven't physically paired in years. Even before the pandemic I'd often be screen sharing with someone across the table from me. We'd just be positioned where we could see each others' faces and our own screens.
These days it's all fully remote. And that's worked out incredibly well since my team has gotten more and more geographically dispersed. The few that were before are now always in the loop.
I haven't done it full time in a while because my responsibilities other than implementation take too much time.
I'm old in my team and when I can, it works well for me. I share my experience, keep software focused, etc. The younger, high performers teach me new tools and tech. The fresh folks learn more how to think and do work from us. Stuff like that it's not just about making something work, but making something maintainable. I probably teach as much backspacing through a "clever" idea I had, than by writing anything. That and how to break a problem into chunks. Then reevaluate that and make it clean.
Pairing is also great for the more ops side of things. I think in a lot of ways you get even more bang out of it there than programming. Have 1 person do the work and a newer person improve the docs as they go. Then flip for the next iteration, with the new person driving and the experienced one helping and tweaking docs. Call out places where automation could replace procedure and get them in the backlog to be prioritized later. The same pair can pick up those stories when they come back around.
I have experienced some of the pains of this list. I worked with a guy who I joked "painted" code. Lines just growing and shrinking like a horizontal EQ. It was dizzying and unpleasant. I often just checked out and pointed out missing braces every once in a while.
Same guy brings up an issue not mentioned here for physical pairing: make sure you bathe. Ugh.
Also, make sure you're rotating teammates. Sticking in 1 pair can be nice if you like the person... for a while. But it can ruin a friendship if you do that for months.
I think the real keys to success there are in luck and management's hands. Make sure you have a mix of maturity and skill sets, and have engaged curious people. Slackers and, uh, "dim" people drag everyone's morale down more in an environment like that. I've lost those teammates and seen team productivity grow. At the same time, it's hard for a team full of people with little to learn from each other to stick with it. It's more engaging when you're teaching or learning or ideally both.
When working alone remotely from home, I simulate pair programming with a methodology I call "The Stranger". I sit on one of my hands until it becomes numb and tingly, and then it feels like somebody else is typing and moving the mouse!
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!