
On Pair Programming - joeyespo
https://martinfowler.com/articles/on-pair-programming.html
======
lifeisstillgood
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.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

~~~
oarabbus_
Why?

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

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

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

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

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

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

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

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

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

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

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

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

~~~
simonw
[https://martinfowler.com/aboutMe.html](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.

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

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

~~~
dustingetz
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

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

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

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

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

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

~~~
jacques_chester
> _what other industry or domain does this? none that i know of._

Aviation, some surgeries.

You know, low-stakes stuff.

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

~~~
jacques_chester
> _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.

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

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

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

~~~
Mike12398
You're not an introvert.

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
drdeca
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?

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

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

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

~~~
22c
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/...](https://docs.microsoft.com/en-
us/visualstudio/liveshare/use/vscode)

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

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

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

