We have recently begun to do more pair programming. The main goal is to more quickly bring new people up to speed with things they can’t easily get from searching our documentation, e.g.
- General domain (Banno / banking / JHA core) knowledge
- Our software stack
- Coding conventions / practices
- How to write good tests
- How to work around issues that might seem to be blockers (big / sbt probs, etc.)
Tips that May Help
This section is largely gleaned from Brian’s experience pair programming at ISL. We will certainly vary from this according to what we find useful.
I’ll use the terms ‘driver’ and ’navigator’ to distinguish who is actually coding at one time.
Talk. A lot.
As you’re thinking, be discussing your design, your logic, your test cases and your tool. A surprising amount of learning happens here. Pair programming sucks if one person is just watching someone else code.
Let the person least familiar with the code drive a significant part of the time
This gives them the practice they need and gives the navigator the chance to guide them and focus on filling in gaps in their knowledge.
Change drivers often
This helps keep you engaged rather than having one person feeling like an extra wheel. For remote pairs, you will need something like ScreenHero, Chrome’s RemoteDesktop add-on
Consider switching on test / implementation.
At ISL we used the following rhythm:
- RED: Driver A writes a test which fails
- GREEN: Driver B writes the simplest code that could make the test pass
- REFACTOR: Driver A takes the keyboard again while the pair cleans up the new code (refactor)
- COMMIT: The code is in a green state, so commit it.
The idea is to take short steps that keep the code green, integrate often, keep master releasable and avoid the need to merge with anything but master.
Let the navigator capture ideas / issues that come up
The driver is often tempted to fix problems he sees in the code he’s ‘passing through’ while working a task (such as ‘add method to search by SSN’). The navigator captures those thoughts so the driver can stay on course. When the task is done, return to the captured list (this can be part of the REFACTOR phase if you’re following the flow above).
We kept a doc for each card for capturing such things. Part of finishing the card was reviewing this doc to see if we’d left anything on the table.