Hidden challenges of Pair Programming
In this post, I am not going to talk about what pair programming is and it’s benefits for software development teams. Instead, I will share some of the hidden challenges, I would rather call them root causes for the reluctance you hear from the team trying to start pair programming.
If you understand the value of pair programming and would like to implement it in your team (or) you are already implementing pair programming but seeing mixed opinions in the team, this post is for you.
Hesitation only enlarges, magnifies the fear. Take action promptly. Be decisive. — David J. Schwartz
A lot of times, hesitation is a common problem when teams newly switch to pairing. People start feeling uncomfortable questioning others opinions, maybe they are good friends and don’t want to end up in conflict or maybe both of them don’t care about each other’s opinions at all or maybe scared that they would be judged based on skills and abilities.
In any of these cases, you are doing exactly the opposite of what pairing recommends. More the conflicts, more discussions and your solution will be more accurate. In pair programming nothing has to be taken personally, after all both of you are trying to solve the problem together and making things better for the project. So do not argue about opinions, rather have a conversation with the intention to solve a problem and as long as respect is there in conversations, your relationship will be held high.
Another important thing for the pair to have is mutual trust. When the trust is high and each other’s opinions are respected and no one is judged based on their skills and abilities, people feel comfortable and they start sharing thoughts without hesitation, which leads to effective feedback and healthier conversations. So please make yourself comfortable with each other and create that layer of trust which will make your pairing more successful and effective.
Nobody works better under pressure. They just work faster. — Brian Tracy
A few junior developers expressed symptoms of pressure when they are pairing with an experienced developer. A lot of times, the reason could be because they feel that the team is expecting them to deliver from the first day and the pair is going to actively monitor their productivity. In such situations, experienced developers should initiate conversation and probably tell them that it is okay to not know things as they are just starting their journey and suggest them to ask as many questions as possible. Having these expectations called out explicitly will definitely reduce the pressure and give freedom.
I touch the future. I teach. — Christa McAuliffe
It is important for the team to understand the value of knowledge sharing. Having bottlenecks and knowledge silos can never make things better for the software. Knowledge transfer will not happen just because there are architectural diagrams out there or we are doing one or two knowledge sharing sessions. It is an ongoing process, which takes time and needs conscious effort and requires skill and by far pairing is the most effective way to share knowledge.
If you think, your pair lacks knowledge, motivate them, support them, suggest them with the right resources and maybe offer them help when needed. It is important for you to accept that, you also have been through the same journey and you should be able to empathize with the pair much better.
In a lot of places, the value of mentoring is underrated and people forget the fact that mentoring definitely needs a lot of skill and passion and it is the most important skill not only for pairing but also for the whole team and organization. So please invest some time on improving mentoring skills, you will not only deliver the project but also create impact in your fellow colleague’s journey.
False productivity measures
When a team has conflicting opinions on productivity because of pairing, there are different lenses we should look at. Is productivity really low, or we are measuring it in a wrong way ?
It is possible for a person who is on the project for a long time to have good experience on how things are done, so that person alone can definitely deliver the work in a short period than pairing with a newbie. If productivity is all about just delivering software then we are missing the crucial benefit of pair programming which is context sharing and quality.
If you feel symptoms of low productivity, this is the time, you should look at productivity from a different lens and make yourself comfortable that you are pairing because you want to share knowledge, you are answering questions because other people should be able to deliver software in your absence, you are discussing because it leads to better quality and productivity is delivering quality software while sharing the knowledge.
