Building collaboration through pair programming: a journey
Coauthors: Gustavo Tonietto and Mahmoud Elawadi
Introduction
It has been months since we have adopted pair programming in Martech at heycar. When we started, it wasn’t clear what were the benefits and we had the assumption that it would consume more time and be less efficient than working solo. But it didn’t take long until we got used to it and started to see its advantages.
Then, as time passed, we got experienced with the practice and now we can say we have pair programming as something usual and natural on our day-to-day work, and working without it too often feels uncomfortable. That’s why we would like to share our experience and encourage other people to adopt this practice.
To do that, we will introduce how we did it, what were the main benefits we perceived, and the challenges that we faced. We will begin with the techniques — and tools — that we decided to have that made us feel more safe about pairing. It was after that we felt we were getting the grasp of what it means to pair program.
Techniques and Tools
Using a proper technique was one way of overcoming our own resistance to pair programming, practicing it weekly was another. It got a lot easier and more natural when we studied some online resources, decided on our own process, and finally started experimenting with it, adapting as we needed.
Our Technique
In our case, we were three frontend engineers, two of the engineers were “anchors“ — each one of them was assigned to a ticket — and the third would switch between the two anchors every 2 days until one of the anchors would finish their task. After finishing the task the anchor whose ticket was finished would become the person switching and the person switching would become the anchor.
We were using the Driver and Navigator style, where the driver is the one coding and the navigator observes, reviews and guides the next steps.
The driver and navigator switch roles every session, to manage sessions, we were using the Pomodoro technique: every pairing session is 25 minutes with 5-minute breaks in between. We usually would have an extended break of 30 minutes after 4 sessions or so.
Our Tools
As we were pairing remotely, and using the following tools:
- Zoom: Used for video calls, driver shares their screen and codes while the navigator observes.
- Github: Before switching driver and navigator roles, the code is pushed to the branch so the next driver can start from where the previous session has ended.
- Cuckoo: Used for time management, since we are using Pomodoro we set sessions to 25 minutes and breaks to 5 minutes.
Benefits
Although it took time and we faced some challenges initially, the more time we spent pairing, the more we understood hence benefits start to become obvious. Here are few major benefits we had while working in pairs.
Shared Ownership
One team member working continuously on a module in the application could lead to single ownership. This situation can happen if a team member takes a task because of existing knowledge of the module and more work on the same module leads to acquiring even more knowledge. In past, this could lead to a single person owning the module and the rest of the team completely unaware of its internals.
With pair programming we overcame this problem with existing code and avoided this from happening in the future, If one of the pair members is a newcomer to the module, the newcomer gradually acquires knowledge while pairing. If modules are being built by a pair, it helps to create a shared knowledge base of the application. This way pair programming leads to less scary times working across the application.
Onboarding
Another usage of pair programming could be for onboarding new team members, we onboarded our new team members using pair programming from the beginning stage. It helped them focus on the feature/ticket at hand right from the beginning and not trouble figuring out how the application works. Contextual information associated with the application could be passed while pairing on the ticket. Pair programming made onboarding smoother and there is room for resolving new team member’s queries.
Team Interaction during home office
Pair programming also helped newcomers to get comfortable with the team especially during home office due to covid. It helped us know our colleagues professionally and personally.
While working in pairs it also helped to have practical self-expectations, showing someone how you work was not something very comfortable in the beginning, we had a feeling that our peers might have better expectations than the way we work, but with time we realised that it was mostly overthinking. As we worked together every day we got to know our team members well and it creates a more open environment within the team.
Learning from each other
Pair programming helped us with trying and learning technologies from peers and standardising the practices across the team.
Due to knowledge sharing, It gets easier for us to understand the usage of tools e.g decoupling building UI component using storybook and integrating with the application is a practice that we adopted while working in pairs. Adapting TypeScript and Test-driven development(where possible) are other successes that share the credit with pair programming.
It’s not just that while working in pairs we had another perspective of looking at the same implementation as we usually discussed our approach. There were few experiences where one of the team members challenged the solution and suggested taking it another way. It led to finding existing official libraries rather than building our own, or reusing existing modules instead. We also learned our day-to-day tools and tips/tricks from each other every day.
Better code and faster reviews
Pair programming allowed us to have opinionated code right from the development stage. As another team member is already reviewing code as you are building, it reduced the efforts to review the PR and hence reduced the time to release it to production.
In practice it worked like this, multiple team members had the context of the modules due to pair rotation, even if one of the team members doesn’t pair on an entire story, they had lots of information about decisions made while building the module. In the end, while reviewing code, information acquired while pairing was very helpful.
Pair programming helped improving our code standards by reducing redundant code, improvement in test coverage, and increasing code re-usability.
Challenges/Difficulties and their solutions
As we started adapting pair programming as a daily practice we also realised that there are some difficulties and challenges. We had to refine our daily practices in order to make working as a pair smoother. Here are some of our main challenges and how we overcome them.
There were challenges even before we started pairing. We had to overcome our own resistance, especially the idea that pairing was a waste of time. Seeing only one ticket at the team’s board being worked by two engineers was challenging. That could only be devised after some time of activity.
Not every task justifies pairing
With time we got more confident, but there were and there are still some challenges to overcome when pairing. We have to keep reminding ourselves not to push it too hard, for example. Pairing is an intensive activity and it is easy to forget to take breaks or to not do it too often or too much on a given day. It is always helpful to be mindful of our own state and decide if we should keep pushing or stop the pairing session for a couple of minutes or for the remainder of the day.
Not only that but, we have to know when should we pair on something and when it doesn’t make sense. Pairing on something that has a clear feeling of accomplishment as output is awesome, but there are tasks that involve too much research, investigation, debugging, that may or may not be suitable for a pair programming session. It is up to us to understand when it is not. Sometimes we have to realise it is not working as expected to understand that the task at hand was actually a good candidate for working solo.
Planning your day
But even when it is crystal clear that there is a good reason to pair on something, it is still necessary to sync both developers’ calendars to be able to find common time slots for one or more sessions during the day. Things like parallel tasks, meetings, interruptions, or simply home-office-related difficulties — things that would already disrupt solo work — can provide extra challenges to pair programming.
On top of that, when trying to squish a couple of sessions between different activities, it can be extra tiring with the excess context switch. The natural brain fatigue is higher than usual, boosting frustration and tiredness.
Communication
Another corner to overcome when pair programming is the communication challenge. Both individuals on a pair programming session must work towards open communication. This is of course not exclusive to pair programming, but while doing it, its necessity becomes more evident. But this one, when overcome, has the advantage of building trust and respect that also extrapolates pairing sessions.
This also works towards other challenges. Open communication helped us to deal with our anxieties and expectations. And also with insecurity while letting others see our work methods, our failures and our weaknesses. We tend to get to know each other better and even to get a better understanding of ourselves. And this opens up to a lot of good outcomes that make pair programming worth all the trouble.
Conclusion
Pair programming is definitely very beneficial to both teams and individual developers — and we’re experiencing this. These tips made pairing smoother and more productive for us, and helped us adopt pairing:
- Open communication: The pair needs to be actively communicating to be able to properly plan how to approach a task, how to include the other developer, and to be able to discuss possible solutions.
- Taking breaks: This will help the pair to stay focused and it will prevent fatigue halfway through the day
- Set a time limit for daily pairing: We have to make sure not to overwork ourselves, more work doesn’t necessarily mean more productivity.
- Be flexible: Although we advise sticking to a technique while pairing, it doesn’t hurt to break a routine every once in a while. Take a longer break whenever you feel fatigued, work a longer session whenever you feel it’s necessary, but don’t make this frequent.
Overall, our team has gained a lot from the practice. We’ve learned how to plan better, in terms of our time and our approach to tasks. Also, knowledge sharing has become easier and less time-consuming.
We advise teams to overcome their resistance and adopt it as a day-to-day practice. After almost half a year of working in pairs, we can say the benefits outweigh the efforts. The skill that we have acquired along was not only useful to work in pairs but also helpful for day-to-day as software engineers.
References
We recommend these articles/videos that contain more detailed information about pair programming and how you could also take advantage of this valuable tool:
