In an attempt to speed up our development process, my teammates and I took a somewhat controversial route \u2013 we introduced pair programming. And it worked. <\/p>\n\n\n\n
The team comprises developers with different backgrounds and levels of experience. The idea was to use pair programming to level the team and make everyone faster and more independent in developing new features. We already had positive experiences with pair\/mob sessions when troubleshooting production problems or supporting our users (other engineers and support teams), so we gave it a go. <\/p>\n\n\n\n
We\u2019ve been at it for two years and are happily reaping the benefits<\/strong>. <\/p>\n\n\n\n Even though programming in a pair has been practiced since the dawn of programming, the practice was first introduced to a broader audience in the 90s. In his excellent book \u201cExtreme Programming Explained<\/a>\u201d from 1999., Kent Beck<\/strong> defined pair programming as follows: <\/p>\n\n\n\n All production code is written with two people looking at one machine, with one keyboard and one mouse. [\u2026]There are two roles in each pair. One partner, the one with the keyboard and the mouse, is thinking about the best way to implement this method right here. The other partner is thinking more strategically..<\/em>.Kent Beck, Extreme Programming Explained, 1999<\/p>\n<\/blockquote>\n\n\n\n Today, there are more options for pair programming than sitting together in front of a computer with one keyboard and mouse, from simple screen sharing to specialized tools like Code With Me<\/strong> from JetBrains. However, the above-mentioned principle remains the same. <\/p>\n\n\n\n I heard about pair programming long ago and was always intrigued by it, but I hadn\u2019t had practical experience before we introduced it two years ago. I heard a lot of positive experiences with it, and the success stories were impressive. <\/p>\n\n\n\n There is also a fair amount of skepticism, whereas the main concerns are that pair programming is expensive, slow, and necessarily ends in frustration \u2013 everything you would like to avoid in a team. And diametrically opposed to what we were trying to achieve. <\/p>\n\n\n\n As the team was already collaborative and had a proven record of great teamwork, we weren\u2019t afraid of pair programming ending in infighting. And yet, we were off to a rocky start.<\/strong> <\/p>\n\n\n\n Although everyone was theoretically up for trying pair programming, we didn\u2019t want to make it mandatory. This meant that, in reality, people were quite shy about asking for pair programming. <\/p>\n\n\n\n One of the issues was that they often didn\u2019t deem a feature valuable or complex enough to have two developers working on it, or there was pressure to code a feature as fast as possible \u2013 and talking about it all day long seemed like a waste of valuable time. There were also some social fears: What if other team members saw everything I don\u2019t know, what I have to Google, how slow I am? <\/strong><\/p>\n\n\n\n We gave up on pair programming on routine, repetitive, and simple tasks because we didn\u2019t get any added value. In that case, pair programming did prove too expensive. But, when adding new features, we saw more and more benefits<\/strong>. <\/p>\n\n\n\n It also took us some time to figure out how to be productive without frustrating each other with unhelpful comments and remarks. We found ways to work through things that bothered us (talking to team members can solve almost anything, right?). We took a pause when needed or moved programming sessions to different times. We didn\u2019t use any specific tool for pair programming, just screen share and audio call. <\/p>\n\n\n\n Despite our hesitations, even the first pair programming sessions were a positive experience \u2013 mainly because we all learned more than we expected, not only about programming, frameworks, or tools we used but also about the domain and the feature\/problem we need to solve. <\/p>\n\n\n\n We noticed that the ratio between talking and coding was much higher than we expected<\/strong>. Since we better understood the problem, the developed solutions and code were better than they would have been if we were coding alone. <\/p>\n\n\n\n In the beginning, the most experienced team member was the driver of most sessions, and we rarely switched roles during sessions. Still, we were noticeably more productive than working alone. <\/p>\n\n\n\n We paired for 3-4 hours a day<\/strong>, as we had other operations and support we needed to attend to. Not to mention that pair programming requires complete focus and can be exhausting, so 3-4 hours per day was the maximum anyway. <\/p>\n\n\n\n Focus was strictly on the task at hand, without the usual interruptions (Slack, mail, phone\u2026). We never got stuck on a problem and always learned from each other. Exhaustion aside, we were satisfied with the progress, and the results were better and more predictable than coding alone<\/strong>. <\/p>\n\n\n\n After a few months, we started with pair programming more often and switching roles. That\u2019s when another positive side effect surfaced: The code was always readable because if it wasn\u2019t, you immediately had questions about it. <\/p>\n\n\n\n The code quality, in general, was very good. And by quality, I\u2019m referring to Dave Farley\u2019s description: \u201cThe ability to change software easily, safely, and with confidence is a marker of its quality.<\/a>\u201c. I would say that the solutions we implement regularly are the best that team could implement (in a similar timeframe), regardless of the way of the work.<\/p>\n\n\n\nWhat is pair programming? <\/h2>\n\n\n\n
\n
Rocky start, stellar results <\/h2>\n\n\n\n
Better readability, predictability, and quality <\/h2>\n\n\n\n