Counter Corona: Pair-Program everything!


Posted by Steven

As most of us, my developer team and I are doing things quite different these days. For future readers: The Corona virus holds the whole world hostage. To stop the spread, humans in all countries try to avoid physical contact. Many developers already are experienced with working from home. My team and I did not have to change much in the last weeks because we have been working remotely from the beginning. Half of the team is working in Romania, the other half in Germany. To optimize the slightly new setting and to counter emotional isolation, we implemented some rules. One of them is to have all (yes, all!) stories worked on in pair programming. This article explains what exactly we are doing and what it does to our tasks and us.

My first assignment was to refactor a Spring backend with a young colleague. Compared to my pair, I had much more experience with the code base. That lead to a lot of explaining about the why's and how's of the codebase. Because I'm a huge shortcut-fan, we talked extensively about features of IntelliJ IDEA and how to memorize the corresponding shortcuts. These topics would never have come up when working solo on the problem. Of course, these discussions needed some time, I estimate it with around 30% of the time needed to finish the whole task. The long-term learning-effect for my younger coworker, both regarding the history of the codebase and the tooling was well worth the extra effort. But it was not all about learning from me. When trying to understand a certain behavior, we analyzed the codebase via screenshare. Right before I scrolled down and away from a certain method, my pair pointed out a line of code that proved to be the cause of the behavior. I sure would have missed that!

My second assignment was kind of a long-term project with a young student coworker. With me as a kind of advisor, my pair develops a small helper tool. Because this tool is a standalone application, all of the fundamental architectural decisions have to be made like what technologies to use, how to structure the code and what dependencies to have. In my experience, this phase of a project always benefits from having multiple minds working on it, comparing and weighing options. I think that my pair learned some of the concepts of how to develop different options and how to choose between them. Also, of course, I kind of pushed the topic of shortcuts into our work. "Alt + Enter!", "Alt + F6" and so on ...

A third task I worked on was somewhat different from the ones I described here because my pair was another senior developer in the team. Together, we reviewed and finished an extensive refactoring in a Spring codebase. We used our sessions mainly for conversations about architectural options and what they would do to the codebase, the team and the complexity of the project. Although we produced much less codechanges than with my previous pairs, the long-term effects of what we discussed were much more severe. Making these decisions solo and without consulting another developer would have solved short-term problems quickly. However, most likely it would not have been the best solution.

In retrospect, all of the pair programming sessions proved to be beneficial in some aspect or another. Most of the time, one or both pairs learned a new shortcut, tool, best practice or technology. Although the sessions took longer than working on problems alone, positive long-term-effects occurred. In addition, I learned to understand how my coworkers think, how they approach problems and what their strengths are. This made the sessions worthwhile, despite that they were way more exhausting. On some days, I really needed a silent lunch break to recover from detailed discussions. Another downside of the do-everything-together-approach is the need for coordination. Working alone can mean to solve a certain problem in the late evening because there's time for it. Working with a pair means to find out what to do with the two hours in the morning when the early-bird waits for his late-sleeper pair. I used this time to read articles and make progress with my Udemy courses.

TLDR;

Working on every task in pair-programming-mode requires additional organizational overhead and discipline. Also, at least some task will take longer. However, this time is invested in longterm learning and team-building and thus is a good investment.

Share: