Foreword: So back in an old team of mine, we've developed larger stuff like our application deployment pipeline or our backup logic together without even calling it "pair programming". In the new team, I am working with right now, we hardly used the pair programming approach at the beginning - instead, people worked more on their own. But at a certain point, we had some projects that would not have been finished in time if only one person had worked on them. Accordingly, we were somewhat forced to complete the larger tasks of the project together. This post is about my experiences and pros and cons while trying out pair programming.
What pair programming should not be
Now and then when you mention pair programming to colleagues they possibly begin to shudder. It places people in vulnerable states as someone else peers over their shoulder as they work. If you are one of these people who feel addressed now, let me tell you that I felt the same way at the beginning. It was not only embarrassing at first but stressful and frustrating at times too. However, after pair programming regularly in several projects, it eventually grew on me. And, as a result, I've experienced the long-term benefits of this technique and these I would like to show you now.
Prevent the typical knowledge silos
Ah, this is a perfect topic. You know life happens - so if someone is ill, takes a vacation, or leaves the team, it leaves the other colleagues on the team with a large knowledge gap behind. Nobody can know everything in a world where things change so fast but it's important to understand how the other parts of your project work together. If you know this then it is easier for you to see how your work affects the big picture.
Strengthen the relations with your colleagues
With the pandemic and also in IT in general, many people work remotely. When you work singularly on projects, it can be easy to isolate yourself from your colleagues. Pair programming can help you to get involved with other members of your team, helping to build better relationships with one another while coding.
Clearly expand your knowledge
“The more you know, the more you know you don't know.” - Aristotle. There is so much to know in this industry that it is nearly impossible to know everything. We never stop learning new things. And the potential to learn new things is particularly high when you exchange ideas with other people about a specific topic. In my opinion, two minds are better than one. Multiple sets of eyes give more opportunities to spot errors, bugs, refactoring opportunities, or missteps during the process. It's always helpful to have a second opinion.
With all these positives, surely there are negative points now that will keep others from giving it a try for themselves, right?
Of course, there are. Let's briefly look at those points together and then try to break down how we can solve them.
The first question you can ask yourself, of course, is why don't we want to share? And this is also more of a personal question. For example, we don't want others to break our work which we've already finished. Another problem for some people is that they don't want others to change it. Because then it can feel like it is no longer their work.
How can this be applied to the developer world?
Well sometimes, code is treated by developers like their most treasured property.
In addition to the above, there are other reasons why we might find it difficult to share our code. You know - if someone is looking at our source code while we are creating, we feel vulnerable. Or if someone already makes changes to the code before we could even explain the logic. This can also cause certain feelings (mostly anger, sadness, panic). So you see... there are plenty of reasons why we might decide against pair programming.
Overcome the bad feelings
As I mentioned above, I would also like to list possible improvements from my perspective that I think could help.
Identify the needs of the session before taking action
Different needs mean different actions. So try to identify what you or your colleague really needs. Is it the inspiration to solve a thing? Is there possibly a lack of knowledge on a specific topic? Implementation is too difficult? All these questions require different answers and related to this, also different actions.
Be transparent
Transparency is important. Show your counterpart that it took you some time to understand something. Learning new concepts or programming languages takes time, which you also needed in the past to understand. Do not expect too much from your colleague and say that you also needed some time to learn. This can reduce anxiety or stress.
Explain the why
As you go through the different stages - from concept to completion, there will be some moments where you might take a wrong turn. These particular moments are especially important because they are an essential part of learning. Here it is necessary to discuss the "wrong decisions" together because being wrong is half of the learning process.
With these points, I tried to describe what pair programming means to me. Pair programming isn’t just about the coding - it's also about building relationships with our colleagues and learning how to work together. I think this concept of collaboration can help you bring your team even closer together and empower them through this process to make them more successful altogether.