Mirrored display face-to-face pair programming setup | Hacker News Reader

Mirrored display face-to-face pair programming setup

pivotallabs.com

59 pointsjoshsusser24 comments

I like it.

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

You write code together. Typing is a minor part of creating software.

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?

Am I the only one here who hates the very idea of pair programming?

This may actually be a symptom of hating your co-workers.

There are people I like to pair with and people I am not as productive when paired with.

Try to pair with someone you like.

I prefer to discuss the design with co-workers and then work on my own. I'm more efficient that way.

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.

Has anyone ever tried pair programming with a collaborative editor? EG: gobby.

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.

Check out: http://piratepad.net/ep/search or http://typewith.me/

Good question. In general, what happens to this setup when two programmers use different editors, say vim/Emacs/TextMate?

It sucks. I just started a new job with lots of pair programming and all vim users. Struggle.

Yeah, I use vim too. I was thinking they'd just pair off vim and Emacs people with their own kind.

Quit complaining. You could have ended inside a Visual Studio shop...

See? I could be much worse.

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.

We actually require Emacs at work, but that's because we're all pairing remotely over SSH and we're all lisp hackers anyway.

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.

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.

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.

Reply on news.ycombinator.com