Programming Paired and Shared
We pair program where I work. Two people, one desk. It can get intense.
Editor wars claim few casualties — until an emacs and a vim user are forced to share a keyboard and screen, that is. Anyone for notepad?
Sharing the typing isn’t why we pair. Where I work we also do code reviews. Whilst pair programming is encouraged, code reviews are mandated: code cannot be checked in until approved by a reviewer. That reviewer could be the person you paired with, and it soon becomes apparent that reviews conducted with a pair go more smoothly than ones where the reviewer is new to the task. It’s hard for someone to review a tricky changeset without the context of its development.
The context of its development turns out to be paramount for understanding a codebase, not just a changeset. Pair programming helps provide that context.
The term pairing serves better than pair programming. The former suggests sharing; the latter, typing. The benefits come from sharing all aspects of the work: decisions and responsibility; research, design, development; how to test; where to cut corners and where to go beyond the immediate requirement; when to take a break. Anyone for table football?
Articles