
Pair Programming (give it a rest) - PeniWize
http://peniwize.wordpress.com/2013/11/17/pair-programming-give-it-a-rest/
======
ggreer
I can't tell if this is sincere or parody [1].

If it's sincere, I think the author is attacking a rather extreme position.

Sometimes I like to write code by myself. Sometimes I like to pair on stuff.
It depends on a lot factors. Is it complicated code? Do I know the
language/framework/codebase well? Do I have a peer who knows more than I do
about the problem I'm trying to solve? Is it important that multiple people be
able to maintain this code? Etc. Like most things, pairing is a trade-off. It
can have benefits, but it costs twice as much to write code.

That said, I think most people in our industry could benefit from pairing
more, not less. Studies on pair programming show significant advantages in
many circumstances [2]. If the author is sincere, I hope he'll keep an open
mind about an occasional pairing session in the future.

1\.
[http://en.wikipedia.org/wiki/Poe's_law](http://en.wikipedia.org/wiki/Poe's_law)

2\.
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.824&rep=rep1&type=pdf)

~~~
JoeAltmaier
If he was insincere, let me assure you that I could make all the same
assertions and be entirely sincere. Pair programming is for mediocre
programmers who need a lot of support. As a highly productive programmer with
decades of successful projects behind me, I can assure you that pair
programming would be disastrously disruptive to me; in fact my entire team
would bail if it were pushed upon us.

~~~
klibertp
> I can assure you that pair programming would be disastrously disruptive to
> me

And so you refuse to do it even if it would be tremendous help for the other
person. You won't pair with a colleague, because you don't like it, because it
would "disrupt your work", even though you could cause the other person to
become much more productive in much shorter time. You're not only being a jerk
by doing so, you're actually undermining your project and putting your
"decades of successful projects" at risk.

Yeah, highly rational decision, based on your dislike of (as per OP)
interacting with other people. I'm so happy I never met you.

~~~
JoeAltmaier
Projecting. I help other programmers routinely; I mentor high school students;
I run architecture meetings for the group.

I don't get anything done if I'm made to waste large portions of my day hand-
holding other programmers. My work is best done in a silent room with hours
uninterrupted.

I'm sure you'd be glad to meet me; I don't dislike interaction at all. Lets
just do it at a coffee shop.

------
cmdkeen
At work we have a consultant in at the moment doing technical mentoring. He's
gone right back to basics on a lot of stuff, unit testing, TDD, refactoring,
pair programming etc. For a while it felt like a waste of time, I didn't need
to be doing this etc. But a realisation is growing on me.

Shared understanding is vital, even more so in a team of "left brain"
introverts. Whether it is establishing what everyone thinks TDD to be and the
metrics to be extracted. Or whether it is making sure that at least one other
person knows what your code does, that it is the best way of doing it, that
you're not taking shortcuts or making "clever solutions" that aren't needed
and sacrifice maintainability.

Being a professional isn't about being dismissive of 9 to 5 paycheck
developers and their skills whilst slamming out loads of code. If your
experience is all of introverts who want to be left alone I dread to think
what your code review practices are like...

~~~
masklinn
> At work we have a consultant in at the moment doing technical mentoring.
> He's gone right back to basics on a lot of stuff

How did you go around to finding him? I feel we really need that where I work,
go back to basics and take up some "good habits"[0], but without a
consultant/trainer to suggest it feels like whining without contributing.
Attempting cultural changes internally on a suggestion basis doesn't really
work, people (me included) just go back to their previous stable state.

[0] both small scale, the testing and refactoring stuff, and larger-scale with
system architecture.

~~~
squid_ca
I understand your frustration with trying to do this "internally", but stay
positive and keep with it. If you (and like minded supporters) keep talking
about "best practices", your peers _will_ notice and _will_ start playing with
them in their work.

At our workplace, we have a monthly hour-long "Lunch and Learn" where we all
meet to do three things: listen to someone share some interesting code they
worked on that month (which helps to generate some enthusiasm and spread some
knowledge around); talk together about a specific best-practice; collectively
review some code with a focus on using that best-practice to improve the code.
It is a very simple, low-cost, low-time-cost way to formalize the fact that
you want everyone to pay attention to these things, and (in our case) has
really stimulated a desire among the developers to improve their code
practice.

To implement this, put someone in charge (or take charge yourself :) and just
start asking people to contribute. You will probably find there is a lot more
interest in this than you think.

Also, be sure to go easy on yourself and your peers as you try to change
habits. If you look back at code you wrote, say, three years ago, you will
probably say to yourself, "What was I thinking? I could write that so much
better now." In the same way, three years from now you will be able to say,
"What was I thinking? I could [test|commit|organize|pair-program|etc] that so
much better now."

~~~
cmdkeen
Cheers - I actually had a really good conversation in the pub on Friday with
some other relatively junior staff, and we all came to a much better
understanding of our goals and motivations, and how closely aligned they are.

It really drives the point - the social connections are what makes or breaks
you in an organisation. Any meaningful change needs allies, needs to persuade
people, and needs to deal with ego and politics. The people responsible for
what you want to change are probably those currently in management roles! It's
probably one of the harder transitions from academic/training when there are
absolute truths, to business where things become much more complex.

------
kalleth
I'm sorry, but I don't agree at all.

Part of writing good software is the ability to _interact_ with people. That
requires certain social abilities and the ability to talk confidently to
people about code, the same as pair programming.

Truly introverted developers may write elegant and beautiful code, but they
generally need an abstraction layer between them and the user/customer, which
can cause the most beautiful code to be wrong, because it doesn't fulfil the
requirement.

Pairing with people improves code quality by forcing you to _explain_ your
decisions, allowing you a better understanding of what you write, sharing
knowledge of the codebase across the team, and preventing tangents that aren't
what the client wants. It's not just about being more productive -- my
personal opinion is it's actually _slower_ than 2 developers working
separately -- but that doesn't make it less worthwhile.

~~~
kelnos
I think you're missing the point of the article. The core of it is
essentially: "being happy is one of the most important things in my life, and
pair programming would make me unhappy; therefore I will not do it."

Yes, he does try to rationalize a little bit here and there, but overall I
think that's it.

I don't at all believe that pair programming necessarily gives you a better
end product. I think it _can_ , but I think it depends a lot on the project
and individuals involved. Personally I'm not a fan. I'm not quite the hater
that the OP is, but I, too, would likely look for a new job if my company
suddenly required regular pair programming of everyone.

I think I'm pretty damn good at what I do. That's obviously a subjective
statement, but I could back it up with some facts that would seem to indicate
I know what I'm doing. If I paired with someone on certain projects, would it
create a better outcome? I'm not sure. Maybe it would. Maybe it wouldn't. But
I really don't care, because I'm certain I wouldn't enjoy the process. Does
that potentially limit my greatness as a developer? Maybe. Maybe not. But
that's where the happiness thing comes in. If pairing truly could make me a
better developer, and there's nothing else that could, then I'm honestly
totally fine not being the best developer I could be, because I wouldn't be
happy while practicing my craft.

As an aside: I'm talking about two peers of roughly the same skill pairing.
I'd be happy to pair with a junior dev for the purposes of mentorship or
knowledge transfer. Actually, I think pairing with _anyone_ for the purpose of
knowledge transfer is probably a good thing. I just wouldn't enjoy pairing as
a fundamental part of working on a project.

------
jbrains
I like to pair. I like to talk about pairing. I have worked with people who
don't pair well. I worked with one person whose wife noticed that his entire
personality changed for the worse when he tried to pair. He stopped pairing.

You don't like to pair. You don't want people to try to pair with you.

So far, I'm with you.

How do you get from there to "if you ever talk about pairing, you're
incompetent and horrible"? I have trouble with that part.

------
enneff
This whole article is predicated on the absurd straw man argument that there
are legion pair programming evangelists ruining the software industry with
their philosophy. In reality, even the people I know who practice pair
programming only do so less than half the time. It's hardly an epidemic.

As an aside: I am pretty tired of people saying "I'm an introvert," when what
they mean is "I'm an asshole." Even if you're introverted, you have the same
responsibility as everyone else to communicate in order to get things done.

~~~
frostmatthew
> I am pretty tired of people saying "I'm an introvert," when what they mean
> is "I'm an asshole."

And I'm pretty tired of extroverts expecting everyone else to be like them and
consider anyone "assholes" when they aren't.

~~~
enneff
That's not what's going on here. And I apologize for being pithy. My deeper
point is that a few (ironically) vocal assholes make introverts look bad by
using their supposed introversion as an excuse to be a dick.

------
michaelwww
Introverted programmers have always coded with other people, communicating
through emails, code reviews, bug hunts, source control comments, phone calls,
brainstorming and planning sessions. "Pair programming" seems to be a modern
fetish to get wallflowers to dance together in hopes they'll both write better
code. It's awkward for the introverted. Brain power that should be going
towards code is siphoned off into social interaction. Coding is an inherently
creative act, unless you're just stamping out boilerplate code at the software
factory, in which case pairing makes sense.

~~~
couchand
In a good pairing session, you are almost unaware that there's any social
interaction going on. You and your pair are both in the zone, applying more
than double the brainpower to the problem. The old saying is true, two heads
are better than one. The only reason it's not effective with more than two is
that the realtime communication breaks down.

~~~
memracom
People talk a lot about pair programming, but when have you ever read about
how to do it. What are the mechanics of it? What should a member of a pair do
or not do? I suspect that a lot of the problem with pair programming boils
down to people who don't know how to do it that end up creating a bad social
interaction and offending their partner.

------
GlennS
I think this is the nub of it: "the very small squeaky obnoxiously loud
minority".

Most people really don't like being preached at, and the agile community is
very preachy. They're also very certain that agile is best practice, while
everything else is cowboy.

I'm confident at this point that a sizeable chunk of the agile mantra is
pretty poor practice. TDD, for example, definitely seems worse than actually
using your human intelligence to plan ahead and design.

I don't necessarily agree with this article. I think most programmers do want
and benefit from some degree of collaboration on problems. Mostly at the start
when they're figuring out what they should actually build. I certainly
sympathise with it though. Sometimes I just wish agilists would shut up and go
away.

~~~
eddiedunn
There's nothing about TDD that prevents you from "using your human
intelligence to plan ahead and design". I really don't understand why so many
people think that.

The main point of TDD is organically "growing" modular and testable code.
Also, after a session, you have unit and function tests for free, instead of
having to implement them afterwards. Having a plan from the start, however, is
beneficial with TDD as well, as long as you're flexible enough to modify it if
necessary.

------
kfcm
The problem isn't pair programming, per se. It's the forced nature of it in
many locations. Every line of code has to be written/modified in a pair.

The irony? Pair programming has become a dogmatic process over the needs of
the individual developer in many locations, yet is still considered a core
Agile technique. That just isn't right.

Like the author, I'm more introverted. I prefer to code alone. Forced coding
or working with others drains me. However, if assistance is needed--myself or
others--I've no issues working in a temporary pair to solve a problem.

Pair programming wasn't intended to be an iron dictate of "you must". It was
intended to be a "it's ok to ask for help if you have a problem, because
working software is the goal".

~~~
couchand
You're right, anything's bad if it's forced on a team or applied dogmatically.

(Also I'd edit the last sentence to read proscriptively rather than
historically: "Pair programming shouldn't be an iron dictate..." since that's
really more interesting.)

------
rdsubhas
Yes I too am an introvert. But saying _pair programming doesn 't work with
introverts_ is not quite right. Introverts are not _no-talkers_ , they like
talking about stuff that they love. They don't _come out and talk_ , but are
truthful if you ask questions. So as a programmer introvert, I love discussing
about programming, new tools and languages, etc.

Its OK if you hate Pair Programming. Its even OK if you hate it without even
trying it. But just don't generalize it with being an introvert.

~~~
ismail
don't confuse being shy with being an introvert. Introversion has nothing to
do with enjoying talking to people. it is actually about where you get your
energy... for e.g do you feel exhausted after a day of social interactions and
need alone time? or do you feel energized and are ready to hit the town?
introverts would typically need aone time off to 'recharge'..

------
finkployd
As a student, I support pair programming. Last semester, we did a six-man
project building an client-server battleships game that offered singleplayer
and multiplayer.

We had to create a strategy to manage the quality of the project and chose a
task-based pair programming strategy. In those student projects it is often
the case, that the better students do a rather big portion of the project
while the others try to keep up. With pair programming this was not the case.
Everyone developed on a similar level. Yes, it probably slowed down some of
the developers, but for a student project, the main goal is to learn. And pair
programming was a way to do that.

Also, our project quality really benefitted from this. After developing the
basic server, client and game logic, we switched teams to do the next step.
For example, the team that connected the client to the server would now have a
person that knows the server side and one that ones the client side. This team
changing was done on a regular basis and helped putting the software together.
There were less problems with the code of different people working together
than in most other projects and I believe, that pair programming was a big
factor in that.

So, I can't speak for the work environment, but for learning to be a software
developer, it really was a good experience.

~~~
jebus989
You're arguing a point unrelated to the post. The author is saying that as a
highly competent SE, paired programming would be a detriment to him due to his
personality etc.

~~~
kalleth
I know you're not agreeing in this statement, but I think part of anyones role
as a senior SE is to help raise others to that level, even if it's to the
detriment of his own productivity.

~~~
htns
Well a cynic would say that in the case of the student assignment it was more
about forcing everyone to put in the same number of hours than it was about
efficient knowledge transfer.

------
mrandrew
A team's responsibilities go beyond delivering good software, a team must also
ensure it is always improving in its ability to deliver software in future;
raising the standards as individuals and as a group and sharing knowledge,
patterns and practices. Pairing is an extremely effective way of achieving
this, I've yet to see another way that even comes close.

Quite apart from his stubbornness around pairing, his broad-stroke
presumptions about people who do pair, people who are introvert and people who
are enthusiastic about sharing their patterns and practices smack of the worst
kind of smug arrogance.

It's fine if the author isn't interested in the benefits of pairing,
everyone's different. However I don't think I'd be particularly interested in
working with him or hiring him.

------
arnvald
Even though I agree that pair programming is not necessary (I think it's
useful, I sometimes do it and enjoy it, and sometimes I really need to work
alone), I do not like how this post sounds. It does not sound like "pair
programming is good, but I prefer to work alone and I think it's equally
good", it's more like "I work for 20+ years in the industry and I'm highly
qualified engineer and I don't want to work with people, so shut up all of you
that try to encourage people to try different things". That does not prove any
point, it's just a rant.

~~~
kelnos
_That does not prove any point, it 's just a rant._

You do realize that the first line of the post is "this is a rant", right?

------
darkchasma
This is a little silly. As a developer, I love cutting code. I really don't
care if I'm pair programming or not. I don't like to write tests nearly as
much. If you swap in "write unit tests" in place of "pair programming", the
article pretty much works the same, the one difference is the authors social
anxiety.

So really, this isn't about pair programming, it's about the fact the the
poster has social anxiety, and needs to address that. (And I need to stop
posting on HN and write some tests).

~~~
JoeAltmaier
You're projecting. I completely understand the OPs position; I concur 100%.
You can dismiss it as some foolish antisocial whine if you like; or you could
understand that his position is entirely valid.

If you've never gotten into the zone; if you've never spent an entire
afternoon and missed meals and been utterly surprised at the clock when you
come up for air; if you've never been productive at the level of a seriously
skilled programmer, then I suppose you would dismiss this as a silly rant. But
that says more about you than the OP.

~~~
couchand
If you've never gotten into the zone WITH a pair you're really missing out.
It's a far more incredible experience than doing it yourself, just like many
things... ;-)

------
Falkon1313
20+ years of experience as a prima donna who refuses to work with others and
can't even discuss code with another programmer isn't very impressive. With
that attitude, the experience wouldn't be enough to qualify someone for an
entry-level junior developer position anywhere that I've worked. In my
experience, programmers who don't want anyone else to see their code and
aren't willing to discuss it have good reason to hide it.

------
coldcode
I have no issue with four eyes looking at a problem for a bit. But I would
never sit next to someone all day long every day. I have no trouble
communicating when it's necessary but to me pair programming seems a complete
waste of 50% of your bandwidth, with virtually no proof that you make it up in
quality of output. If it works for your team fine, but don't expect that it
means it works for everyone.

~~~
couchand
In my experience pairing works best when it forces you to focus. If you have
only a two or three hour pairing session with someone, you're going to make
sure you use it effectively. You're right, sitting next to someone all day
long is a waste.

------
markm208
The OP clearly doesn't believe that he has a responsibility to teach those
around him to be better. Imagine that you were the CEO of a company that had
one great programmer and four average ones. Don't you think the CEO would want
the great one to spread some of his/her knowledge? Now, imagine you were one
of the four average developers, wouldn't it seem crazy that you sit three feet
away from a great developer but never learn anything from him/her?

Do we want this to be an industry where only the self taught succeed? I don't.
I believe there are still some things that I can learn from others. I believe
I am obligated to help those around me get better- it should be part of the
job description. Pair programming, if it does nothing else, does open up what
is normally a solitary activity and gives people a chance to learn from
others.

~~~
JoeAltmaier
You're projecting. He never said any of that - he may spend his afternoons
mentoring and building housing for lepers for all you know.

------
JackMorgan
Why such a rant at all? If you can't change your job, change your job. Luckily
for you, pairing shops are in the vast minority, I'd guess you'd have to go
out of your way to find another one no matter where you live.

It's the same as any software practice: TDD, which form of typing,
vim/emacs/IDE, OO, etc. Without solid measurable proof that it's best for your
specific job/domain/team (basically impossible) it's all just preference
anyway. And someone who hates OO is going to constantly find ways why OO is
terrible.

So we gather into jobs and teams that all share the same religious faith on
all the above mentioned. Interviews are basically the same as you get in any
church: do you believe these core faiths about our doctrine, and are you cool?
Great, you're in!

------
rsslldnphy
I think that blog could have done with another pair of eyes.

------
xcess_denied
I don't see anything wrong with Pair Programming unless we overdo it.

Does this mean Code/Peer Reviews should be given a rest too?

~~~
kelnos
Why put words in the author's mouth? He's talking about one specific thing he
doesn't like. He hasn't given us any indication of his feelings on reviews, so
there are no conclusions you can draw.

------
hobs
It sounds like this is a conversation you should have with your boss, and not
really a pair programming problem.

A specific type of interaction is not for everyone, its clear you are not
making any claims about it except for it doesn't work for your personality.

------
ExpiredLink
He's a bit late to the party. The pair programming hype is long gone.

------
NAFV_P
Give it ten years, employers will make their underlings have radio
transmitters implanted deep into their heads in order to communicate over
great distances.

This is the future of pair programming... Hive programming.

