Pair Programming Practice
Last updated
Last updated
Last review: May 28th 2018
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
--
Two heads are better than one
More efficient
Fewer coding mistakes (on-going peer review)
Effective way to share knowledge and learn
Develop interpersonal skills
Pairing is appropriate when:
Implementing complex features
Fixing a bug
Refactoring
Onboarding a new member
Live code review (one member reviews code implemented but the other member)
Pairing is not appropriate for:
Easy and simple implementation
Chores
Research/investigations
Code review of a PR that does not belong to the pair
To make pair programming as efficient and as enjoyable it is important to have a common set of tools with the same configurations.
If you and your pair have negotiated a different setup, you're welcome to use it.
The default themes used for applications are "light":
MacOS: Light
Atom: Atom Light (UI) / One Light (Syntax)
iTerm: Solarize
If the pair wants to change the themes, this may be negotiated.
Both pair members access the Cloud9 instance using their Amazon IAM account. The pair use Zoom for audio. If need be, the pair can use Zoom to share a window or screen, like for instance look at the Github issues together.
It is responsibility of one of the pair members to prepare the cloud pairing station for the pairing session.
Before starting a new pairing session
one of the members prepares the workstation
negotations are completed, e.g. themes; when to take breaks and lunch
Note: breaks are very important to take. Try to take a break every 1.5 hours for 15 mins.
For pulling and pushing to Github, we use our CivilCode pairing account (civilcode-pairing). The first time a repo is pulled through the https handle, git asks for the username and password. By default, the credentials are cached in OSX keychain.
Update the ~/.gitmessage file (uncomment/comment co-author lines)
Prepare the editor and terminal with the recommended screen configuration
Fresh master has been pulled
Test suite is green
Prepare the editor and terminal with the recommended screen configuration
The branch has been checked-out
The branch is rebased with master
Test suite is green
Good etiquette translates into efficient pair programming.
Agree on the physical environment beforehand
When talking about code, always refer to line number and file name
When disagreeing, talk in terms of benefits
When feeling ill at ease, say so
Bestow as many compliments as possible
The developer having the keyboard and mouse is considered the driver, while the other developer is the watcher.
A significant part of the watcher role includes continually reviewing the work of the driver, pointing out spelling and syntax errors at the right moment, and providing feeback when the driver asks for it.
The overall flow is simple:
Pair discusses the next problem to solve
Developer A becomes the driver
Developer A refactors an existing test module (if applicable)
Developer A writes a failing test
Developer B becomes the driver
Developer B refactors existing production code (if applicable) - not the tests!
Developer B makes the test pass writing only enough code to make it pass
Developer B makes a commit (if it makes senses - highly suggested)
Pair discusses the next problem to solve
Developer B refactors the previous test or other tests (if applicable)
Developer B writes a failing test
Goto 2
Continue until Developer A and Developer B both agree that there are no more tests for the unit they are currently working on
Things to watch-out for to prevent breaking the loop:
Watcher should not move the mouse, unless asking for permission to do so.
Watcher should not touch the keyboard, unless asking for permission to do so. If permitted, this is not considered a role switch.
While making a test pass, if the test code needs tweaking, it is up to the driver to do the changes (not the person who wrote the test, in this case the watcher).
The driver can refactor the code in which modifications are about to happen only when all tests are passing.
If the pair is performing long refactoring, the role switching can happen after each refactoring or group of small refactoring. The driver should watch for not keeping control for too long, otherwise the watcher may "lose interest".
For the pair:
First, before either writing a test or implementing the code, a clear shared understanding has to be established. Otherwise, the watcher will have a hard time following the driver and disagreements may arise quickly.
If research is required at some point, don't hesitate to split and regroup at some point.
When writing code to make a test pass, the goal is to get something quick and dirty working. Then the pair can discuss and improve the code. If the driver had the keyboard for a while, the watcher can then take over and do some refactoring before writing a new test.
If the pair disagrees on design or implementation and cannot come up with an agreement, the pair needs to determine if the issue is the technical lead or another team member should be brought in and a discussion should happen. If no-one is available, a solution that leaves options open should be adopted so progress can be made; the issue can then be discussed when the technical lead or another member becomes available. It maybe determined that the issue is not project specific, i.e. is a general design issue and requires R&D. At this point, an issue will be created in our reference repository and scheduled for investigation.
The code is shared by the development team, therefore use we instead of you or I when referring to the code.
Be proud of what you achieved as a pair. Take time to admire and feel good about the code.
Be mindful of your hygiene.
For the driver:
Be willing to be vulnerable, do not be afraid to ask for help. This triggers a discussion and the driver can then resume. It is a great opportunity to learn.
The driver must communicate the intentions. Otherwise, it is difficult for the watcher to follow the thought process of the driver.
The driver regularly asks the watcher for feedback (errors? spelling mistakes? opinions?)
The driver should not keep the keyboard for too long. Big refactoring can be split into smaller ones and each member in turn refactors portions of the code.
For the watcher:
The watcher should try to limit interruptions to prevent the driver loosing focus. The watcher should wait for a moment where an intervention is "à propos" and is absolutely required (i.e. the driver started something on a wrong path).
The watcher should not tell the driver what to do, unless the driver asks for it.
If the watcher wants to use the keyboard/mouse, it must first ask the driver.
When pairing remotely, as a watcher, avoid distractions and stay in the same file as the driver, as if you were pairing in person.
; editor
; terminal
; Git GUI - optional
Pair programming is done in with the editor on the left hand-side and the terminal on the right-hand side. It is helpful to be familiar with to work with fullscreens gracefully.
Remote pairing is done using a cloud pairing station. We use Cloud9. A pairing instance must first be provisioned for the project. See .
; pairing station in the cloud
; screen sharing and/or audio
When committing code, the pair uses the feature of GitHub. The dotfiles have a list of possible co-authors in the ~/.gitmessage file.
More details .
This technique is based on the .
The watcher is not a navigator (concept from another pair programming technique, as described ).
- Video