As a developer on a project, I often take time before my pair is ready (or time at the end of the day after my pair has left) to see if there are tasks I can make progress on solo.
If I’m unsure about the approach for a solution, the design of a function or class, or the performance considerations of an architecture, I record my questions and concerns and then try to gather data to reduce those concerns by doing research in api/framework documentation or by making small experimental spike apps.
In most cases, I find enough information (and, therefore, confidence) to start working through a potential solution on my own, or I’ve bridged the time for which my pair wasn’t available (be that an early am or late pm hour), and we can sync back up as a team.
At Atomic Object we pair pragmatically, not dogmatically. Not only does pairing 100% of the time on all code not make sense for our clients, it doesn’t make sense for us as developers. Some tasks — such as renaming a class, updating copy, or refactoring/reorganizing existing logic once a direction for doing so has been set — aren’t as needy of a pair as others are. That’s not to say they wouldn’t benefit from another set of eyes, but rather that the additional set of eyes isn’t always a requisite while working on the task.
[…] on practices that are core to Atomic’s software process, including contextual inquiry, pair programming, test-driven development, and design validation […]