Seven principles of pair programming etiquette
By: Juntao Qiu
Tags: Culture, Efficiency, Programming, Agile, Pair Programming

The Observer

On the other hand, as an observer, pairing is a great chance to learn from your peer, you should make the most of the experience. Such as short-cut usage, options for command line tools, or any other productive programming habits your peer has been using. Keep your focus and curiosity, when you see you peer magically delete all the content in brackets, or prettified the output from curl , don't hesitate to ask.

In practice, you can switch your role every test — code cycle. For example, A write a test, B code to make the test pass, and A do the refactor, then B write another test, and so on so forth.

Keep focusing

Once you decided what’s the problem to solve, you then need to do tasking. That can make sure you always focus on a small chunk and avoid the potential waste when you have to switch between context otherwise.

After each task, just cross it from the Post-it. Don’t overlook the power of tiny tick,. Firstly, it can easily visualize progress. Secondly, it could be a reminder when you were interrupted by a meeting or lunch. Finally, this small ritual could provide your brain with positive feedback, which can promote dopamine that can make you happy/enthusiastic.

However, in some extreme scenarios, when the conflict comes inevitable, we have to trade-off on some of the aspects and move on.

Deal with disagreement

When you have to pair with a stubborn colleague, and unfortunately you are someone that hard to convinced too, how would you handle inevitable arguments like this in the real world? Especially those arguments that cannot tell right or wrong explicitly. Like which programming language suit most in the Web application (Surely it’s PHP, I hear you), or how to do TDD properly (bottom-up or top-down) and so on.

In some situations, we insist something we genuinely believe and treat others who don’t think in the same way as pagans. Actually, it just takes a little more time to realize that they might be not that wrong, and it might make sense if we could see the problem rationally from another angle.

In the previous project, I have chosen scss module as the CSS preprocessor just because in the project just before this one I used it and found it pretty handy. While one of the colleagues purposed styled-component , we both didn't convince each other. So it ended up with both styles mixed in the codebase. Until one day, I found that component built on top of styled-component looks pretty neat, and after tried to refactor some components written by scss to styled-component , I found the code looks more concise and doesn't have any impact on existing tests.

Suddenly I realized that the truth I had been insisted is kind of ironic: that's just some fantasy I made up - just to keep using something familiar. Keep open mind is not that easy, and hope you can rethink the proposal you made when you find it's hard to convince others or be convinced.

For that hard-to-agree dilemmas, I suggest park it and try one of the approaches, until you find the flaw that would block the implementation of the business requirement. Usually, you will find some trade-off, and come up with a solution using advantages from both sides.

Tough tasks

Even for experienced developers, they might be facing tough problems, it could be a new domain with complicated business logic or some new challenges in a familiar domain. In some cases, both peers do not have any clue to get the problem solved. If you insist pairing in this stage, it actually makes it difficult and ineffectively.

One viable approach is to do some spike separately with limited time box, like 30 mins. In most cases, at least one of you would come up with some direction to start with. Otherwise, you might have to raise it as a technical risk to the whole team or the whole program.

For instance, we were facing an authentication issue about Kerberos recently, neither my peer nor myself had not ever touched that at all. After 20 mins separate spike, I found an informative article about a lot of details of the Kerberos authentication mechanism, and my peer found some existing code in internal GitHub (although in mild quality). We decided to copy that code instead of putting more effort into it and refactor it later on. And the article I found is something worth reading as an extension reading resource.

Set and control a right pace

Attention is actually the most precious resource, normally you can hardly focus on anything more than 30 minutes. After that, your brain would find something more interesting instead. A short break could make the brain refresh and rest. Our brain has a fascinating feature, seems it has a super ability to handle tasks in the background — and much more powerful than the foreground. Chances are you have already experienced a lot the aha moment when you just go downstairs for a flat white.

When you encountered some bugs that difficult to understand or stuck when setting up the testing suite, take a break might give you some inspiration in a different angle. To avoid immerse too deeply in a particular issue, you could use tools like tomato timer or similar tools:

Fetch a task from todo-list Set an uninterruptible tomato for 25 minutes and start working When time is up, task 5 minutes break Repeat step 2–3, take 15 minutes after 4 tomato s

Here is an online tomato-tool you can use, or you may want just to use the timer on your phone.

Switching pair

When always you pair with someone for a while, pair itself will turn to the information island. For example, A and B have been working on order module, while C and D have been working on store management, without doubt, after a certain period of time, A and B won't know what's C and D are working on. Not only the domain knowledge but also the technical details/design patterns, etc. When your team grows to a size like 10+, that will go even worse.

You should have some mechanism to ensure the rotation happens, like rotate pair twice a week or so, that can enable knowledge sharing across the team.

In some cases, the team adopts front-end and backend separation fashion. The tech stack in both ends may have nothing in common, that introduce potential challenges for rotation, and can reduce the productivity in a short-term. Things could be getting worse when Ops separated as an independent team.

In practice, I found that the benefit brought by rotation in different roles could lead much more far better than knowledge isolation. If frontend developer spends some time to pair with Ops , they could understand more how the application works in architecture level. And after pair with Ops , backend engineers could realize the potential defects and fix it even before the defect happened (For example, externalize the session storage, cache strategy, etc).

Respect your peer

As the smallest unit in all kinds of team level activities, you should always see things from your peers’ perspective. Try not to be the person you don’t want to pair with. For example, you hate someone focuses only about typing without care about if the peer is on the same page, or you don’t want to pair with someone always using the mouse to navigate files and less effective when typing, then you should try not to be that kind of person yourself.

Apart from this, respect is all in the details. When you have to leave during pairing for something else, make sure let your peer know. And apologize before you left, do not just vanish and show up several minutes later. No one wants to pair with someone that isn’t reliable. Furthermore, when your peer came back from a meeting, you should tell him/her what’s happening and how the progress like, and what are you trying to do next. Make sure you have the same understanding on the task on hand.

Control your emotion

Emotion is fairly an interesting thing, and it can easily propagate to others. When we got some blockers when trying to finish our task, or found it’s difficult to make any progress for some reasons out of our control, you have to learn how to control your emotion. It’s interesting when your peers whine next to you, then you tend to become frustrated as well, and hard to focus on problem-solving.

It’s crucial to find outside help and visualize the blockers. Let the team understand your situation and provide support if possible. Be proactive on the task itself and try not influent others by your negative emotions.

Do some homework

After a full and happy day, it’s your responsibility to summarise what you learned, that’s a perfect way to improve yourself and skill up. After applying what you learned from the real world, you can found your potential weakness and see how other solve it closely, and that might have a relatively profound impact to you, all of those are good for you.

For example, when you are quite comfortable with using grep to do full-text search, and noticed that awk looks more effective when your peers show some advantage of it. You can then learn it as homework when you get back, and try to use different options or compare with the tool you already familiar with. Another example could be you and your peer found some interesting feature about webpack when fixing some issue in daily work, but neither you understand the mechanism under the hood, that's a good opportunity to improve that particular part. Spend some extra time on those could make your looks better in next day's paring, and immerse into the fun (if any) of paring.

Those principles are fundamental, subtle and trivial. But do it well can make you and your peer comfortable and confident during paring, and hopefully could bring productive into your daily work.

Summary

In this article, I summarised some common patterns and solutions about paring. Before you even get started, make sure you have both hardware and software set up correctly and fit both of you. In order to be more productive when coding, you can use different IDE preferences. When your capability is unequal — that’s exactly when pairing can maximize its potential — not only the observer can retrieve most of the experience, but also for the driven, can learn something from a different perspective.

During paring, you should always focus on the task, and you might need tasking to help split the big task to parts, and resolve them one after another. Additionally, you should make a regular break during pairing, relax the tension now and then. To avoid information island on a larger scale, the team should rotate the pair periodically as well.

To summary, by applying those principles, it’s helpful for both individual and team in the long run, and promote everyone in the team works under a healthy atmosphere.