JOE MOORE: My name is Joe Moore,
and I've pair programmed for almost thirteen
and a half, almost every single working day.
And for the last four years, I've pair programmed
remotely using remote pair programming full time,
out of those thirteen years. I work for Pivotal Labs.
We're a Agile software-development consultancy.
And I work remotely from Atlanta.
There's two of you who didn't hear this. I'd
love feedback at bit.ly dot com slash pairprogrammingama, it's
totally anonymous. And, also, for the other people who
walked in, there's a microphone here and a microphone
over here. If you have questions, it'd be great
if you could make your way that way and
start, and queue up while I kind of blab
on about some other stuff. If not, I'm gonna
grab these mics and I'm gonna run around, and
do a, I don't know, a Maury, maybe. I
don't know who's, is he still around?
Anyway. So, again, thank you for all, everybody for
coming here. Who is familiar, at least somewhat, with
pair programming? I'm gonna call that eighty to ninety
percent. That's great. So, for those of you who
don't know, pair programming is a software development technique,
by which two programmers work on the same code,
at the same time, solving the same software problem
on the same computer. That's what pair programming is.
And you can throw the word remote on there,
and guess what, that's all that stuff, just using
some remote collaboration softwares, such as video chat and
audio chat and screen sharing and such.
So what are the benefits of pair programming? I
could have slides and slides and slides, but I'll
just give you a few. It's everything from having
a continuous code review to cross-training junior people and
older people, or, or more experienced people. Cross-training people
from different disciplines. You tend to introduce fewer bugs
because you have two eyes on the same thing.
You have differing opinions, which is really great, because
that ends up raising what I call the whole
team to what I call the highest common denominator.
Because that kind of disagreement and such is really
great. And it goes on and on and on
and on from there. In general, the general principle,
I think as most of us know, in almost
everything, two heads are better than one when you're
trying to solve hard problems.
What are the challenges of pair programming? It's extremely,
it can be very exhausting. Personality conflicts can be
difficult when people don't necessarily get along. It's definitely
what I would consider to be the most difficult
software development practice to implement, both from a social
point of view, from selling it to people on
the ground people, to selling it to management that
it's, not it's not just, it's not double the
money and twice the time, et cetera. But it
also, I feel, has the greatest benefits. So, it's
the hardest, but it's got the biggest pay off,
if you're willing to dedicate yourself to it.
And this is the, one of the top three
questions, so I thought I'd go ahead and take
care of that now. When do you decide to
breaks? When do you decide to go to the
bathroom? And the answer is, whenever you need to
go to the bathroom is the optimum time when
you should probably do so. And it kind of
points to, you know, you're just people working together.
You know, you, you decide to take breaks when
you're ready to take breaks. If you've been going
for an hour, you've been going for more than
an hour. Yeah, take a break. Stretch your legs.
Play from ping pong. Use facilities. What you're kind
of into. Take breaks. It's a super intense discipline.
You, you do get tired, and taking breaks is
super important. And do so whenever you feel like
you need it. Need to.
And with that, ask me anything. Who's got a
question? Over here there's a question.
QUESTION: So, my team has been doing pairing, but
we find that, just subjectively, that it tends to
slow things down by maybe fifty to a hundred
QUESTION: In other words, things tend to go up
to twice as slow when we do it. But
we still use it for our hard things, like
ramping up a new developer on a project, or
laying the, the foundations for a new project. But
not for a lot of other things, because of
the time cost. And I was wondering if you
could comment on how it effects your velocity and
maybe we just need to look further down the
road to see pay offs and velocity? Is it
one of those things?
J.M.: Sure. So, I'm hopefully not going. Raise your
hand if you could not hear the question. Everybody
could hear the question. That's great. Cause it'd be
great not to spend time repeating. So it looks
like the mics are working.
So, you all heard the question. Velocity seems to
slow down. I think that the empirical evidence has
shown that, at least in a controlled environment, pair
programming has been shown to slow down accomplishment of
tasks by fifteen - one five - percent in
a controlled environment. And I think that this is
often with college students who are either paired up
or doing solo. So that's certainly not fifty -
well, five-zero - to a hundred percent.
And there, there are other pay offs. But I
guess my initial reaction would be, you know, pair
programming is a tool, and the, you know, the,
I would call it the lower-case agile toolbox. You
know, not the, you know, it doesn't, it's not
necessarily mandated. But there are other things that you
might be able to apply if you find that
things are just going really slow. And that is
identifying the issue. And maybe you've already done this.
You've already identified, this is taking twice as long
and here are the five reasons why. And they're
insurmountable reasons.
So, I would say, you might want to use,
you know, what's called a retrospective, or investigate, you
know, dig deep into why things are taking too
long. Are you arguing about stuff? Are, are the
pairings so unbalanced that the senior people are constantly
trying to pull up people who are, are, are
more junior? Are there differing opinions and people are
just constantly arguing? Those are, you know, there could
be many, many reasons, so identifying the problem is
the first step to figuring out maybe why it's
taking that long, because in my experience, it should,
potentially be a bit slower, on the metric of
from moments on the keyboard typing the first characters
to maybe doing a commit. And that's not what
encompasses done software. That's just two people coming up
with the best solution. And you can have other
pay offs further down the line, such as your
code is not as buggy. Your code is hopefully
better-factored because two people are coming up with the
design versus just one, et cetera, et cetera. So
I would encourage you to dig deep into why
you're having these problems, and see if you can
address those problems. And then try it again, and,
and measure again. Thank you.
QUESTION: Just as a, kind of following, my big
impression is that, in many cases, the tasks are
relatively straight-forward, and so it just, you know, wouldn't
take a single person much longer to do them.
J.M.: Sure.
QUESTION: And then, so the other person is kind
of, you know, avoiding, helping avoid typos and, and,
you know, that sort of thing. But maybe not
adding as much value as they might be doing.
J.M.: Right. So we've, we've had clients decide that,
you know, they measure, you know, we use a
particular project management tool that lets us estimate stuff.
And it's called Pivotal Tracker. You don't have to
use it. Cards on a wall. Whatever works for
you. So we tend to estimate things sort of
on like a one to eight scale. And we've
had clients who have said, after they disengage with
us, you know, anything that's a zero or a
one, I guess I should have said zero to
eight, they choose not to pair on those things,
cause they find they don't get much value. That's,
that's great for them. But they have made a
rule that, well anything that's more of a, than
a zero to a one on an eight point
scale, that that must be paired.
And so then maybe you re-evaluate the twos and
the threes and then ah, looks like maybe the
threes, they have, they're, those are getting pretty buggy.
So let's bring pairing back into that. So that's
a strategy as well.
Let's go over here.
QUESTION: If you could clarify, I have another question,
but, if you could clarify just for a moment
that fifteen percent increase, was that compared to one
developer doing the task? Or was that compared to
the relative work that two developers would do, you
know, each individually, right? So, one developer doing a
task takes this much time. Two developers doing the
same task takes fifteen percent more time? But then
that other developer isn't doing any work, right? So
there's actually less benefit than might, might be-
J.M.: Right. So the, I believe it was against
a solo programmer-
QUESTION: Right.
J.M.: -working by themselves.
QUESTION: OK.
J.M.: But there, you know, but I, there were
lots of other measures that showed, you know benefit
of pair programming-
QUESTION: Sure.
J.M.: -above, you know, it sort of out, in
the opinion of the report, outweighed this, this particular
slow-down.
QUESTION: So I, I think that kind of plays
into my, my main question, which was how do
you quantify to other stake-holders, particularly in the business,
even other developers, and maybe measure the benefits of
pair programming? I'm trying to incorporate it into our
process more, but getting some resistance. We, we've given
it enough to like experiment with, but how do
we actually measure the benefits and say whether it's,
you know, working for us?
J.M.: That's a great question. Measuring the benefits and
selling it to management, or your team. Selling it
to anybody is I, I feel one of the
hardest things to do. And even when I've been
going over the empirical evidence, even the empirical evidence
has said, like, more studies need to be done.
More sort of metrics for measuring this, this stuff
needs to, need to be developed.
It's, it is really, really hard to sell it,
because the math is just too easy. One plus
one equals two. You just can't, like, fight that
math. It's going to be, take twice as long
and it's gonna be twice as expensive, right? And
why would anybody ever do that? And I think,
yeah, and in my experience, you, you know, I
could, I could, we could try to come up
with some metrics and we could look at, you
know, I could point you towards these empirical studies
and they have particular measures of how they measured,
you know, different kind of factors. And I, I
find that stuff it, it bounces off people. You're
like, ah, yeah, that's all neat. But you've heard
of one plus one equals two, right?
And I think that this is an unsatisfying answer
that I'm about to give you. There's a leap
of faith that needs to happen, and I think
you can kind of come back to like, let's
pretend we're in a world where we can still
do TDD. In a world where we did TDD,
that was a leap of faith, too. Because it's
like, that's twice as long. Why would you, you
can't test something you haven't written yet. And that's
gonna take twice as long. And I'm willing to
bet almost everybody in this room has had that
argument with somebody who doesn't practice, like, not just
TDD but any kind of testing. It's too slow
and it takes twice as long.
And, finally, you're spouting all this stuff when you're
talking about all the things that you, make almost,
I'm willing to bet everybody in this room, love
testing, to somebody, and it's just bouncing off and
it's just bouncing off. And finally you're just like,
ah, you just gotta, you gotta try it. You're
going to see the benefit, I swear. And then
finally they do, and usually you win them over.
But actually, and I'll turn this around, because I
know that there's lots of people in the audience
here who have been more on the sales side
of pair programming than, than I have. Has anybody,
would anybody like to comment on success stories they
have had selling management or clients of your consultants
on how they've addressed this issue? Anybody? Maybe in
this row here? Could I encourage anybody? Does anybody
have anything to say? I've got a mobile mic.
Ah, excellent sir. Don't break your ankle.
AUDIENCE MEMBER: Hello, hello.
J.M.: Does that work?
AUDIENCE MEMBER: So one the, is this working?
J.M.: Could I get this mic, this hand-held mic
on?
V.O.: It's on.
J.M.: Oh, OK.
AUDIENCE MEMBER: Hello.
J.M.: Excellent.
AUDIENCE MEMBER: That's better.
One of the easiest ways that I've found to,
to get pair programming into a team is to
talk about the benefits of bringing, increasing your ability
to absorb junior developers into your team. A lot
of, I'm from San Francisco. A lot of companies
in San Francisco are hiring their first junior developer.
Like, right now. And so, one, a lot of
discussions I've had recently have been along the lines
of, OK, so we're bringing on our first junior
developer. Everything we do has to change, because we
need to vocalize a lot more things that we
used to. And, so, what I tell them, oftentimes,
is like, OK, one of the ways you can
practice that, before the junior developer shows up, is
by pairing amongst yourselves. Getting used to this idea
of, like, vocalizing your thought process, understanding how you
talk about writing code with each other, and then
you can bring someone in who's in a very
different place, and you'll be better-equipped to talk to
them about it.
J.M.: Thanks a lot. Thank you so much.
Excellent. So, go ahead.
AUDIENCE MEMBER: I had two things to say. Part
of like, selling pair programming, like, for me, as
a developer, it's been really awesome, just cause it
forces you to get out of your own box
of thinking and see how other people think about
writing code and sort of, like, maybe you thought
this one practice of how to do something was
bad because you got bitten by it once, but
maybe you can be convinced that, oh, no that's
actually worth doing. It's a great way to like
just share knowledge about gems that someone found on
another project if you're coming into something.
And then, like, to the junior developer point, like
it's great cause you're there and you know, you
ask, have you seen this part of the code
yet? No? Then you go through and you explain,
like, everything about it, cause you, you know, have,
you write it and you can, or you understand
it, and so that helps bring them in more
than just sort of looking through all this code
that may not have comments or was written by
someone who left the company later. So those are
my, like, big selling points. Like, I think it's
made me much better and much more open minded
developer, and like, made it much easier for me
to collaborate, which yields, I think, like better code,
and like, you know, over all makes your, your
group better cause you're just better at collaborating and
sharing ideas. And it sort of tears down the
barriers of like worrying about, about bumping shoulders in
communication.
We'll get kind of heated, like you said, like
and we'll just get through it, and in the,
in the end come to an agreement on what
will hopefully be a better idea or revisit it
My question was kind of around pair rotation. So,
like, if you're working on, on a team in
an office or, we work with one of, we
work with the clients' developers separately, like remote pairing,
like we'll spin up an EC2 instance and we're
trying to sort of figure out, like, proper pair
rotations, so like, on a particular feature, two developers
won't be the only ones like, who work on
it, know it, and make, like, to some extent
make all the decisions. And I'm curious, like, what
your thoughts are on that, and like sort of,
what you have found to be a good way
of pair rotation, if, if you've practiced that at
all.
J.M.: Sure.
AUDIENCE MEMBER: And things like that.
J.M.: Yeah. Absolutely. So pair rotation. Super important. I
think, several things can help encourage pair rotation. So
one, yes, we do rotate pairs on a regular
basis. There are extremes to this. There's something called,
I've never done this, but it's been dubbed promiscuous
pairing. I don't know if anybody has heard of
this. And it's where you pair many times per
day, like, on a timer basically. And there's been
a little bit of evidence to show that that
can be very productive. It's also shown to be
disruptive and exhausting. So I think that, give it
a, give it a try, perhaps.
But for us, for practical purposes, what we tend
to do is, it, it ties into the art
of breaking down work. So we call our, the
stuff we're working on, we call them stories. And
we've gotten quite good at being able to break
down deliverable stories to small enough pieces. This is
all, in almost every case. To small enough pieces
that, ideally, our pair developers will be able to
get one or two of them done per day.
And a long story, we'll say a big story,
that's gonna take a long time, quote on quote
long, that might be several days. Two days, maybe.
Three days.
So what I'm not saying is, this is going
to take three weeks to do. Now, maybe there
is a giant track of features, a huge feature
set - the entire profile page rewrite. That might
be weeks of work. But getting that link photo
upload thing, just that small thing, that might be
a day's worth of work or less. And so
we tend to rotate pairs every day, if we
can, at our morning stand up meeting. And, because
ideally people will have completed one or two things
the previous day and they're, they're ready to move
on. And if they're not, and if they didn't
complete it, there's, like, just a little bit left,
and you could wrap it up with a new
pair the next day and, and go on from
there.
What will happen, sometimes, is that pairs will request
to stick, we call it. We're working on this
thing, it's really long. We have a lot of
context. We'd like to stick on this. OK, second,
you know, that's the next day. Cool. Then the,
you know, the third day comes around. Like, we
still. We're almost done. We'd like to stick. And
the whole team collectively is like, hmm. Maybe. OK.
Maybe. OK. Go ahead.
Fourth day rolls around. We're really almost done, I
swear. And then at that point, like we, as
a group, agree as a team collectively, like, we
should get somebody else in. Often, at that point,
the pair will say, one of us is gonna
swap out. You know, Bob's gonna stay on. Let's
get, who's available? Sally, you're available. Jump in. Fresh
pair of eyes. They're probably stuck. You need a
new perspective. And so we will force rotation that
way, too. And just maybe taking it a step
further, something that will often come up after this
is, yeah, we rotate very often, but it's kind
of like the same people, like. We're the same
people on the time and kind of the same
four people just kind of, like, go around and
around and around, what you can do to combat
that kind of a situation, where there's, there's rotation,
but it's not balanced amongst the entire team, is
you can just start tracking it. Just, you could
do a white board. Like, keeping track of who's
paired with who how many times, all the way
to, there's even a website called pair tricks, I
believe. Where you can sign up your company and,
and you can put all the pairs in and
it'll randomly assign people and do weighting based on
how long, how long it's been since they've paired
and things like that, but.
So you can do something like that, like, every,
or just keep track of it on a white
board or a Google doc or something like that.
K. Good questions.
AUDIENCE MEMBER: Kind of a follow-up to that.
H.M.: Sure.
AUDIENCE MEMBER: How do you combine that with, like,
sort of junior developers, like, sort of making sure
that they're not going through so much context-switching that
they're not really getting anything out of it, they're
just sort of starting a feature and then, like,
you know. So like, in our case, we'll start
something and it won't, won't be done in one
day, and then sort of, they'll switch and it's
just kind of like, well like, I'm kind of
like lost. Like I-
J.M.: Right. Right.
AUDIENCE MEMBER: I was barely beginning to grasp, like-
J.M.: Sure.
AUDIENCE MEMBER: -that part of the code that I
was working on.
J.M.: So I think just being flexible, you know,
just because it's nine o'clock the next day doesn't
mean that, you know, the judge comes in and,
you know, breaks everybody up or something like that.
And I think that if, if the team decides,
you know, hey, it seems like this junior developer,
they're three-quarters of the way, the, the senior and
junior developer, they're three-quarters of the way through this
task. They're trying to complete, yeah. Let them. Let
them complete the task. And, because they're gonna get
a lot of benefit out of seeing it from
beginning to end.
So don't be, I'm personally an advocate of just
kind of playing it by ear. Just kind of
seeing how it works out. Don't be so strict
that you're being too disruptive, but don't be so,
don't let people stick so long that you get
these little sort of knowledge cylos and ownership and
such. Great.
AUDIENCE MEMBER: Thank you.
J.M.: Sure.
AUDIENCE MEMBER: A few questions on, I guess, team
dynamics with pairing. This one's kind of a follow
onto this one.
J.M.: Sure.
AUDIENCE MEMBER: I guess I'll spit them all out.
J.M.: Go for it.
AUDIENCE MEMBER: Monopolize things a little.
One is, do you have any thoughts on, if
you have a group of, a spectrum of people
at different experience levels, are, can you talk about
sort of the pros and cons of going with,
like, senior senior, junior, junior, people at like levels,
or to go junior senior to get more mentoring.
Have you had any barriers with tools, where people
just would be incompatible, say one guy likes Vim
and one guy likes Sublime? And then, thirdly, do
you have any, any wisdom to share on adding
a test or QA person to a pair to
get that person involved early in what role a,
a QA engineer would play throughout a, a, working
on a story with a pair.
J.M.: OK. I may have to refer back to
you to remind me what all those are. But
I believe they were, experience level pairings, tool conflicts,
and adding, like, a QA or a support person
to the team.
So let's do, let's do experience level pairings. I,
I like, personally, I don't, I don't consider it
being a big deal to mix up almost any
kind of experience level pairs. Except the junior-junior situation.
I wouldn't just randomly, personally, do that. So the
obviously one is senior and junior. Those can be
great pairings, right. Just, especially for the junior person.
And that, maybe, a lot of people talk about
pairing and say, oh, you know, we pair when
we're wrapping somebody up. And they'll kind of use
that as the only excuse for pairing. You know,
we're wrapping up this junior person.
But, that can put a lot of burden on
the senior person. If they're always ramping somebody up.
You know, if they're, if you get a new
person every so often, then they're, if they're a
senior person they might feel like they're always wrapping
somebody up. I'm gonna encourage everybody to have the
attitude of, well, one, share, share the load. Like,
the junior person shouldn't just stick with the same
person all the time. And also have the attitude,
if you're a senior person, or have your senior
people have the attitude that, they can always learn
the junior person.
On the last project I was on, you know,
I've been doing software development for sixteen years. And
I was pairing with a guy who was fresh
out of college. And he didn't even have a
CS degree or anything. He was just, well, you
know, one of those smart people who just graduated
from college, and he was doing something that was
clearly way below his skill level. We're like, you
should probably do some programming. Here, get over here.
And, I learned something new from him every single
day. You know, and I, the supposed expert, and
everyday he's like, oh, did you know about this?
Whoa. No. That's really cool. I would usually write
it down. I kept trying to keep track of
the things I learned each day. And then people
at the same experience level, that's, that's great as
well. You do sometimes have to watch out for
people, especially senior, senior people, who maybe, let's say
they once had the word architect on their names.
Sometimes people are gonna be extremely opinionated and not
want to budge from ideas. It's something to watch
out for. People kind of, we call it thrashing.
Junior-junior. Should you ever pair junior people together? And
I think the answer is sometimes yes. Especially if
they've both been through multiple, been through multiple pair
rotations. They're kind of, maybe one of them has
kind of been on that, let's make up the
user, new user profile rewrite or something like that.
And that junior person has kind of bounced between
pairs, all kind of in that area. And they're
kind of getting pretty good at learning some stuff.
It might be good to swap in and have
a junior person who doesn't have any experience in
that area pair with this newbie but newbie with
a lot of context. And then you can really
help them exercise what it's like to have them
own something. You know, own's a bad word. But
whatever. You know what I mean.
Tre- you know, bringing this other person up to
speed. Transferring that context. And it, I've always found
it amazing how, when I feel like I don't
really know anything and I'm really relying on this
other person, and suddenly the person I'm relying on
kind of drops off, and I have to explain
it to somebody else, it really forces me, personally,
to dig deep, understand the problem much better. And
I almost always surprise myself, both in how much
I actually do know, and how much I don't
know.
So, once in awhile, having those junior people pair
up and, and yes, struggle, like, have problems. Have
to figure some stuff out, the way we all
used to have to do when we were working
by ourselves. OK. So that was a lot of
that stuff.
Tools. Wow. If you could see the email threads
go around at our company, these guys know. These
guys know. Key bindings. Tools. Vim versus RubyMine versus,
versus Sublime versus TextMate versus frikin' Decorak. I mean,
give me a break. Come on people.
Yeah. That, that's, that's, it's a, it can be
a huge struggle. And you can go to an
extreme, that I don't really know of anybody else
doing. Maybe some of you do this. I don't
know. But we pretty much standardize on a particular
kind of keybinding, and often an editor. It, it
evolves. It isn't like, the manager doesn't come down
and say, today we're a Vim company. The, the
team ends up, you know, adopting, and the people
who are kind of holding onto those other texts,
they inevitably kind of like, OK, fine. Fine, I'll
do it. And I did that, because I used
to work out of the San Francisco office. Now
I'm working out of the New York office. And
they use different tool sets. It just evolved that
way. And rather than stomp that out, we've let,
we've let it evolve. And it's been great.
My advice on that front would at least be
this. One, be open to learning new things. Two,
if you have your super awesome custom setup that's
just for you, and your own, your precious, Vim
bindings, don't stomp the defaults. Because maybe that person
who doesn't really know Vim very well, they might
at, or, or RubyMine or whatever your editor or
tool of choice is, they may not know your
thing. But they may know kind of enough of
the default settings, that they can kind of get
around and maybe, maybe they start adopting yours. Or
maybe they say, yeah, I don't really use that
key binding for this, I use it for something
else. And, and be open for that. But people
can sometimes be too closed minded about, you know,
they build this little ecosystem just for themselves, and,
and not want to, to change, and I encourage
people be open to change, but leave the defaults.
And be open to trying other stuff. But there's
no silver bullet unless you mandate, our office is
an X office and everybody just learn it.
OK. Integrating other people into the team. Like, QA
folks. And if you don't mind, I'll sort of
mutate that question into pairing across different disciplines, or
integrating anybody of any other discipline into the pairing
structure. I'm a big fan of that. Be it
a QA person, design people, design, you know, front
end design or visual design, designers. Even your product
owners, product managers, whatever you want to call them.
I think that that's great. One, it builds up
a lot of empathy. Just from a person to
person point of view. Two, it can be super
practical, especially with, say, visual design. And, and actually
QA as well. Like, that last mile, I've always
found, of say a visual design, where, you know,
you've pretty much got all the assets in. Let's
say you're building a web page. Got all the
assets in and you're, you're tweaking the css, and
all the stuff that came from visual design, it's
pretty good right now, but you know that field,
or that area of the page that looked great
with lorem ipsum, that only had like twenty-five characters.
If somebody puts in a thousand characters, and they
can, the whole thing goes blah. Right? Crazy.
Getting visual design in to say, hey, like, the,
the last bit, let's just sit here and work
on this. And then you can just, especially if
you're using, like, web, if you're doing web development,
and you can literally tweak it right there on
the screen together. That could be super powerful. And
I've even been in situations where you'll, they were
so good that they were working on this thing
and were like, moving stuff around. They're like, ah,
now that we've moved this from here to here,
those icons look terrible. Hold on, and they're like,
somehow spew out an icon out of their fingertips.
And they're like, OK, now pull in this icon.
And wow, it's just. It's like the most rapid
changing finalization wrapping up of, of something I've ever
worked in, and that was one of the best
experiences I've ever had pairing was with this person
who was not technically a software developer.
QA, as well. I think, like, a really good
QA person is worth their weight in, in gold.
I think if anybody here is kind of tied
into the capital A Agile community, or at least
extreme programming, you know, somehow this strange notion came
up that, like, you don't need QA. We've got
tests for that. And it's like, nah. Those are
two different things. So, integrating QA people can be
really good, especially if you're, if they're in a
mode of, maybe you've got a big release coming
up, and they're hammering the site and finding all
these bugs, and you know, pairing with them as
you're fixing the bugs, as they're like pressing, you
know, trying all their different attacks on the system.
They're saying, OK, well you fixed that one, but
that makes me think of this other thing. Oh,
look. It's broken. OK. Try this. Try this. And
just, like, just kind of, you know, purpose, purposeful
pairing when it's needed can be super valuable as
well.
Now I haven't, say, just, you know, like, where,
hey, we're making an android application and today I'm
doing some, you know, a big feature, and it
just pair with a QA person instead of another
software developer, in the middle or at the beginning
of the development process. I haven't done that. But
give it a shot.
All right. That was three. I hope they were
good. Cool.
AUDIENCE MEMBER: Quick comment about the cross-tooling,
or cross-editor,
there's a tool called Floobits - F-L-O-O bits, which
lets your Vim people work with your Emacs people,
and the idea is, like, one of them's got
their computer and the other one's got their computer,
and they're each running the same damn thing, but
it's all synced and good and there's a fall
back, which is like a diff shipper for other
apps. So it's-
J.M.: OK. Cool. Floobits.
AUDIENCE MEMBER: Yeah.
J.M.: I've heard of it. I haven't, well, I
did, I technically did try it when it was
early. And it didn't really work very well, but
I'm gonna try it again, cause people-
AUDIENCE MEMBER: Yeah. It's, it's still-
AUDIENCE MEMBER: -fairly early, I think. But the promise
is there and more plugins would probably help it.
But.
J.M.: Excellent.
AUDIENCE MEMBER: So, a couple questions. One, when you're
driving, how much vocalization do you do to the
other person explaining your thoughts? And the other one
is, when you've got a senior developer paired with
a junior developer, there's, you know, I frequently find,
I'm the senior one on this side. And there's,
I know I need to let them work through
it, but at the same time I want to
rip it out of their hands and type it,
you know, it's like, how-
J.M.: It's hard.
AUDIENCE MEMBER: -what tools do you, techniques do you
use to combat that and work with that and
help them to learn?
J.M.: Sure. So, the first question was. Wow, this
is really terrible. What was the first question again?
AUDIENCE MEMBER: Vocalization.
J.M.: Vocalization. Yes. Ironically. So vocalization and then being
a keyboard hog, right? I'm that, like, I'll, I'll,
I'll take on a trip with that one. Cause
I'm, I can be that way.
Or, at least, letting new people struggle through something
when you already know the answer, for example.
Vocalization. I vocalize a lot. Especially because I do
remote pair programming. And I lose a lot of
the, a lot of the visual cues and physical
cues that you might pick up sitting side-by-side. I
lose a lot of those. So, when my whole
view into somebody is from, say, the neck up,
you know, or like the midsection up, it's harder
for me to say, see anybody's hands. I almost
never see anybody's hands. So are they reaching for
the keyboard right now? Are they reaching for the
mouse? Are their hands on their laps? You know,
what are they about - are they about to
do something? I don't really know. Well like, when
you pair side by side, and out of, you
know, right now I can still kind of see
you over there. And if I see this hand
going out then that's a cue for me to
be like, oh, it looks like they want to
do something. I wasn't in the middle of doing
something, so I'll kind of back off.
So, maybe a little bit less verbalization, consciously verbalizing,
anyway. But, when I'm remote, I'm constantly saying things
like, I'm gonna grab the mouse. Can I look
at this? Would you like to drive? Do you
mind if I drive? All that kind of stuff.
And, you know, to the point where, I've pair
programmed with, remote paired with people, and they've told
me later that they, they found themselves doing that
much more when they were pairing side by side,
and they felt it made them a better programmer,
or a better pair anyway, because they found themselves
being more vocal even when they were in person.
Which was, which I thought was great.
AUDIENCE MEMBER: What about vocalizing, like, OK, now I'm
making this case statement because of such and such,
do you go to that level, or?
J.M.: Yeah. We, I will sometimes go to that
level if, if I feel like that it's needed.
Often, yeah, I'm kind of like, constantly talking. And
I've recorded myself doing it, so I could show,
like, for a presentation or something like that. I
actually kind of hate listening to myself do all
that. But I, I think it's valuable. And I
find that often, my pair will in, sort of
call me out when I'm not doing that. You
know, I'll be kind of, like, in a zone
and kind of going and like the thoughts are
coming out and they'll say, like, well, what, what,
what do you, what are you, what are you
doing? And I'll realize, ooh, I haven't, I'll realize
I haven't been, I haven't been saying anything. I
haven't been vocalizing it. And so, you know, that,
I think, is also kind of a tick mark
in the be more vocal column.
Were those the two questions?
AUDIENCE MEMBER: Junior developers.
J.M.: Junior developers. My god.
AUDIENCE MEMBER: Letting them-
J.M.: What's happening to me?
AUDIENCE MEMBER: -work through the problem when you know
it.
J.M.: Yes. So, techniques for trying to let the
junior people drive more when you're more senior. It's
certainly hard. Some people never get it. Some people,
it can be especially bad if you have a
person who is, let's say, naturally, or professionally more
passive, and somebody who is naturally or professionally more
assertive. Tricks for that are just both sides trying
to be more honest and vocal about things.
Like, oh, in saying, like, hey, do you mind
if I drive now? Would you like to drive?
I have physically sat on my hands. Like, underneath
my thighs. And when I feel myself, like, pull
my hand out, I'm like, ah, get it back
in there. Sit down. And ping pong pairing, if
people haven't heard of that, is a great sort
of structure to, to implement, to kind of enforce
a rigidity in the bounce back and forth. So,
again, this is testing, test-driven development. So if you're
doing test-driven development, you can have one person write
a failing test, and the other person implement the
code to make it pass. And then they, the
second person, writes a failing test, and the other
person writes the code to make it pass. And
you can sort of enforce that rigidity while you
need it.
And it was, it can actually be a not-so-subtle
cue, that somebody is being a keyboard hog. And
I encourage people to do this if they maybe
don't want to be confrontational about, like, gimme the
damn keyboard. But if somebody's kind of going, or
let's say, if you're going along, and your coding
and everything is great, and then your pair says,
hey, how about if we do some ping pong?
Like, oh. Hmm. Maybe I'm driving too much. Or
you can, you can say, like, oh, let's ping
pong this one. What do you say? Like, that
can be a, maybe a less assertive way of
saying let's balance it out.
Trace, you have something to say?
AUDIENCE MEMBER: Oh, just, I'm really glad you mentioned.
Thanks. I'm really glad you mentioned ping pong as
a, a technique to help manage that. When I
first started pairing, it was definitely something that was
very hard for me to do, and I had
to do the same thing. I sat on my
hands for three weeks. I, I saw people like,
you know, when I sat side by side with
someone, I'll see their hands come near the keyboard,
and my will always leave. Or if their hands
leave the keyboard, I'm, OK. It's my time to
speak. And I'll raise them up.
So I've heard of some of the other paradigms,
like driver-navigator, for example. What are some of the
other pairing patterns in addition to ping pong and
when might they be good to use, and what
are their names?
J.M.: Oh, let's see. Yeah, driver-navigator is sort of
the, the canonical pairing structure people think about, where
one person is literally driving and one person is
literally saying, oh, OK, well you missed this and,
hey, maybe, you know, let's use an if and
not an unless there, and that kind of a
thing. And they're kind of also kind of looking
over the rest of the code and say, like,
hey, how about we extract, you know, finish that
up, but let's extract that as a method next.
And kind of a thing.
As far as, those, that's the one I'm most
familiar with. The, and, and that can be great.
I think that's kind of the natural mode of
most pairings. Is like, one person is like actively
engaged and, and driving, the other one, or, actively
engaged in typing, the other person is, is doing
more navigating. I think that the challenge can be
figuring out when, when to switch. Testing really helps
for that. And if you don't do testing, let's
say you don't, then maybe you can use some
other kind of bounds. Like, you know, you just
wrote this method. OK, now the next guy writes
the next method. Or, you know, you're doing a
bunch of refactoring and extracting classes and, and methods
or something like that, then, you know, you bounce
back and forth between the thing you're extracting, for
example.
OK. We gotta couple minutes. One minute actually.
AUDIENCE MEMBER: The most useful thing that I ever
did for stopping myself from over driving was getting
a chess clock. So that we could actually see
how much time I spent driving. And so when
I'm looking at the clock and I'm forty-five minutes
ahead, it, it's very helpful.
J.M.: That is excellent.
AUDIENCE MEMBER: And another technique is to just turn
your keyboard over if you have two keyboards. Just
make it so you can't type.
J.M.: That's a really good one, too.
OK. Forty seconds, go.
AUDIENCE MEMBER: Based on your experience, can you share
what you consider to be good habits and effective
habits in pair programming? And then can you, are
there, are there pitfalls that people tend to fall
into that, are there commonalities that you see in,
in?
J.M.: Sure. In twenty-five seconds I will, I'll put
it this way. I think it's, the main thing
is to remember that we're all human, and that
it's not really about technology or, really, about programming,
per se. It's about being patient and having a
good attitude and building trust. So as long as
we all have a good attitude with each other,
trust each other, are patient with each other as
we're all learning, I think that's really the key
to pair programming. You can apply that to almost
any situation, but especially this very strange and extreme
version of software development. I hope that helps.
That's it. We're out of time. Like I said,
thank you.