The concept of pair programming is overhyped in most if not all tech industries. Even college students working on small projects in groups practice pair programming with the belief that it will improve their efficiency, codebases and also most importantly, reduce the total time required to devote to a particular task or feature.
There may be multiple groups involved who are practicing pair programming, or the entire team, or some programmers’ individual decision who choose or feel comfortable.
Yes, pair programming has really proved to be efficient when writing codes, improving particular features, detecting and fixing bugs, and completing a task within a deadline. But, like every rose has a thorn, we also need to be well aware of the ill effects of pair programming to make a good decision of whether to opt for it or not. This reminds me of the famous quote:
“Sometimes we need to see the bad side, to appreciate the good side.” — Anthony Liccione, Author
I, personally chose to adopt pair programming many times when working on small personal projects, mostly with my friends. I did so previously, by only considering the good sides and being unaware of the darker side. For this, I had to face a lot of challenges, which I don’t want others to face in the future.
From my past experiences, I will share the five cases when pair programming proved to be detrimental without offering any kinds of benefits.
Though difficulty level is highly relative and the total time to complete the task depends on various factors like typing speed, programming languages, etc., if we try to generalize a broader aspect, then we can divide a task into many sub tasks.
First, we have to look at how many sub tasks we have still got. By the way, sub task division and guidelines that need to be followed can also vary from organization to organization. If the total number of sub tasks is less than five, and all of them seem to be pretty easy to use and will consume very little amount of time, then don’t go for pair programming. If you feel confident enough in completing the tasks, why indulge another programmer on the same task?
They may work on some other features or independent tasks on their own. Choosing pair programming in such cases wastes valuable time and resources by boosting productivity.
Sometimes, pair programming is performed very differently in various organizations. Sometimes, two programmers sit close to one another and share all resources like the monitor, keyboard, etc. Also, programmers may work in small groups of 3 to 5, all brainstorming together but limited to one resource at a time.
I feel that if you are not working on fixing bugs or debugging, then it is better to have separate display units, keyboards, and mice accessible for all programmers collaborating in groups, so that each one can access simultaneously and work.
Avoid working in a group of five for long hours by sharing the same set of resources. This increases not only stress, but it is also very difficult to prioritize who should go first when writing code.
Every programmer works at different problem-solving levels and proficiency when handling specific tasks.
Some programmers can be excellent typists, while others have to look at the keyboard while typing. Some may be very good when working with databases while the other one may be good with Machine Learning.
It is very difficult to find a perfect pair who has strong expertise in the domain that you lack and also has the same speed when writing code. Also, it is required that both can debug pretty well and can understand each other’s code or coding styles pretty fast.
I have seen many times where people write code for the same logic or algorithm very differently, and if you are not accustomed to or have spent time reading others’ code, then it may be quite challenging for you. Now, you will or may have to constantly ask your partner to describe or explain their code or logic behind it. It becomes even more challenging if you are just learning a new programming language and you are not fully aware of its syntaxes, in-built functions, classes, format, and so on.
Level of friendship with your partner plays a crucial role in pair programming. Even though very few talk about this but this decides how effective or beneficial it will be to work with your partner.
If you have joined a new team and are not accustomed to everyone, their habits, coding skills, how well they communicate, and so on, it is best not to do pair programming right from the very first day if you are not told to do it.
Some programmers even hate the pair programming concept and prefer to work alone. They work well for long hours, wearing headphones, not getting distracted elsewhere. As long as they deliver their work on time, with minimal bugs, no one can force them to do pair programming.
If you force some person to be your partner in pair programming, then it will just worsen the situation. Both of you will get frustrated over time, and your relationship with your colleague will deteriorate. It is good to not do pair programming just for the sake of knowing each other well.
If yes, it is best to pair with someone who has been doing pair programming for a significant amount of time and is quite accustomed to the process. Also, pairing with a person who is knowledgable about what to do when things don’t go as planned is helpful. Discuss with a professional pair programmer, if available in your team, as they might help with choosing a partner for you.
Pair programming may reignite imposter syndrome, when you see your partner solving a problem or fixing a bug easily that you have spent several hours on and are still unable to resolve. Such kinds of situations may arise many times for you and your partner. Either of you must know how to handle it when such a situation arises or else it will reduce productivity rather than improving.