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.