
The Only Person I’ll Pair Program with Is My Cat - kiyanwang
https://hackernoon.com/the-only-person-ill-pair-program-with-is-my-cat-86da6fb4da3d
======
hadsed
Well, it certainly seems difficult to pair program for 8 hours a day. That to
me indicates that people don't understand the point of it.

For me, pair programming with the right person always resulted in a quantum
leap in my knowledge and skills. This was true for the astrophysics professor
who taught me about Linux, RAID, Fortran, and modelling colliding galaxies, it
was true of the electrical engineer who wrote driver software for a DNA
sequencer, and it was also true for the guy who would keep postgres from
falling over every damn morning at a startup whose data was just exploding.
Even today, when someone new comes to a project we sit down every day or so
for a few weeks and we code.

The amount you can gain just by watching a pro is incredibly valuable. It's
all the little things, the tiny decisions they make, the way they think about
problems and solve them. You'll get a glimpse of the reasoning and experience
behind their philosophies. These are not things you can easily see through a
pull request, in a classroom, or even in meetings. For me, it is the ultimate
kind of mentorship.

~~~
abritinthebay
Most people _don’t_ understand Pair Programming. Most people don’t understand
_most_ Agile/XP practices though.

They _will_ often write lengthy blog posts about how said practices don’t work
while also illustrating they never did them well in the first place though.

~~~
vonmoltke
They also often write lengthy blog posts about how well it worked for their
specific situation and then pontificating about how it generalizes to all
software development.

~~~
abritinthebay
Agile _principles_ generalize to all software development. The _specific
application_ of those principles at one company won’t.

That’s the core difference people miss.

Of course then there is the difference between “software development” and “one
individual programmer”. Not all programmers will gel with Agile stuff as well
as the next one. That’s why it’s _not supposed to be rigid_ (it often is when
done poorly).

But yes, an understanding of the _principles_ is required to translate them
into _practices_ for a team. Rigid adherence to Scrum or XP is missing the
point.

For a good look at a way one company took the principles of Agile and applied
them in a very effective but _utterly idiosyncratic_ way... look at Spotify.

Pt 1: [https://labs.spotify.com/2014/03/27/spotify-engineering-
cult...](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-
part-1/)

Pt 2: [https://labs.spotify.com/2014/09/20/spotify-engineering-
cult...](https://labs.spotify.com/2014/09/20/spotify-engineering-culture-
part-2/)

------
rdtsc
I don't like pair programming. I like pair designing, pair debugging, tutoring
or explaining how code works. Then best if everyone goes back to their office
/ house / cubicle / desk and does programming.

~~~
peapicker
This, exactly, is what works well in my experience after coding for 25 years.

------
jacques_chester
These are common and, I think, reasonable objections. Particularly for someone
who's actually done it.

I work for a company - Pivotal - that relies on all-day pairing.

# Tiring

I agree that it is tiring. We take breaks, as many as folks need. I tend to
introvert and I spend time alone during lunch to recharge. That said, it
became more normal after a while. It does for most folk.

# Configs and Ableism

I didn't experience the config-by-committee thing. Each pair, each team uses
whatever they want. There are common configs around, but you don't have to use
them. If you do, it's mostly because they're helpful and commonly installed.

My pairs have always accepted accommodations for my own needs. For example, a
symptom of my ADHD-PI is dyspraxia. Stupid hands. So I need much lower mouse
sensitivity or I will have an infuriating time overshooting everything. When
my peers pair with me they turn it down. When they pair without me they turn
it up. Nobody really gets twisted up about it. If I paired with someone asking
to bump the font, I don't mind. Colour-blind? Jetbrains have a checkbox for
it!

Being empathetic is part of being a good pair. It's harder than it looks.

# Learning

I agree and disagree. I think that saying that pairing is the _best_ way to
learn _all_ things is obviously wrong, bordering on strawman. But it's a great
way to learn a lot of things. It's a great way to see examples of practices,
to have examples explained, to learn the quirky, hard-to-describe-in-docs
gotchas that someone with more experience has already encountered for you.

On the other hand, sometimes it's better to rip through a pile of reading.
Even if you come out completely wrong, you come out with some kind of skeletal
understanding, on which pairing can quickly build.

I've argued internally that a key difference is in how easily something is
_diffused_. Some lessons, knowledge and behaviour are highly diffusable; some
are not. TDD, for example, is very quickly and effectively diffused by
pairing. Stack-specific knowledge is diffused at a reasonable clip, but works
best with skeletal knowledge. Unobservables or topics with long feedback loops
require different approaches. In these situations you turn to books and
training as a prelude to having that knowledge refreshed and supported by
pairing.

I have both observed and been responsible for "watch the master". Locally we
call it "Bulldozing". I used to do it without thinking about it. It sometimes
still happens. It is still incumbent on me, the bulldozer, to be aware of
that.

I have had discussions with pairs of the form: do you mind if I bulldoze for a
bit? Sometimes they're cool with it and we're off to the races. But again, if
they ask to slow down, we slow down. It's _pair_ programming. I am working
_with_ someone, so if _either_ of us wants to change the dynamic, we talk it
out briefly.

In that same vein, I've been in situations where I am exhausted and struggling
for inspiration. I'll say, "do you mind driving a bit more today?", and
usually that's fine. Often after a while I begin to tune in more and the
dynamic shifts, organically, to a give-and-take. But it is also up to me to
stop my pair if I don't understand what she or he is doing. I do this a lot.
It's welcomed because we don't want to fall into _future_ master-watching /
bulldozing situations.

At Pivotal we constantly discuss this stuff, constantly argue different
approaches and constantly experiment with it. Right now, for example, I am on
an "odd" team, meaning someone is soloing each day. I find that a solo day now
and then is a good change of pace and lets me do deep-diving and sploshing
around.

But I also find that I am less effective as a 100% soloer. I go down rabbit
holes. I make simple errors. I get stuck on something that might be obvious to
someone next to me. I form elaborate theories that get punctuated by simple
questions. I begin to draft The Last Code We'll Ever Need, before realising
I'm just trying to get a simple task accomplished.

# Pairing in general

Most people who criticise pairing haven't tried it a) with someone experienced
in pairing, b) for more than an afternoon. When people come to pair with us in
Pivotal Labs, they are often skeptical and it often takes a few weeks for
pairing to click and seem like a good idea.

Sometimes it just doesn't. Which is good. No practice is for everyone. But I
also want to point out that my experience, the experience of my peers, the
experience of many of our clients, is overwhelmingly positive. We are not
preaching this from a book. We're doing it.

# Cult Beck

I once introduced a talk by Kent Beck. In the lead up, I told him that the
first time I read his TDD book, I thought it was total horseshit.

He laughed. In the talk he started with the story of how nobody attended a
talk he gave when he was new at Facebook (but the cooking class next door was
full). As cult leaders go, he has a talent for deflating his own ego.

~~~
abritinthebay
I have to say - I kind of want to work at Pivotal for a few weeks just to
learn how you guys do it.

Seems very very dialed in. Would be a great learning experience.

~~~
jacques_chester
It's been quite an education.

Don't get me wrong. It's not perfect. It can't be.

But it's the best job I've had by a country mile.

------
lgleason
related :) [http://purrprogramming.com/](http://purrprogramming.com/)

