Stack OverflowGetting Started with Pair Programming
[+44] [31] Rob Cooper
[2008-09-26 08:02:52]
[ agile getting-started pair-programming ]

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?

[+23] [2008-09-26 08:06:54] Ed Guiness

Personal hygiene.

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

(1) Make sure you have minty fresh breath! - Craig Angus
(2) Don't take your shoes off at someone elses desk. - Phil Wright
OK, this is funny, but can we please stop upvoting it, its not really a good answer ;) We are both hygenic gents :P - Rob Cooper
Yeah I know its a serious answer, but lets base this on the assumption that we are ok talking and sitting close proximity since we want to TRY pair programming in the first place! ;) - Rob Cooper
(3) I wanted to write EXACTLY THE SAME before reading this answer. Shower! Have fresh breath! And I also planned to add "This is not a joke". - Thorsten79
(2) It's getting upvoted because it's important, maybe not for your specific scenario, but in general it is. - Erik Forbes
[+19] [2008-09-26 08:16:44] Nenad

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.

The equal-time is a very good point, but you don't want to go breaking the natural flow of someone's work just because it's time to swap, it needs some judgement. I found that it helped us to break the work into obvious little sections, a function or procedure each at a time, for instance. - robsoft
[+10] [2008-11-30 13:40:47] Arjan Einbu

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).

(4) Anything to prevent those fingerprints... :) - Sakkle
[+9] [2008-09-26 08:06:03] Craig Angus

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

(1) This is a good answer, and sometimes it can work as easily as having a PS/2 and USB mouse and keyboard plugged in at the same time, easy to set up. - Grundlefleck
This goes contrary to the main tenet of pair programming - the pair of you are doing it together. Isn't two keyboards and two mice just "sitting very close to each other programming"? - Andrew Harmel-Law
(1) Both Keyboards and mice are connected to the same PC It has various advantages - Less hogging of the keyboard - Choose your own keyboard and mouse - Better ergonomics, when the keyboard is in the middle and you both have to lean towards the middle - its more hygienic too, Less spreading of colds! - Craig Angus
(1) why stop at keyboards and mice? 2 (or 4) monitors in clone mode, means you don't have to huddle (if you don't want to) while you both watch the same screen real estate - geocoin
(3) Not tangible enough. You need to be able to jab your finger at the relevant place. Also, have a whiteboard nearby. - slim
[+7] [2008-10-07 15:57:08] Adrian Wible [ACCEPTED]

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)

Updated link (and now there are a few more videos there too)

DUDE! Awesome link! Made me chuckle, thanks for sharing! - Rob Cooper
REAL difficult selecting an answer for this, there are so many good answers! I selected this since I think the video is a great intro for n00bs such as myself :) thanks for sharing! - Rob Cooper
the video is down. if somebody could provide an updated url, that would be neat. :) - elementz
Apparently the url changed ... and there seem to be a few more videos now. Go here to see the list: - Adrian Wible
[+6] [2008-09-26 08:25:50] robsoft

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!

[+6] [2008-09-26 10:21:17] community_owned

Check out these links:

Pair programming TDD Game

Another pair programming game

Pair programming do's and don't's

Hey! I resemble that first link. :) - Brad Wilson
[+5] [2008-09-26 08:08:29] Paul Whelan

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

One thing worse than a hog is a smelly hog. - Ed Guiness
hehe I guess so - Paul Whelan
[+5] [2008-09-26 12:13:06] Alexander Morland

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 :)

[+4] [2008-09-26 10:27:55] slim

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.

[+4] [2008-09-28 07:03:18] Jörg W Mittag

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 [1]. 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
[1] http://StickyMinds.Com/s.asp?F=S9101_COL_2

[+3] [2008-09-26 11:14:42] brien

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.

[+2] [2008-09-26 13:10:55] Ryan Thames

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.

[+2] [2008-09-26 10:07:00] boutta

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.

[+1] [2008-09-26 11:11:19] Andrew Harmel-Law

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.

[+1] [2008-09-26 12:43:43] pmlarocque

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!

[+1] [2008-09-26 11:51:53] slicedlime

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.

[+1] [2008-09-26 13:20:50] reefnet_alex

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.

[+1] [2008-09-26 13:33:12] TraumaPony

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.

[+1] [2009-06-29 22:43:04] pmf

Start by getting a chair [1]. Then proceed to building a corresponding desk [2].


[+1] [2010-01-29 11:46:27] John Nolan

I've recently started remote pair programming. I've blogged [1] 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


[+1] [2008-10-01 02:34:06] Zee JollyRoger
  • 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. :)

[0] [2010-01-29 11:57:05] cjk

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

[0] [2010-09-20 08:43:31] Doro

Have a look at this blogpost: Pair Programming [1]


[0] [2011-02-18 20:51:46] Tim Ottinger

Try some self-improvement strategies: "Eat the Rich" - pair with someone who knows something you want to learn. "Attack the Poor" - use pairing to mentor the less knowledgeable in an area where you are strong. See:

Consider a shared understanding like this:

Watch out for pair programming smells:

Also, there is some help in the AgileInAFlash deck on what to do when not pair-programming. We'll have to see if we can't get that copied up on the blog.

[0] [2008-10-01 02:26:15] trenton

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?)

[0] [2008-09-26 11:58:11] Paul Shannon

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

[0] [2008-09-26 11:26:48] Roman Odaisky

See [1].

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.


[0] [2008-09-26 11:42:06] akauppi

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.

[0] [2008-09-26 13:15:01] Mark Lindell

From a logistics perspective

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

[0] [2008-09-26 08:25:25] gizmo

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 [1] which runs only on OS X, but there are others. For instance, there is an Eclipse Plugin for collaborative work [2].

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.