Important things about pairing:
Make sure team rotate on who and who will pair together. Otherwise it creates segregations.
Leave free time at the start and end of the day so each person will have time to check messages, etc.
How much time the team should spend on pairing? My group did 100% pairing, i.e. all coding was done through pairing. Later we changed to selectively choose to pair or work on things individually. From the pairing experience, there are times when pairing doesn’t work well. When the pair needs to try to experiment, when both are willing to try some totally different approaches, it is better that each person tries on their own, and then come back to pair and review the results together.
When the task to work on is very straightforward and simple, it is not necessary to engage two persons to pair on that. Even with rotating who to drive and who to navigate, it would become boring to pair on super simple tasks. It will be better for the pair to split the work and each work on their own. Then after they are done, review each other’s work.
The time when it is very good for pairing is when some design thinking is needed, then through pairing, 2 persons working out this phase together not only gives better design, but also having both of them gaining good understanding on how to proceed if they are going to split work to work on their own. This is better than each person just learn from reading other people’s codes and interpret the intention of the codes based on their own understanding.
When there are complicated tasks, pairing or mobbing will be more effective to tackle them together. It is also very good learning time to let junior developers to learn and grow.
Pairing is most effective when two persons are at about the same level relative to the difficulty level of the task. Both sides contribute thinking and ideas. No extra explanation is needed when both understand what is considered best practice or what design patterns to use.
Pairing is good to bring new person on board in a new area, or it is good to share knowledge. However, if for long term the persons to pair with is always at askew level of skills and knowledge, productivity or even team dynamics won’t be good. This is not a problem of pairing, but a problem of team structure. A team should have mixed level of team members. At work, we normally have mixed difficulty levels of work. Then pairing with different persons work well for different types of task at work.
Seniors pair together can tackle very complicated task or work out a good design for the product. While senior pair with junior gives the junior an opportunity to learn from a senior person, but it also allows the senior person to teach and practice mentoring and communication skills. By explaining things to the other person, it will help the senior person to work things out too by talking loud what is in their mind. Junior and junior pair together both get more opportunity to practice and improve on decision making.
Some groups practicing pair programming try to hire many junior developers to reduce cost, having the thinking that two person together will provide better quality of codes. However, this doesn’t work that way with complicated task or when good design is needed.
One thing to watch out for is pairing doesn’t really give enough opportunity to an entry level person to grow into a good developer, or it maybe a very slow process. To become a good developer, it requires abundant coding and trying things. Having some side projects or hackathon will work better for that.
Digital Transformation Journey 