Writing code reviews, on GitHub or elsewhere, is a central part of a software engineer’s daily life. Yet, it is a task unlike any other: in addition to technical knowledge, a substantial amount of tact and subtlety is required in order to go past differences of opinion and establish a fruitful dialogue. This is of course true for both the one reviewing and the one being reviewed, but it is undeniable that, as the one initiating the discussion, the reviewer bears an even greater responsibility.
I’ve personally always liked walking up to the seat of the other person to have a chat whenever written discussion seems stuck. Unfortunately, in the age of COVID-19 and remote work, this option is not available anymore… That’s why, facing yet another delicate review to write, I’ve decided to try remote pair programming as an alternative. It was my first time doing so, and I feel like I’ve learned a great deal about myself and how I should try to handle it in the future.
Disclaimer: keep in mind that no two pairs are the same. As such, the lessons I’ve learned may or may not apply to other cases.
Pair Programming and Power Balancing
In an ideal world, a code review should be a discussion between equals and not a one-sided judgment. Comments regarding code should be exactly that - suggestions on how to improve it, and nothing more. But in reality authors tend to overly assimilate their work to themselves, taking criticism as doubt over their ability as a programmer1.
Writing a code review can thus quickly turn into a tricky diplomatic exercise. Don’t say enough, and there is no point in writing a review in the first place. Say too much (or express yourself badly), and you risk getting the other person upset, ruining any chance of dialogue and resulting in needless frustration.
The other day at work, I received a pull request on GitHub from a coworker that I’ll call T. As I was going through T’s code trying to write a review, I realized that I had comments to make. Many comments to make. So many, in fact, that I became worried my review would get T defensive and end up being counterproductive.
As an alternative way to carry my point across while ensuring a two-sided back and forth, I decided to try remote pair programming. But pair programming, while not suffering from the same innate bias as a code “review” (which very definition2 suggests an imbalance between reviewer and reviewee), obviously does not guarantee perfect equality between the two participants.
When talking about uneven relations in the workplace, people usually think about gender, age, or race. T and me are cisgender males, but we still have many differences:
- culture (T is Japanese, I’m French),
- personality (T is an introvert, I’m very opinionated),
- job title (T is a contractor, I’m an employee, which is a pretty big hierarchical difference in Japanese work culture).
Differences are a source of strength. But they can also create obstacles when it comes to making sure that everyone can freely speak their mind.
Pitfalls and Lessons Learned
I did my homework and came in with several ideas regarding how to carry out our pair programming sessions. Yet reality proved to be different, and taught me several lessons I will endeavor to remember in the future.
Come With a Plan
It may seem obvious, but it is really important to come prepared. This means that you should know exactly what you are aiming for before the session even begins, but it never hurts to take a few minutes to check that both members agree on the objective before diving into the code. Trust me, it will save you a lot of time later. Also, don’t forget that a good goal should be reachable, which means explicitly limited in scope (refactor one class, add one functionality…)!
During our first programming session, we took about 20minutes doing pseudo code on a blank notepad. It proved to be incredibly useful across the three sessions that we ended up doing, and was a great way to make sure that we were on the same page.
Stay On Track
While coding, it is deceptively easy to lose track of your objective and to start doing too many things for your own good. For instance, let’s say class A uses a method of class B. While refactoring class A, you may realize that the method of class B also needs cleanup. But what if B uses C, and you figure out C could benefit from a refactor? It is crucial to resist your initial impulse, lest you end up starting way more changes that you can possibly complete during your pair programming session. Instead, it is a good idea to keep a record of what you feel needs additional changes so you can come back to it another time.
Something that worked very well for us was rotating roles (between typing the code and supervising
it) every 30 minutes or so. This not only ensured that we kept a balance between who gets to talk
and who gets to type, but it also forced us to take our eyes away from whatever we were doing at the
time, and to check that we were still on the right path. Whenever we felt like changes were also
needed outside of our objective’s scope, we simply added TODO comments.
Don’t Make It Too Long
This may be because we were both new to pair programming, but we realized that a good pair programming session is a short one. It is a very draining exercise, and having someone else looking over your shoulder sometimes hinders your ability to think deeply about a problem. Taking breaks during a session is very important, and so is leaving some time between sessions. For us, about three 90 minute sessions over three days was a good amount.
It is also good to know when to stop: during our last session, we went over two hours as we were trying to address too many details, then realized we were losing efficiency and motivation. I personally feel like most of the gains made by pair programming happen at the beginning, when the two people agree on what to do, in which order, and start implementing the broad outline, but not so much later on when what’s left to do is coding the details.
Use your time with your partner to agree on the essentials, leave the details for when you’ll both be working separately!
Don’t Talk Too Much… Nor Too Little
This last point is highly subjective, and comes from my perspective pairing with a more introvert person: it is important to find the right balance between talking too much and too little.
When doing pair programming, a common pattern is to have one person coding (the driver), while the other is planning and reviewing (the copilot). It is especially easy to overwhelm your introvert partner when you find yourself in the copilot seat. As you are not focusing on the coding details, it is easy to see typing mistakes come up before the driver does. You may have comments about small things, like variable names. But as much as you want to, saying everything instantly is not the way to go, as you will break the driver’s flow, and may even come out sounding like a jerk.
This obviously does not mean that you should not help your driver out if he or she gets stuck, but rather that you should first give him or her a chance to figure it out by him or herself. Something that worked very well for me was keeping a pen and a paper nearby, and writing down my comments on it. After a few minutes, if the driver did not do it, I would then bring it up. And guess what: most of the time, I ended up not needing to.
That’s it! I hope this article will help you if you plan on trying out pair programming for the first time. T and I sure had a blast, and we learned a lot from each other. Besides, it felt really good to work with someone after so much time working alone. For those of you who lost motivation due to a long period of remote working, pair programming may just be what’s need to rekindle your spirits!
As always, shoot me a message or tweet @nicol4s_c if you want to chat about any of this, if you spotted any mistakes or typos, or if you’d like me to cover anything else! Have a great day :)