
The case for pair programming - mijustin
https://tuple.app/pair-programming-guide/the-case-for-pair-programming
======
projectileboy
I used to be a zealot. I had found the religion of XP, and I enforced pairing
on teams I was hired to coach. Many people were happy to be exposed to it, but
many weren’t. Of those, some were better for the experience, some weren’t. In
either case, it was massively disrespectful of me to force it on people.
Certain kinds of people are drawn to programming. Asking some of those people
to pair all day every day is tantamount to asking them to switch careers. I
for one don’t have the emotional energy for it any more. Having said all that,
I would encourage any skeptics to give it a try, in the right environment with
the right teammates. It can really teach you a lot in a short period of time.

~~~
beefsack
I feel the more general lesson here is that zealotry in our industry is almost
always a bad thing. Whether it be in technology choices, development
paradigms, project management techniques, training strategies, or even just
how you deal with your staff and coworkers.

Whenever I come across a zealot in a professional setting, I'm fairly certain
they're intentionally ignorant toward better ways of tackling certain problems
(big red flag).

~~~
projectileboy
I agree, although I would qualify your last statement a bit to allow for (a)
the zealot is usually well-intentioned, and (b) the zealot is usually not
intentionally ignorant, but rather hasn’t yet learned that context matters.

------
RandallBrown
I worked on a team pair programming for about 3 years. I really enjoyed it.
Now that I've moved on to a different company and am working solo again, I
_really_ miss pairing.

I feel that most of the problems my team has now would be easily solved by
pairing. Things like shared standards (not just syntax but architectural
approaches that are hard to automate), testing (you keep each other honest),
and faster code review. Right now, if there's a bug in feature x, everyone
goes to the feature x "guy" to have it fixed. If that person gets hit by a
bus, feature x is hosed. People don't have a good idea what anyone else is
working on (beyond the few that seem to do most of the code reviews). Swapping
pairs every day or two easily solves these problems.

Things like on boarding new employees is just _so much faster_ that it's a no
brainer to pair, especially when they're starting out. Junior developers learn
_so much faster_ by working directly with a senior developer. Sure, it might
slow the senior down (very little in my experience) but it makes the junior
developer so much more productive in the long run.

Pairing is mentally exhausting at first and I can understand that it isn't for
everyone. Most people hate it at first, especially if they have a bad setup.
Most people I work with seem to think it means 2 people crowded around a
single laptop. Setting up real pairing station with multiple BIG monitors and
2 keyboards and mice is crucial. After you get comfortable with it, the
"always on" feeling goes away and it just becomes an enjoyable day working
closely with your colleagues. If you really give it time, I feel it's the
"right" way to develop software.

Switching a team to pairing might not be the right decision for everyone. Some
people are just uncomfortable working with others. I'm not sure those people
will be super strong members of most teams anyway, but they can certainly be
successful in some organizations. If you build your team around pairing and
select for it in your interview process, you can have really great results.

~~~
wvenable
> Right now, if there's a bug in feature x, everyone goes to the feature x
> "guy" to have it fixed. If that person gets hit by a bus, feature x is
> hosed.

I think it's admirable to want to spread knowledge around as much as possible,
I think having individual developers "own" specific applications or features
is a net benefit. Sure if a developer leaves, they take their knowledge with
him and someone else has to get up to speed, but that will necessarily happen
anyway.

There is only so much room in your brain; the more features or projects you
work on, the less you remember about any of them. Being able to go to the
feature X "guy" most likely means the problem will be solved significantly
faster. That person's caches are already primed, the pages are loaded from
disk, and they can hit ground running. That is a much better case to optimize
for than the off chance somebody gets hit by a bus. We also know that
multitasking is bad for productivity so the less people have to focus on the
better.

~~~
RandallBrown
I think what's really nice with pairing is that you can have feature ownership
and spread knowledge really easily.

The way I've done it in the past is that a feature will have an "anchor" or
someone who owns it. They'll work on most of it and be in charge of
interfacing with product on how it should work.

That person would switch pairs every day, working with a few people who then
pick up some of that context. Being hit by a bus is the classic example, but a
more realistic one is that the person goes on vacation. Now, instead of just
being 1 person with deep context on that feature, there's potentially a few
others that will know it well enough to solve the problem.

The people that are constantly switching will eventually own a feature and
won't have to multitask all the time. Also, when you're pairing with someone,
you get to share some of the focus with that other person, which I've found to
make switching contexts a lot easier.

------
carterza
I find pairing with anyone that is significantly outside the range of your
competency level, to be extremely frustrating.

You can have a junior dev, and hand hold, but it also requires effort on the
part of the junior dev / a desire to learn and grow. Without that, the
exercise is futile.

IMO - pair programming is over-hyped. I often find that I produce better, more
reliable code, with the more space and more time I am given. I agree that
pair-programming can rock in certain circumstances - but you need developers
that have a certain level of synergy, you can't force it.

~~~
jacques_chester
> _You can have a junior dev, and hand hold, but it also requires effort on
> the part of the junior dev / a desire to learn and grow. Without that, the
> exercise is futile._

If someone's not interested in learning or growing, I don't see how pairing or
not pairing makes a difference.

~~~
watwut
It is completely driven by senior developer. Many students find such pedagogy
demotivating. They are not getting tasks they could solve autonomously and
independently, every their step is watched as they are doing it. So, they
don't even have chance to make mistake, realize mistake by themselves and then
fix it. Imagine college classes done that way - everyone would rightfully
complain.

Motivation and desire to learn are partly function of personality and partly
function of environment.

~~~
jacques_chester
> _Imagine college classes done that way - everyone would rightfully
> complain._

The tutorial method is thousands of years old, actually. I suspect that if
one-on-one education was economically feasible it would be the model chosen
almost every time.

Having paired with people who don't know what "if" and "for" mean in a
software context clear through to individuals who've been in software for
longer than I've been _alive_ , I can only say that it works more often than
not.

I often hear that pairing _would_ be terrible at this, pairing _must_ be
dreadful for that, pairing _wouldn 't_ work for the other thing. What these
have in common is that they are rejections based on mental simulation of
events.

But ... I've actually paired. For years. It doesn't work for everyone but it
_still works for most people_ , so long as they learn it from an experienced
pair.

It is frustrating to see a thing work, over and over, then be told you must be
wrong, it can't possibly work.

------
keithnz
I started with XP way back in 99 after following the discussions on OTUG and
then the white book came out.

I PP for 8 -> 9 years. Theres a bunch of things I learnt from that

It is really good for improving everyones skills. There is a fast convergence
in good way to do things

The code quality is generally really good and people often develop good
habits, everything gets discussed.

It doesn't work so well when people are across different projects, much better
if they are all on the same project.

Teams reach a point where it doesn't actually matter if you pair or not, you
tend to carry on making good code.

It can slow down experienced devs and they often don't get the same kind of
"flow / mental zone" of coding they can get by themselves.

Developers need alone time to do their own coding experiments and to follow
their own noses

It 100% has to be done right and people need to be open to the idea, I went
into other companies who were trying to do it and it was failing massively.
There was animosity and a lack of openness to trying it. People really didn't
understand why they should do it, and felt coerced and threatened by it all.
Untangling those messes seemed ... unproductive :)

It's exhausting.

These days I don't see the need for full time pairing, I see it more as a tool
that has certain outcomes, and you use that tool when you notice certain kinds
of problems / weaknesses. I would think that teams should "pair" at some
point, and by that I mean watch each other code and have interactive
discussion about code as it gets developed.

------
maxxxxx
Pairing with someone you get along with is a great experience. But with a lot
of people I find it pretty miserable. I have paired with people who I just
almost never agreed with. I am not saying they were bad but I just didn't like
their style. There is also the risk of having one very dominant partner and
the other one just watching passively (or having checked out already).

------
mbo
The "How to pair with a junior developer" section is extremely considerate,
and highlights some behaviours that I know I've subconsciously engaged in that
may have negatively impacted a junior dev. Expanding this section would be
great.

~~~
rhacker
It actually makes a great reference. Today during a pair session a new
developer happen to mention a technology that might solve X, Y and Z.

I think 5 or 10 years ago I would have shut them down - I was much more
arrogant back then. Instead in the next few days this person is going to demo
something they've built since they are pretty much our team's expert in this
tech - since none of the others have used it. If everything checks out, this
could very well be our next large architectural shift - and that's incredibly
awesome contribution for someone new. Even if it means he'll be putting in a
lot of extra work and time - in my eyes that's better than turning him into a
robot that wants to check out exactly at 5pm.

------
erik_seaberg
I have to wonder how people make up for never getting into the zone.

~~~
mitchtbaum
I've been pair programming for about 6 weeks now, over Discord. The calling
and screen sharing functionalities work so well that my partners and I can
join and part quickly and easily. We can get deeply into what we're doing
individually. But collaboratively, we can solve problems that neither of us
can do alone.

I like this virtual setup for multi-user interaction a lot, and hope more
tools, even ones specific to virtual programming environments, come for it
soon. Tuple's making a remote sharing tool that looks interesting. What comes
to mind for me is a shared 3D Wayland environment, like this
[https://www.youtube.com/watch?v=_FjuPn7MXMs](https://www.youtube.com/watch?v=_FjuPn7MXMs)
so, hopefully more people will start focusing on [https://github.com/way-
cooler/way-cooler](https://github.com/way-cooler/way-cooler) and other Rust
desktop/handheld application level development.

------
city41
For contrast, here is an article I wrote that is largely against pair
programming: [http://www.mattgreer.org/articles/pair-programming-is-
not-a-...](http://www.mattgreer.org/articles/pair-programming-is-not-a-
panacea/)

~~~
rhacker
While I'm pro-pair programming I totally understand these issues. The way I
normally go about it is put it out there that I like pair programming. And if
other people in the team feels the same way, usually that just clicks.

I definitely think PP shouldn't be mandated at all. I think too that some of
the issues you bring up are very important - especially about the notion that
the soft spoken person will usually have their ideas rejected. A lot of
developers act in very peculiar ways often because software development shops
can be very toxic. Instead of addressing that toxicity, most places end up
with a few head honchos. It really is bad for companies actually and can lead
to many great budding engineers to leave or get out of the profession, sadly.

------
rhacker
We got rid of the bad breath, smelly ass, coffee spill issues associated with
pair programming. It's all remote now using VSCode Live Share and something
like BlueJeans or Slack calls to facilitate the communication.

------
artsyxxx
[https://books.google.ca/books/about/Pair_Programming_Illumin...](https://books.google.ca/books/about/Pair_Programming_Illuminated.html?id=LRQhdlrKNE8C)
<< Pair Programming illuminated shows all the different kinds of combinations
that are possible between programmers of different abilities and experience

------
hw
How well pairing works also depends on a person's personality. Introverts
don't really do well in pairing situations, and especially when paired with
someone totally opposite, the pairing essentially becomes a single person
coding and the other person just observing and nodding their heads.

~~~
watwut
Plus beyond introversion, controlling and dominant people make everyone suffer
during pairing. Also, shy people non-assertive people loose any possibility of
autonomy or independent decision making (they might or might not find it
uncomfortable). People who see everything in absolutes are hard to pair with
and find it stressful. Extroverts who still like to think about problems
silently or explore issues cant do that in pairing either.

The human social issues related to pairing are many more areas then just
introversion extroversion.

------
zaptheimpaler
Pair programming: when u need 2 devs to do 1 devs job

~~~
dang
Please don't post shallow dismissals to HN. This is in the site guidelines:
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

Fortunately you needn't look far for good examples of how to do substantive
critique; there are some excellent ones in this thread.

