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:
Personal hygiene.
EDIT: This is a serious answer. Consider how effective you would be otherwise.
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.
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).
Get dual keyboards and mice, stops you getting in each others personal space when sitting beside each other.
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)
http://www.realsearchgroup.com/pairlearning/educators.php#ppvideo
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!
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
Share equally keyboard time, nothing worse than a keyboard hogger.
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:
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 :)
Put some serious effort into preparing a suitable physical environment. It's no use if you can't easily:
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.
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'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.
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.
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.
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.
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!
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.
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.
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.
Start by getting a chair [1]. Then proceed to building a corresponding desk [2].
[1] http://www.cenqua.com/pairon/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
Good luck. :)
Give one person the mouse and the other the keyboard, and swap every now and then. Works well for me.
Have a look at this blogpost: Pair Programming [1]
[1] http://www.agile42.com/cms/blog/2010/09/9/pair-programming-why-and-when/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: http://agileotter.blogspot.com/2011/01/pairing-competence-and-recognition.html
Consider a shared understanding like this: http://agileinaflash.blogspot.com/2009/02/abcs-of-pair-programming.html
Watch out for pair programming smells: http://agileinaflash.blogspot.com/2009/02/pair-programming-smells.html
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.
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?)
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
See http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=2058 [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.
[1] http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=2058We 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.
From a logistics perspective
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.
[1] http://www.codingmonkeys.de/subethaedit/