For a while, we had a couple people who really liked pair programming at work. Our desks really, really weren't fit for that. They went through a lot of things and finally settled on 1 person having the work computer, and the second remoting into it. They would sit at their own desks, which were close enough to talk, if loudly.
Other than a few latency issues, it seemed to work pretty well for them.
This setup, though, would have been MUCH preferred.
As for the cost of the second monitor... Most non-pair places buy 2 computers AND 2 monitors... Our stations at work even have 2 monitors per computer, with only 1 developer at it.
I think the cost of the second monitor is a very small price to pay for efficiency.
I'm not sure I understand the concept of pair programming. It seems to me that the keyboard clashes, while able to be avoided, would be rather annoying and be less efficient. I could see collaborative editors working out much better.What does the second programmer do while the first one is writing code
One vision of pair programming is to explore on your own and save the technique of pair programming for the code that you are going to keep. Keep meaning put into production, with the implication that 6 months later some-one is going to be trying to debug it or extend it.
In this vision the two person aspect is inescapable. The issue is when does the second person say "Whoa! Dude, that is such an obscure way of writing that, no-one will ever understand that piece of code." Do they say it when you have just typed it in and can be persuaded to play about a bit, searching for consensus on what makes for clear code. Or do they say it when it is too late?
Don't measure only your productivity - measure the team. When you pair with someone with a different skill-set, some learning also happens.
A good analogy is with sports. In a good team, every player knows what the other is doing, not because they can observe each other, but because they know each other so well they can predict what will happen in the field.
I've never tried pair programming, and I'm not convinced it would be a good idea for most programmers out there. I like to be able to think alone, and sit and reflect upon things, then go back into discussion with my colleagues either via "real life conversation" or via GTalk or e-mail.
I'd be willing to check it out for the sake of not rejecting it without cause. However, finding a co-programmer that is a correct match seems to be the biggest challenge.
PS It's good to see that your workers also have decent chairs, and not just gymballs. :-)
Seems like the tables don't need to be so deep, which would help use less space. Maybe not, though,
I do something similar when I'm pairing, but we just sit on opposite sides of a conference room table. The offset is key so you're not constantly leaning over to see the other person.
Hey Josh, what if I want to turn my head to the right to look at my pair? One of the things I need ergonomically is to even out the twists in my spine. Seems at a place like Pivotal you might want to encourage people to do the same.
Switching sides is good when you're sitting side-by-side. But I haven't noticed that there's enough neck twisting in the tete-a-tete configuration for that to be an issue.
Sometimes both programmers just keep using their favorite editors.
At my last job, we had a more typical pairing setup with one machine (27" imac) in the middle of two programmers. When I paired with a non-Emacs user, we'd put Emacs on my half of the screen and their editor (usually Vim, occasionally Textmate) on their half.
The only caveat is that you have to make sure your editor will refresh files when they change on disk. That way, when your pair saves a file, your editor reflects the changes.
Textmate does this automatically; in Emacs, you may have to put
(global-auto-revert-mode 1)
in your init.el, and there's some Vim setting you can tweak to get the same behavior.
The main downside is that you can only fit half as much code on the screen, but this can be mitigated by using a sufficiently large screen. In my experience, a 27" display is sufficiently large and a 24" is pretty good, but anything smaller starts to feel cramped.
I've used SubEthaEdit for pair programming in the past, and it was very successful and awesome. I was hosting it as such I was not aware of any latency, but my partner never really complained about it.
It also provided both of us with the ability to see the others changes.
I've not tried pair programming using collaborative editor but I've done sessions of requirements gathering with teams using EtherPad (I guess now it would be Google Docs given Etherpad was rolled into Google Docs).
It's fun and almost LAN game like in terms of having everyone create stub items, then others go in and fill them out, then someone else goes in and further adds to that given item, etc etc.
I can't describe how helpful this is for some of the open source projects that I contribute too. Sometimes it's hard enough getting folks to review patches, etc, but getting people to write docs is like pulling teeth at times. This makes it way easier to tweet or announce in IRC that a doc is being edited and in no time you can have 4-5 people working on it and it's finished in a fraction of the time.
BTW, Etherpad was released as an open source project (https://github.com/ether/pad seems to be where the development lives) as part of the acquisition and there are tons of clones out there if you still want to use something simply with no sign-in, etc.
With Emacs you can open a window (frame, em Emacs-ese) on another display. If both run X, you can make that display be your colleague's. The new window responds to keyboard and mouse activity from both workstations and both share the same editing buffer.
javery and I basically pair program during our TekPub recordings, using SharedView and Skype. The hosting SharedView user has asymmetrically better control of the editor, but it still works out great for us.
Not quite the same as a collaborative editor, but similar.
For a while, we had a couple people who really liked pair programming at work. Our desks really, really weren't fit for that. They went through a lot of things and finally settled on 1 person having the work computer, and the second remoting into it. They would sit at their own desks, which were close enough to talk, if loudly.
Other than a few latency issues, it seemed to work pretty well for them.
This setup, though, would have been MUCH preferred.
As for the cost of the second monitor... Most non-pair places buy 2 computers AND 2 monitors... Our stations at work even have 2 monitors per computer, with only 1 developer at it.
I think the cost of the second monitor is a very small price to pay for efficiency.