Hacker News new | past | comments | ask | show | jobs | submit login
On Pair Programming (martinfowler.com)
156 points by joeyespo on Jan 15, 2020 | hide | past | favorite | 120 comments

As a "senior" the thing I find about pair programming is that it forces code review - it's waaay too easy to blip over code in a review. It really is higher quality code review

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 used pair programming at a startup with a heavy junior engineering team. I loved it cause I could pair with any one of them and that “mentoring session” would be retaught without me having to do it. Our junior engineers progressed really fast in a short amount of time and I didn’t lose my mind having to reteach the same lessons over and over.

I find pairing works well for onboarding new members.

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.

I’ve done ping pong / tennis programming before and it was honestly one of the most enjoyable experiences at that particular job. It helped that I was a junior developer pairing with one of the most senior developers at the company, who also happened to be very enthusiastic about what we were working on.

Yeah, I hadn't heard of that style before, it soundw really fun and seems like a good approach when you have a well defined feature you want to get done quickly.

I work for an enterprise and use pair programming sparingly. It's particularly useful with juniors who are eager to work hard but don't know how to think about writing software. It allows a fair amount of narration. I've mentored a few people this way and it resulted in their productivity and skill level skyrocketing. It's worth noting this never came from a top down mandate or anything. It's just one more tool in the tool belt. I think that's key to success, adapt to what works best on an individual level.

I see that as mentoring - really valuable for the team and the mentee, and more of a job for the mentor.

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...

It's good for transferring code ownership and development culture to a new maintainer, though.

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.

The tennis thing may actually work. You get quick review and if something is difficult you can do some pair programming.

We pair when we get stuck. It isn't our standard way to work, and it is difficult, in particular for remote teams. But still, spend 15-20 minutes screen-sharing with a coworker, and you find one of two things happen:

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.

I wrote this after almost exclusively pairing for 3 years: https://www.mattgreer.org/articles/pair-programming-is-not-a...

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.

I had someone in an interview once "confess" that they did so much pair programming they had forgotten how to quickly do things on their own. It was said as if it was one of the pro's of pair prog., but I saw it as a huge downside that this person was so dependent on others to complete their day to day tasks.

I'm torn. I don't feel comfortable pair programming, but I think looking at an individual's speed is too narrow. Consider, you probably don't criticize this person's use of an IDE. Why is that different?

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. :(

If someone can't program without an IDE, there are plenty of free ones that they can download, and they're unlikely to ever be in a situation where they can't find an IDE but they can run and test their code.

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.

This still feels over simplistic. If there isn't someone else in the office to pair with, the code isn't getting pushed anyway, as it will lack a review.

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. :)

I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming.

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.

For such a person, short periods of pair programming might be sustainable, but beyond that you'd expect two reactions: either the become combative as they reach the end of their rope, or they shut down, at which point they are just the chauffeur and the other party is calling all the shots. One of those is immediately and obviously detrimental to teamwork, the other is just as bad because it's insidious.

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.

I sometimes lean toward calling it discriminatory, but generally don't - not because I think it isn't, but because I think that doing so weakens any legitimate criticism of the practice by coming across as hyperbolic.

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.

> 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.

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.

It sounds like you and I are very similar.

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 appreciate your positive encouragement and that you took the time to write. I'm glad that you jumped in at the deep end and that it worked out so well for you :-)

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.

Mine does too! I would generally describe myself as an ambivert (right in the middle of intro/extrovert) and I would say 6 to 8 hours a day on pair programming is too much.

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.

I think it's endemic of larger open plan office style organisations. They have (unintentionally?) self-selected out those with sensory processing issues plus some forms of autism just by the way the workplace is shaped. So perhaps that's why the concerns stated in the article don't take people with SPD/autism/other related issues into account.

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!

> Pairing causes the social part of my brain to activate which is fine, but I cannot also think analytically in real time while speaking.

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.

I have long thought that pair programming and open offices were yet another way of punishing anyone who is neuro-atypical.

I am an introvert (although I don't have social anxiety). I work at a company where we pair program every day. I was very nervous about it at first, but I absolutely love it.

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.

Same. I'm introverted but find pairing works well for me. I don't like it if it goes on for more than a day in a row, however.

I consider myself rather socially anxious and introverted. I pair-programmed at a startup for the whole day, every day, for over two months, for an internship.

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.

It's not even an issue of "mental resilience". Pair programming, like any other close human interaction, is strongly weighted toward the most aggressive or insensitive (or autistic) personality.

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.

Just a heads up, HSP is often comorbid with autism as are plenty of other atypical sensory processing manifestations.

Every label probably has a range of details which can describe it, but in my experience autistic people are marked by their relative inability to understand social cues and other non-verbal (and even verbal) indications of emotion.

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.

Would you mind expanding HSP? An online search seems to indicate Highly Sensitive Person which would fit based on context?

I've done fulltime pair programming with dozens of people and not found this to be the case.

Pairing is a skill. Practiced regularly it becomes easier and smoother, like any other skill.

tsss on Jan 16, 2020 [flagged]

I sure am glad I never have to do pair programming with someone like you.

You might be looking for the section "Pairing can be exhausting".

If forced to choose between pair programming and not programming at all, I think I would choose the latter.

I was forced into it for a few months when it was hot and Agile was still XP (Extreeeeeeme Programming). I found it agonizing. I was unable to do anything deeper than code the simplest functions. Everything I "accomplished" felt shallow and I could not come up with something better until I was unpaired. Sure, I could bash out comments and boilerplate and dumb little helper functions, but the part of my brain that seems to spit out the mysterious solutions that are the point of the whole exercise was dead silent.

Pairing destroys deep focus. It's an impediment for hardcore coders. Maybe it appeals to extroverts with short attention spans who prefer to socialize rather than do their jobs.

I'd choose not programming over a team of solo virtuosos and 10x feature factory cogs myself


Not OP, but for me, it's like having someone stand over my head with a pot, banging it with a spoon incessantly. It utterly destroys my ability to concentrate.

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.)

Pairing programming is like any skill. If you never do it, you will be terrible at it. I also believe that pair programming requires a level of psychological safety that not all orgs possess.

Possibly, but the time and energy it would take to do that would be far better spent brushing up on new and not-recently-used technologies. Ability to produce quality code is far down the list of my weaknesses, and life is short.

Goal of pair programming isn’t better quality code, that is a side effect, but better quality solutions. It’s one of those 1+1=3 types of things.

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.

I'm happy to discuss things at the water cooler or in front of a whiteboard, and this seems to be an efficient way to discuss design or help junior people. But sitting next to someone at length is rarely helpful, to me.

Were you coding with someone either much more, or much less experienced than you? Without knowing the case, this could affect how successful the pair coding is.

Two people somewhat less experienced. I don't believe that was the issue.

Out of curiosity do you think they benefited from the experience?

Hard to say. The code that was produced was worse than useless, IMO. I think they were programmers that had both peaked (and stopped learning) when they were young. I'd guess they're in management now.

it can surely be, but do you happen to have times where you sluggish and facing a problem you're very far from knowing how to solve ? in which case it helps making progress. I'm mostly speculating based on my small experience

Try using an old version of Visual Basic. Note how when you type something with a syntax error and then cursor off the line, the IDE will flag up the error with a modal dialog box you have to dismiss before you can continue.

That's pair programming, except the modal dialog box is a smelly human looking over your shoulder.

This is the most accurate description I've ever found of my experience with pair programming. Thank you!

It's pretty much the opposite of what attracted a lot of current programmers to the field in the first place. Even if it were objectively better (which I doubt), I don't think it would be popular.

No pair would ever let me go off into the experimental wilds that are ill advised but is also where greatness can be found.

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.

For many of us, perhaps most of us, being forced into Pair Programming completely destroys the enjoyment and fun of programming. For people like me it's the difference between loving my job, or hating every second of it and not wanting to get up for work in the morning.

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.

I haven't tried it, but I know myself, and how I work.

- 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.

I found that putting thoughts into words was a skill that became much easier with practice. And then I realised that it forced me to structure my hunches, which would knock some of them out on the spot.

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.

I'd venture 99% of pair coding is done by people who don't know why they're even doing it and set themselves up for failure at the outset ultimately crying sour grapes

Personally when approach a task I like to be alone and do design. At this point I do not need anyone messing with my thoughts. If I need advice sometime during the process due to let's say lack of experience in particular area I'll call someone who does and ask for advice. Does not take long. Few minutes usually.

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.

I would take less money to get to work like this. The isolation is what I find hardest about being a developer. I work far better in a team with people relying on me. Direct interaction like that makes the days so much more enjoyable. I really hope to one day find an employer willing to adopt this practice.

If anyone is hiring I'll apply.

I work for a company that takes agile development practices seriously, and I pair program all day, every day. I absolutely love it -- primarily for the reason you cite (I previously worked mostly solo as a freelancer or remote teammate)... having the direct accountability all the time makes me much more focused and productive. (fwiw, I am definitely an introvert, but a one-on-one situation is much easier for me than a group).

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).

You don’t need an employer to by into pairing. Get them to buy into managing work at the team level instead of the individual level. Then you can safely pair with your team mates.

My experience of pair programming, which spanned about 4.5-5 years of working for Pivotal Labs and in Pivotal R&D, was pretty much universally positive.

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.

Nothing wrong with "pair programming". It's only natural when people are friendly, engaged and cooperating, in that order.

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.

Agreed. The stigma around it seems to be that either side can treat pair-programming as a pop quiz when really it’s just another set of eyes and a discussion.

Pair programming is a nightmare for introverted people. Part of the appeal of coding is the relative solitude of the work. I think any company that mandates it is just a place I won't work.

I'm always slightly surprised when I see an article on martinfowler.com that isn't by Martin Fowler. I can't think of many other personally-branded domains like this that feature guest author content so often.

... 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?

https://martinfowler.com/aboutMe.html helps explain what's going on here:

> 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.

My experience of PP has been that it's often a way for one of the devs to prove that they are the smartest person at the desk, and its far from a collaborative effort.

A lot of dev teams suffer from the iamverysmart problem already, and PP just seems like a way to exacerbate it.

I have somewhere between moderate and severe social anxiety. Was on a team earlier this year that did 100% pair programming. Was the worst 6 months of my career. I had weekly breakdowns, my mental health got much worse ect. Once I was moved to a different team, my mental health quickly recovered.

I had a coworker with whom I did some pair programming and it was painful. He was very talkative, to the point of forcing me to interrupt him every time to come back to what we were doing. Also most of the time he made really hard to follow the code because he took every opportunity to show off his keyboard-shortcut-skills, jumping from file to file, jumping between lines of code, commenting and uncommenting code... all that very fast.

1) You can make pairing part of the interview

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

This describes every pair programming session I’ve ever had in 15 years and 5 companies. And I’m sure I’m guilty too. Pair programming occasionally helps, but as a frequent practice it causes systemic harm, especially to morale.

The problem is treating this stuff in an "inheritance" rather than "composition" manner. Which is precisely how most managers think, AKA management fads.

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 have never once been able to look at this and think it was a good idea outside of specific training sessions with specific coworkers for specific purposes.

I think programmers should be considered professionals who can do their own work quite well on their own, and held to that standard.

What about pairing strikes you as not considering programmers to be professionals?

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.

the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of.

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.

> what other industry or domain does this? none that i know of.

Aviation, some surgeries.

You know, low-stakes stuff.

those aren't analogous, like at all. or actually, they are analogous, just not in the sense you mean, as they don't serve as examples of "pair <whatever work>".

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.

> for both pilots and surgeons, no one is doing the same job at the same time.

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.

> Do you think pair programmers are literally bashing the keyboard simultaneously?

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.

One person is sitting at the machine, the other is sitting beside them. Like how one person is flying the plane, the other is sitting beside them. Pilot/navigator is a common role division. In pair programming, the person at the keyboard is doing the minutiae of the immediate task at hand (the pilot), while the other person is thinking through the next steps or how it fits into the whole (the navigator). They are not actually typing at the same time.

thank you!! i had the same exact thoughts last night but refrained from commenting. same exact thoughts about pilots and surgeons.

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.

And yet in software, the people in high-stakes domains who really care about quality (like the Lockheed shuttle group) don't use pair programming. Has any team using pair programming ever had a defect rate as low as 1 bug per half million lines of code? Or even within an order of magnitude of that?

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.

Fundamentally different to software development on both counts.

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.

Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on.

The easiest time to catch mistakes is early.

> Software mistakes can be pretty dire

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.

> Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery.

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.

> When do they occur? When the code is run, not when it’s written.

> 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.

Coding is NOT a real-time procedural performance activity, and thus can not be compared to aviation or surgery. Code reviews, collaboration on architectural decisions, and QA catch mistakes as early as necessary.

All these professions require a mix of procedural and declarative skill. Pilots and surgeons aren't professional athletes, they rely on enormous amounts of declarative knowledge.

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?".

Read again: Coding is NOT a real time performance activity, thus can not be compared with aviation and surgery in that way. Pairing is a requirement to do aviation and surgery reliably and accurately, but is completely optional for coding well, and arguably reduces quality of code in many cases.

> The easiest time to catch mistakes is early.

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.

My experience is that it does catch mistakes early. And it's not mutually exclusive of other ways of spotting errors, it's reinforcing.

with pair programming, you have two people supposedly in the same head space, if it's working as sold, writing code. the benefit of tests and code reviews is that they come from a different head space than what the code was written in.

As a counterpoint to most of the comments here: I work at a company where almost every developer pairs all the time. I absolutely love it. I thought I would hate it. I'm an introvert. I previously worked as a solo freelancer and then as a remote teammate. So I was very nervous about this aspect of the job, but figured I'd give it a shot (other things about the job were appealing enough that I was willing to try it out).

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).

You're not an introvert.

I sure am! Introversion doesn't mean you don't like interacting with other people, rather it's that such interaction is draining, and you need to be alone to "recharge" (whereas extroverts "recharge" by talking to others). Even the exhaustion of interacting with people is more of a scale than a binary thing -- I personally find one-on-one interactions much easier than groups.

At my first job I mandatorily pair programmed with someone every day for months and we had very different personalities. Neither he nor I wanted to and the result was we wore on each other, decorum broke down and the code itself was weaker because we would take turns ignoring the situation to get what few moments of peace we could in the day. We both left that company around our 1-year mark even though otherwise it wasn't bad got out at 5pm every day, catered lunch sometimes etc. I understand it is useful in certain situations but that largely turned me off from it as a concept and I still doubt the benefits when used "properly".

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.

Pair programming is fantastic.

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.

I been working full time now about 15 years and I think Martin Fowler's blog and especially articles like this do more harm than good.

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.

All around pretty good article. Never thought about using the pomodor technique while pair programming.

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.

I think that section makes good points about hierarchies between more and less senior people, and between people with a CS degree and people without, but yea I think it is unnecessary to single out white men and imply that they are more likely to try and hog the keyboard or always be in teaching mode.

Pair programming is by no means "crucial".

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'm sure pair programming is great for certain personality types, but please do not treat it as a panacea.

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.

I find PP useful for complex tasks where two devs can bounce ideas off each other (preferably in a breakout room with a whiteboard).

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.

I've worked at places in the past that forced pairing. One monitor and two keyboards style. It was painful; impossible to get into flow state.

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.

Here is a beautiful example. Using "screen" to switch every 5 minutes or so... https://www.youtube.com/watch?v=yG-UaBJXZ80

I fake it by doing a screen capture of myself working and then playing it back.

Who are you fooling with this screen capture? Your programming partner?

Perhaps by “fake it” they meant “emulate it” rather than “deceptively produce the appearance of it”.

This would allow one to double check ones actions in order to notice and correct mistakes one made the first time?

So while pair programming what happens with the never ending string of distracting Slack messages and diversions? It just seems completely impractical for the environments I’ve had experienced.

Having another person around helps me stay on task. I have to put off engaging with those distractions until a scheduled break. For that reason alone, pair programming can be more productive.

I've seen a few patterns at Pivotal. In Pivotal Labs and some R&D projects the team is fully colocated, so Slack isn't necessary for the day-to-day.

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.

You DnD. If you don't feel like you can do that, then I would suggest you're not in an ideal working environment for fostering productivity.

Anyone know of a good, open source, cross-platform video conferencing application?

Not exactly what you asked for, but I have had success with pair programming using VS Code Live Share[1] and Mumble for VoIP[2]. I don't think video is particularly important when you're both seeing the same screen and able to talk about it.

[1] https://docs.microsoft.com/en-us/visualstudio/liveshare/use/...

[2] https://www.mumble.info

I've been trying this recently, but find it hard to debug issues because I can't see the output of the program being run or use a debugger on it. We got to the point of sending Dropbox links to screenshots of chrome with the devtools console open, which seems absurd. Maybe chrome remote debugging could help?

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.

Edit: Completely missed that VS Live Share has a solution for this. Amending my complaint to be about the discoverability of the UX

Jitsi looks interesting: https://jitsi.org I've never tried it out, but I am very tempted. Looks pretty clean and modern, with a pure JavaScript WebRTC client, in addition to the usual native apps.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact