Tom Dale and Yehuda Katz's Pairing Setup

Given a sufficiently large monitor, it's fine. I (Emacs user) routinely pair with a Vim-using coworker; we just put Emacs on one half of the screen and Vim on the other.

The only thing you need after that is for both editors to automatically refresh when a file changes on disk. With Emacs, you can get that with "(global-auto-revert-mode 1)" in your init.el. You can make Vim auto-refresh too, though I'm not sure how.

(This is not editor related but in a similar vein...)

At my previous job we had to get a QIDO[1] since I type Dvorak and switching layouts with Cmd-Space was driving us both insane. We would invariably forget to switch and either write gibberish into the file or, worse, hit some unintended keyboard shortcuts. After getting a QIDO it was fine though.

[1] http://www.keyghost.com/qido/

I pair at least once a week with an Emacs user. Switching between Vim and Emacs is not a problem as long as both people are fast at file-switching.

Updated to be more clear; thanks!

TIMGroup do, and we are a product company, not a consultancy. (We don't use it exclusively, but certainly pair very frequently.)

We pair a fair bit at Square. We require that all code either be paired on or go through code review, but let each team decide their own process. Some of the teams pair 90+% of the time, and some pair only infrequently.

We used it all the time (Emacs/SSH/tmux) at my last gig since the engineering team was 100% remote. It worked fantastically well.

We (a consultancy) seem to only use it when someone has some design/implementation questions and/or concerns. For example, I don't need someone watching me write code I'm comfortable writing... they should be busy producing as well. However, if I'm unsure about something, having someone look over my code and/or help code, is extremely useful. Code reviews is a different subject completely, and is "definitely" a great learning experience for everyone involved.

That is because pairing helps mitigate risks (human error), when you're being paid to build software no client like to pay for bug fixing, they would rather pay a bit more to make sure there are less errors (or at least appear more bug free).

If you're a bootstrapped start-up, it is not an efficient use of time to be pairing 100% of the time. We tend to only pair on 'core' parts of apps or 'hard' problems, or when someone needs another pair of eyes on something (two heads etc), otherwise clients budgets are quickly exhausted on pairing for pairing's sake.