A few months ago, we had a discussion about problems that members of the Payments team face. We identified knowledge sharing as the main problem: the Payments team takes care of payments, obviously, but that means communication with payment service providers, card tokenization, payment automation… And it’s not just a complex domain, but also an important part of our system. And even with a good code review process, quite often you can see only parts of a project and not the whole picture. So, when our team saw several knowledge gaps, we took it seriously and decided to try pair programming—having people share their knowledge with others while working together on specific tasks.
Implementation
We’ve always recommended working together—solutioning with someone, discussing review comments personally instead of through GitHub, etc. And, of course, we ask each other for help when stuck or unsure which approach to take to a problem. But pair programming is different, and we decided to have some strict rules:
Pair programming sessions are one day a week – it is predictable and transparent so everyone can schedule time for it without having to constantly replan.
Pairs are always different – of course, people sitting together (in the old days back in the office) discuss things, and there are different relationships between different team members, so a lot people would naturally pair up if given the choice. We decided to make pairs randomly so everyone could learn from everyone else and get to know each other.
Pair programming sessions last the full day – we don’t want to only do solutioning together, or implementation, or review. We want to go through the whole process together. So, we decided to spend the whole day in pairs. We even review pull requests (from a different pair) together.
Results
After more than two months, I believe we can summarize some results.
Knowledge sharing is better than expected — team members not only share domain-specific knowledge with each other, but also tips and tricks, different approaches, and knowledge about tools, like using Azure Data Studio instead of SSMS (thanks Matthijs).
Also, solutions found and developed during pair programming sessions are better — it always helps when you have to explain the next steps out loud to someone. And no matter how senior or junior the other person is, it is great to get a different point of view.
Our review process is smoother and we can get our work to production sooner. The magic is in real-time feedback. There’s no waiting for review, for explaining comments, etc., everything is resolved immediately when the code is written. And, more importantly, with a perfect understanding of the context.
And it’s fun. It’s better than it sounds. It also improves our relationships because, if you have to spend all day with someone, you will definitely spend some time discussing things other than work.
As you can see, we are happy with our pair programming sessions, but we believe we can move it further. What are our plans? We probably want to do it more often. And we want to multiply all of these benefits.
When I saw this tweet, I had no idea what mob programming was, but after a few minutes of reading, I was sure we have to try it. And we did. And it was even better than pair programming, although some of us expected disaster before admitting it was good (thanks Michal).
I think we need more time and practice to use the full potential of mob programming. So far, we used this approach to start a large refactoring that we’d postponed for a long time.
Conclusion: make a habit of it
The main message of this article is that pair programming is worth a try. And if you want to try it, prepare a few simple rules that people can follow and then make a habit of it (as usual when starting something).
