This content originally appeared on Level Up Coding - Medium and was authored by Syed Mohsin
Too much of a good thing can be harmful
I’ve written at length about the Benefits of Pair Programming.
But if you are not careful, pair programming can tank your team’s productivity if done incorrectly or excessively.
Here are four common mistakes I have seen engineers make.
#1 — When it becomes a crutch
I have seen some junior engineers unable to build anything unless they pair program with a more senior engineer.
If the idea of working alone is daunting, then it is a good idea to sit in that discomfort and struggle on a problem yourself. Making mistakes and learning from them is where the magic happens.
I see pair programming as a tool to help engineers get out of sticky situations. When it becomes the default mode of operation, then engineers risk losing the ability to think independently and take a back seat mentally as they watch senior engineers solve their problems.
#2 — When you do it for too long
Pair programming more than 2–3 hours in one session has diminishing returns and is pretty inefficient.
When two engineers work asynchronously on two different projects, they are able to parallelize and get more done.
When you take those same two engineers and have them pair program, they can only focus on one project at a time and get less work done comparatively.
Again, I believe the problem starts when pair programming is the default mode of operation rather than a strategic tool to grow and unblock an engineer.
#3 — When you do it begrudgingly
Imagine how demoralizing it would be if you could feel that your pair programming partner didn’t want to be there?
If the experience gap is wide between the pair, then the junior engineer may feel discouraged to ask for help in the future. Engineers should never bring negative energy to a pairing session because that is a quick way to stifle collaboration and devolve into an anti-mentorship work culture.
#4 — When you learn nothing after a session
Perhaps the worst-case scenario for a pair programming session is when neither engineer learned anything. Regardless of your level of your experience, you should ideally learn something new or become a better teacher.
Related to #1 — if you become too passive while pairing or treat it like a crutch, then you won’t take note of how your partner is solving problems.
Similarly, resentment can build up if your pairing partner does not perceive that you are becoming more independent after each session.
The goal is not to get to a point where you don’t need to pair ever again, but rather to work on richer and more difficult problems than before in your next session.
Conclusion
It is crucial to find the right balance between pair programming and struggling on your own.
In my opinion, pair programming is a powerful tool but not the default way to solve every engineering problem. Pairing sessions should be focused on growing and “unsticking” engineers. When pairing sessions become too long, you risk one engineer becoming too passive and not learning anything.
How do you pair program at your company? Let me know your pros and cons below!
Like this article and want to read more? Subscribe here to get my latest articles right away.
Level Up Coding
Thanks for being a part of our community! Before you go:
- 👏 Clap for the story and follow the author 👉
- 📰 View more content in the Level Up Coding publication
- 🔔 Follow us: Twitter | LinkedIn | Newsletter
🚀👉 Join the Level Up talent collective and find an amazing job
4 Ways Pair Programming Can Hurt You was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Syed Mohsin
Syed Mohsin | Sciencx (2023-01-17T01:52:48+00:00) 4 Ways Pair Programming Can Hurt You. Retrieved from https://www.scien.cx/2023/01/17/4-ways-pair-programming-can-hurt-you/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.