Pair Programming is one of the practices that fall under the Extreme Programming discipline. Benefits to practicing this behavior include improved knowledge sharing, consistent productivity, and fewer bugs. Any technologist looking to pair program should think through the situation driving this decision in order to make best use of the time and experience of the participants of a session.
It can take trust to begin a pair programming session, so remember that both parties are usually interested in the benefits and are doing the work willingly. Start from a place of clearly stating goals for the pairing method, time to spend working together, and expected outcomes.
It may make sense to have a “pre-pairing” session to make sure that there is no confusion with IDE setup, technologies used, or software pre-requisites. Assuming that the session is virtual, make an effort to ensure that any code is clearly readable via video conferencing software. If needed, consider a tool such as USE Together designed specifically for these types of sessions.
Equal Experience Level
If the two participants of the pair programming session are of equal or near equal experience in their career or technology being used, using a simpler time tracking technique like pomodoro can provide a clear time box for which one person “drives” (directly writing code) and the other talks through each step and asks questions to clarify the working being done. Be careful not to jump around to what each person just wants to work on, and instead focus on one task or section of code at a time with both developers spending nearly equal time in the same area. It is important to state this early on to make sure that a more confident developer does not prematurely leave unfinished code.
Unequal Experience Level
The participant with less experience should spend more time on the keyboard writing code with the more experienced developer providing verbal guidance and assistance. It may take more than one session to find a good balance of how much time should be spent by each person writing lines of code. The ratio of years of experience may be a good place to start. For example if one person has 4 years, and the other has 2 years of experience, it should be something like 40 minutes on the keyboard for the less experienced developer to every 20 minutes on the keyboard for the more experienced developer.