Getting Started with Pair Programming

Question

I found out yesterday that due to demands from the powers that be, I am being pulled from my current project to help out a colleague with some work.

Now, he is a great guy, and while it sucks I will have to put my little baby down, I am looking forward to working with him.

We have both previously expressed an interest in pair programming, but it is completely new to both of us, so I was wondering:

Those that pair program, what advice would you give to someone getting started with it?

Answer 1

Get dual keyboards and mice, stops you getting in each others personal space when sitting beside each other.

Answer 2

Personal hygiene.

EDIT: This is a serious answer. Consider how effective you would be otherwise.

Answer 3

Share equally keyboard time, nothing worse than a keyboard hogger.

Answer 4

Pair programming means that while your partner is programming, he/she has to explain to you what he/she wants to achieve, and your job is to understand, ask questions and eventually provide a brilliant ideas. After a while, you have to switch the roles.

Very important is to provide approximately the same time slots for both of you, otherwise someone will start feeling as obsolete, not important or something worse.

Answer 5

Well, it depends on how nervous both of you are, but if you're of those who'll start making jumps on its chair while the other's coding, being a "passive" reviewer will make you crazy.

If so, I would better suggest you to take your own computer, sit near the other guy and use an editor that support collaborative work. The first that came in mind is SubEthaEdit which runs only on OS X, but there are others. For instance, there is an Eclipse Plugin for collaborative work.

By the way, the most important is to talk to each other (that's why being close to each other is SO important). Define a set of rules from the start (coding standard, test first, YAGNI, ...), then adjust them if needed.

Answer 6

While gentle banter is to be encouraged, it's counter-productive to spend the day arguing about comment-styles, tab/space formatting and the way you use {},begin/end (or equivalent in your language of choice).

I pair-programmed (in Delphi) with a guy for a few months, many years ago, and one night he ran a homebrew 'code formatter' on my code because he didn't like the way I laid-out stuff (capitalisation, spacing etc). In the end, the back & forth game between us over this was as entertaining and interesting as the actual job itself, and it really broke the ice between us and helped us to get along, but in fairness it wasn't very professional or productive (at first, anyway)

One serious tip, always turn up with an open mind and a willingness to try things a different way. It doesn't matter which one of you is the more senior, or experienced, or 'master' programmer - if you don't both get something out of the exercise then it's a wasted opportunity.

And all being well the company will get better quality, inherently-peer-reviewed code, as a by-product!

Answer 7

I can support most of the answers given before mine.

But I'd like to stress one point: the guy in front of the keyboard needs to explain a lot what he's doing or what he's thinking, or the one sitting next to the keyboard will feel left alone. But if the explanation comes then there is a good chance that a discussion will sprout about how to get to the goal. And that's what is actually meant to happen (imho). And the guy next to the keyboard needs to talk to the programmer if he thinks something could be done better.

Answer 8

Check out these links:

Pair programming TDD Game http://www.peterprovost.org/blog/post/The-Pair-Programming-TDD-Game.aspx

Another pair programming game http://xp123.com/g4p/0104c/index.shtml

Pair programming do's and don't's http://www.developer.com/lang/article.php/3652636

Answer 9

Put some serious effort into preparing a suitable physical environment. It's no use if you can't easily:

• Swap roles ("hey, let me type a while")
• Read the screen while you're not controlling
• Point at the screen while you're not controlling

Depending on your starting point, this might involve some serious furniture moving.

Put your fastidious hat on. One of the benefits of pair programming is to keep each other honest when it comes to test-driven development and so on. Don't end up colluding to cut corners.

Answer 10

You need to be compatible personality-wise. Otherwise you'll just slow things down rather than gaining the hoped-for benefits. Remember, Pair Programming is about getting the fastest feedback possible. Faster than Unit Tests, and faster than CI. If you're not getting feedback, but rather constant sniping, then perhaps you need another partner.

That said, you should try and get on with the people you pair with. "We constantly disagree" needn't be a reason to fail. A good way to get into it slowly and build trust and respect is pair debugging. Two heads are always better than one when hunting a really tough bug.

Answer 11

It's best to work at a desk where you can both sit side-by-side. I did some pair programming in "corner" cubicles where the keyboard and monitor are at the angle of an L-shaped desk, and that made things much more difficult.

Answer 12

See http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=2058.

My own opinion is that the most important aspect is not to allow one partner to dominate his colleague, that ruins the entire purpose of PP. Both must feel completely free pointing out errors, proposing suggestions and asking questions.

Answer 13

We have both previously expressed an interest in pair programming,

This itself is essential; that you have the attitude to pull it through.

My experience is that PP is rather tiresome; like running intensive marathon instead of casual jogging. Don't expect to be able to do it full 6-8 hours. I'd do 1-2 hour PP and then assign things for individual work for the time in between such sessions. PP is productive, though, just the other side of the coin I guess.

Answer 14

What I used to do on a previous project was not to enforce pair programming, but to open for it. We'd code away at our own pieces of the project doing the mundane and the ordinary, and then once in a while we'd stop and have a long discussion of architecture or such.

Every so often one of us would end up with something tricky, and we'd naturally end up pair programming for a while through the difficult segments. I find that one of the most useful part of the exercise is that it forces you to explain what you're doing, and in order to make someone understand it you'll have to straighten out the concepts in your own head first.

This also applies to a less strict form of pair programming, which is simply a form of reviewing... sit as if you'd be pair programming and let him guide you through the code (that he's already written), or do pair debugging.

If you're just starting out with pair programming and he knows the project, then you have a perfect opportunity to let him do the programming while working on old code -- he can explain the thought behind it to you and help you understand it. When it comes to writing new code, you can take the coding position instead and explain your views on things to him. This both lets you learn the codebase and lets him learn from your way of thinking.

Answer 15

We pair program most of the time, but not for 6-8 hours a day, usually for stints of 3. If your team can be enlarged too "pair swapping" helps as you work with different people and everyone gets a view of every part of the project.

We work on the TDD adage of red, green refactor and usually swap "drivers" (the person doing the keyboard work) at the end of each cycle, or to turn it into a version of the TDD game, at the end of each part of the cycle - one person writes a test, the other person satisfies it, the first person refactors it, then the second person writes a test etc etc

Answer 16

Me and a colleague have been doing pair coding for a while, but recently we started pair developing. Whats the difference you ask? Well before we did this: one codes, the other sits next to him and waits for a problem to arise. Recently we coded a small feature together and we used this workflow:

1. Quick and loose brainstorm
2. Implementation discussion, orally agree on implementation
3. Wrote an empty class, defining the public methods and variables.
4. Wrote code documentation for these methods.
5. Implementation cycles:
   1. One writes the simplest unit test, while
   2. The other implements the class to pass those tests.
6. Gradually increase complexity while repeating step 5 until the tests cover all eventuallites and all tests pass.

Of course we helped eachother out continuously during step 5, but we didnt always sit next to eachother impatiently. Leaving your partner alone to concentrate is sometimes very important. And having tests to write while doing this is both very usefull gives you something to do.

Good luck :)

Answer 17

Be open-minded, and have the will to make compromise, or you'll waste too much time argumenting that looping with a "for" instead of a "for each" is more effective ( just a naive exemple here ).

There no secret, just do it the way you feel it!

Answer 18

Don't be afraid to ask questions. In other words, don't just sit there and not say anything. Ask questions if you don't understand something, it's only natural that you wouldn't understand something someone else is doing, you're not a mind reader after all. So if you have a question don't be too afraid of looking dumb, it's better just to ask.

Also, don't make fun of your pair-programming partner if they ask questions you think are obvious.

Answer 19

From a logistics perspective

• Dual keybaords/mice
• Timer to track pair switching (We used 20 minutes each)

Answer 20

One of the more difficult things to cope with at first is the differences between peoples abilities and the contributions they bring to the mix while pair programming.

I've often started pair programming almost in a mentor capacity, and I think this is quite common. It doesn't take a lot of working together like this however, before the person learning gets up to speed and starts contributing equally.

So, even if it feels a little uneven at first, stick with it for a few sessions.

Pair-programmed work is generally more robust and well thought out, and of course it's a great advantage having more than one person on the team understand the code that's been written.

Answer 21

Increase your font size, so the other person doesn't have to be as close. Also, get a big (or even second) monitor. There's no point in two people leaning in to read the text on a tiny screen.

Answer 22

In several other answers, time-tracking (basically using a stopwatch) was mentioned as a solution to one pair hogging the keyboard or dominating the session.

An alternative, and extremely cool, solution, is ping-pong pairing. It's literally like ping-pong: A "serves the ball" by writing the failing unit test. Now the ball is on B's side of the table, and B has to accept the ball (by making the test pass) and return it (by writing another test). Then A implements it, writes another test and then B implements it, and so on.

This can turn into a friendly but still competitive game, which has several benefits:

• it keeps concentration up, fun in, and boredom out
• the competitive nature leads to very robust tests, because one pair constantly tries to break the other's code
• the competitive nature leads to very simple designs, because one pair tries to impress the other with the most simple, most expressive code; also, they don't want to risk failing tests due to high coupling
• it distributes the time naturally between both pairs; even if one pair is slower than the other, both will have written roughly the same number of tests, the same number of features and the same amount of code, even if one took more time to do that

Answer 23

Consider yourself lucky that those "powers that be" support this. Usually it a battle to get management to allow you to do it at all!

Dual keyboards and mice can help... only if you both have the same IDE on the same OS and the same keybindings. I prefer screen sharing (VNC works great and is cross platform) since you both use the tools that you prefer. You can easily share code by committing to your branch. (You are on a developer branch, right?)

Answer 24

• Be supportive and encouraging.
• Don't hog the keyboard to yourself.
• Make sure the other pair-programmer has time to code, possibly more than you.
• If he/she makes a mistake, give them hints as to what is wrong.
• Always reflect and review code. Talk intensively about what is going on. Make sure you both understand what is going on.

Good luck. :)

Answer 25

Here's a video that Laurie Williams at North Carolina State University put together on pairing. Deals with a wide range of questions/issues (my favorite - take a shower on occasion)

http://agile.csc.ncsu.edu/pairlearning/educators.php#ppvideo

Answer 26

Turning on line numbers makes it easier to "sit in the back seat" as you can more easily communicate where. (And no greasy fingerprints on the screen).

Answer 27

Start by getting a chair. Then proceed to building a corresponding desk.

Answer 28

I've recently started remote pair programming. I've blogged about it but here are the bullet points

Remote Pair Recipe Equipment

* IDE of choice - (helps if these match)
* Git - (or other DVCS)
* GitHub Account - (or other hosted service)
* Skype/GTalk/Live Messenger - for Audio Comms
* MS SharedView - see what the other pair is doing

MS SharedView deserves a special mention here as it worked extremely well for screen sharing.

Check your setup
Have a plan
Don't be scared to critique
Don't be offensive either
Swap driver-navigator often
Embrace your differences
Take breaks

Answer 29

Give one person the mouse and the other the keyboard, and swap every now and then. Works well for me.

Answer 30

Have a look at this blogpost: Pair Programming