If two people sit next to each other at the same computer and write code together, we call this Pair Programming.
We do not pair program 100% or even most of the time, but we believe that for certain problems pair programming is a very relevant and useful tool. It helps new members of a code base or section of the code base to hit the ground running and get started working in it as they are paired with a more seasoned developer. It likewise helps more junior developers help learn about how to work with tools or how to use them more effectively.
The result will likely be more highly polished code, as it was already signed off on by two people. Likewise, there is no better collaboration between designers, developers, or other stakeholders than at the keyboard.
When to do Pair Programming?
- When we want to foster knowledge transmission, especially for juniors or people new on a project
- When we want to tackle a complicated issues collaboratively to prevent architecture problems and get better results in areas where the investment is worth the extra attention (especially in business-critical areas)
- When somebody asks for this to help them.
Rules for Pair Programming
- Agree on the scope of what you will do together (how long? just to get the baseline? all the way? for one hour?)
- Agree where and when, so you are both prepared and it is not too spontaneous and disruptive.
- Agree on how you will work, which tools (text editor, or other tools) or environment you will use.
- Agree on how to pair. Who will take the keyboard? Will you switch around, and if so when?
- Keep talking aloud and encourage and support each other.
- Remember to sometimes switch and keep both sides involved.
- Take a break if it goes on for a long time or you are both stuck.
- Give each other feedback afterwards on how it went.
- Split tasks clearly: For example, usually the developer at the keyboard is free to worry about the details and do the typing, and the other can focus on the broader picture, ideas and architecture.