Pair Programming Antipatterns

Pair-Programmers in action!

For me pair programming is one of the most fun activities you get to do as a programmer. Also is not just fun, it is a great tool for knowledge sharing and team building. And actually it does improve productivity as opposed to what many wrongly believe. But sadly so many people hate it and also so many companies even actively discourage it or feel uncomfortable about it.

There are many points that often people use to attack pair-programming practitioners. I am going to just mention two of them before we move into the anti-patterns.

1)Even if is proven that pair programming can significantly reduce costs of; software licences, hardware, training and team building among others. Yet many companies see it as a “waste of human resources”. I meditated and thought about this in multiple occasions during my career and I reached to the conclusion that the underlaying motivation when this reason is given is often due to a huge fear of disruption and change.

2) Another thing that is often heard is the “it’s not for everybody” argument. They say some people are more introverted than others or sometimes, time away is needed to be able to think with more clarity and be able to solve the problem.

My opinion on this is that there are an enormous amount of people in the industry highly skilled technically but incapable of communicating efficiently and talking out their reasoning or trail of thought. People that lack social skill and fear or feel extremely uncomfortable with social interaction.

So yes, the human resources and recruitment teams(specially agencies) in many occasions just aim for “the best” technically skilled but they completely disregard the communication and social skill aspect that is required for team work. Unfortunately it is called Pair Programming but if it was called Pair Problem Solving this would hint that is not just the technical skill that is needed.

Those two are not the only points that you will hear against Pair Programming, there are many others. I would happily debate all of them but I want to move into the anti-patterns, because understanding them and reflecting on them I think can help understanding what are those blockers to successfully implement Pair-Programming.

It is not a difficult technique to put in practice but to make the most of it we should be careful how we approach it, how our setup looks like and how do others around us support the effort to transition into it. Is not uncommon that in occasions a team tries pair programming for first time but they approach it from a wrong angle and sadly they end up hating it or at least forming a wrong impression of it.

Hopefully understanding some of this anti-patters can help the team avoid having a traumatic experience when trying to transition into pair programming and likely avoid the formation of wrong opinions such as the two ones I mentioned previously.

Factors that can influence pair programming
Efficient Pair Programming depends on many factors. Depending on those factors some of which are:

• technical(a.k.a practical): this are things at low level when pairing. Things that involve you and your pair. The way you interact with each other and how you adapt to each other.
• environmental: factors that have to do with your immediate surroundings that have the potential to stand on the way of your pairing.
• organisational: factors that have to do with your company and it’s views on agile or certain aspects of pairing that either consciously or unconsciously present a difficulty to the implementation of pairing.
• psychological: set of factors or also commonly thoughts or states of mind that act as forces that can affect the quality of the pairing experience.

So without anymore hesitation, let’s have a look at the Anti-Patterns.

Lone thinkers.
If one of the pair members says “Give me some time to think and I will get back to you”, here we are not longer in a pair. We are not solving the problem collectively.

This just means that the pair is not familiar on using collective problem solving skills and techniques. Yes they will break apart and each of them will “individually” come up with some viable solution that then will be discussed, etc … But that is not team work. The problem was not collectively solved.

Solution:
Practice pair/collective analysis and/or pair/collective problem solving skills to help the pair overcome blockers as a pair and enhance pair/collective learning.

Desk nostalgia
True pair programmers don’t have “their desk” they both sit together at the same desk. There will be two mice, two keyboards and maybe 2 screens but one single CPU.

If there are two CPU’s then this is no longer Pair-Programming and the risk of the Pair-Breaking apart is higher. Of course remote pair programmers will have a CPU each and use screen sharing technology to drive and navigate but it will require from them discipline to avoid going on a tangent and breakaway.

Solution:
Stop buying so much hardware, software and desks. If the team is distributed get some good screen sharing software that allows the pair programmers to draw, highlight, etc …

Clueless navigator
The Navigator is in the observer position, while the driver is typing. He/She reviews the code on-the-go, gives directions and shares thoughts.
The navigator also has an eye on the larger issues, bugs, and makes notes of potential next steps or obstacles.

The idea of this role division is to have two different perspectives on the code. The driver’s thinking is supposed to be more tactical, thinking about the details, the lines of code at hand. The navigator can think more strategically in their observing role and will have the big picture in mind. The navigator also reviews code on the go to make sure it adheres to teams conventions, gives directions, take notes, warns about potential issues and shares thoughts.
So as you see the navigator needs to be experienced and familiar with the system and that’s why in Pair Programming it’s advised that when someone is new in a team, that person takes the driver seat instead of the navigator seat.

“Clueless Navigators” can easily occur when a new joiner is placed into the navigators seat or when two new joiners are sit together. The navigator will be unable to guide the driver towards important locations due to lack of experience. If is the experience member that is driving, the inexperience navigator will just end up sitting there saying “aha”, “hmm”, “ok”. And if the two of them were unexperienced new joiners probably it will end in some kind of frustrated collaborative research with likely frequent interruptions of other team members.

Many companies sadly have their “best senior” developers often
busy with no time to do things like Pair Programming until the “busy period” passes(but that never happens), so they just put the new inexperienced joiners together to figure things out but this actually ends up causing more bottle neck due to frequent interruptions.

Solution:
Make sure that the most experience individuals take part in Pair Programming and don’t let less experienced team members be navigators until they feel confident enough. It depends on different factors but often
a new joiner should be ready to try a first attempt to navigate after 3 or four stories being implemented.

Narcissistic process
Sometimes when some people that are new Pair Programming at the beginning have the feeling that they are being judged. As the new driver is pointed here and there by the navigator he starts saying things like, “I know that”, “I didn’t write that”, “this was like this already”, “someone else did this”, etc … Feeling judged is not unusual among new Pair Programmers. This is something that with time it just disappears as the team bounds more and more and everybody develops a collective sense of responsibility and ownership. But in occasions some processes and tools that are being used encourage the development of a self cantered/egoist attitude towards development which makes it hard to implement pair programming. This are little details that often are unnoticed. For example the language used during stand-up meetings should not hint or give the feeling that something that happened is someone's fault or an attitude of “throwing over the wall”. This little things are against the agile principles of shared ownership and shared responsibility. While it is ok to criticize someone's work that needs to be done better, the emphasize that something is someone’s fault rather than the team’s fault can be harmful when we try to implement Pair-Programming since continuously new team members will fill either judged or hesitant.

Also some of the tools we use such as JIRA in occasions are restricting us because unless certain features are enabled, shared ownership of tasks is not possible. In most companies it is always one persons face against each task displayed on the board. Business love to ask “who owns that”? And they expect the answer to be someone’s name rather than a team.

As you see Pair Programming is a collective effort but if while we are trying to build this collective effort the environment and tools around us should not encourage us to be individualists. In summary the Narcissistic process antipattern one way or another englobes anything in the software process that is against the principles of shared ownership and shared responsibility.

Solution
Use retrospectives to discuss the concepts of Agile and specially the meaning of share ownership and shared responsibility in each of the steps from ideation to the product is in the user’s hand.

Sweating
Offices with big open spaces often cause discussions about the aircon and/or heating system. People keep complaining about it, “too hot”, “too cold”, etc …

But if you are working on a pair and there’s no issue with the heating and you often sweat, then probably you are sitting too close together or even touching chairs. Maybe your pair will tell you now and then “please can you move over a bit”.

Solution
Tell your manager or team lead to buy a second keyboard, mouse and monitor so that you don’t have to sit so close to your pair that you touch chairs. If the issue persist, check with a doctor.

Distraction domino
One of the advantages of pair programming is that one particular task never stopes from being worked on. A pair that for some reason is interrupted, let’s say somebody comes to ask something or a personal phone call, etc.. does not need to stop, is enough if one of the team members addresses the temporary situation. Distraction domino is a situation in which the attention of both pair members is taken by an external factor.

Solution
If you are a navigator and someone comes and is likely to interrupt, protect the driver by taking the question. If the drivers phone rings and the call is really important, the navigator should temporarily take control while the driver answers the phone.

No team DJ
Another reason why many people hate pair programming is because they don’t get to listen to music while they code. If the team feels for listening to music, they should be able to. Pair programming does allow music, but it doesn’t allow headphones. Of course the team needs to make a suitable play list that everybody agrees upon during a retrospective. If the team is in a large open space, be aware of the surroundings and nearby teams, always ask the team/s near by. But best is when the team has the whole room for itself of the space is big enough so that music at low volume will not disturb nearby teams.

Solution
During a retro or a team meeting agree on music genre the team would like to listen too. Also agree on music times, that everyone is happy with. Also relocate the teams desks further away if you think is necessary and possible.
Talk to the teams nearby about turning on music and test the volumes by asking if does it bother them.

Fear of driving

This is very common among new practitioners. Once at the driver seat, some are confused and fearful of what to do, what to say. This is all perfectly normal, the important thing is that questions and thoughts are exchanged rather than sit in silence and wait for instructions. Get the fear of driving away buy building a bond with the navigator. Learning to understand his way of speaking and pace. Keep asking questions and take your time to perform actions and evaluate feedback.

Sometimes fear of driving can lead to “you do it please” and while that’s ok maybe at the beginning, it should be discouraged. The navigator should be able to do it’s role without touching the keyboard and by doing and touching the keys the driver should gradually absorb knowledge. If you are fearful when driving, try to avoid “you do it please”, instead just take your time to think reflect, stop if you need, think about the question that was formulated and re-formulate it if necessary. The navigator should be patient and understanding.

Pair Programming is a very powerful learning tool but to use it to it’s maximal potential, the attitude of both driver and navigator need to be the right one. Also the attitude of the company is important. As I already mentioned, many companies feel that learning time is a waste of time. Yes it’s true that delivery is important to deliver but also building a strong and capable team is probably even more important. This companies don’t understand that if their “best ones“ get “hit by the bus”, their business could be in serious trouble. Pair programming can mitigate this risk easily.

Solution
This just takes time but also remember that the best recipe to ease the fear is communication. Talk with the navigator, communicate, keep asking things and together discover the pace that works for you. Also remember that the driver should avoid the temptation to say “can you do it please?”.

Quitters
Sooner or later the pair will get to some kind of road block or they will get their wheels stuck in the mud. When this happen there are multiple things important to remember that can help resolve the situation as a pair.

First slow the tempo or even stop and ask yourselves, do we feel stuck?
If the answer is yes, then review what were the last few steps and why were done. Formulate questions and share thoughts about what is happening.

Sometimes the blockers are highly technical, for example an stack trace that at first glace doesn’t make sense or maybe an unexpected response from a dependant system etc … It is important in this situation the pair continues to communicate. A question will maybe not be answering but may lead to a hypothesis and the validation of it through experimentation could provide the answer. Quitting in the sense of splitting to think and then come back should be discouraged. A pair should get to a point in which is not feeling uncomfortable about “the other” presence. Gradually and with time will understand that “not knowing” something is perfectly fine.

When hitting a road-block, in my opinion thoughts such as “what would others think of me?” or “am I good enough?” in most occasions will lead to the next step or thought(instinctively) which is, “I don’t feel comfortable, I want to quit!”.

The quitter mind set is a huge anti-pattern that repeats a lot and ends up destroying the pairing experience and practice.

It is enough for new pair or team trying for first time pair-programming, to encounter itself in this situation just once or twice, to start questioning things like “if I am going to separate from my pair to fix the problem anyway, then why I am even pairing at all?. I could just do this myself”.

Exactly why are we pairing if we are going to have to split? That’s a huge mistake that we hear again and again in companies, interviews, meetings … etc. “If we need to think, we step away and then we come back”.

Wrong!!!

Solution
Don’t quit and abandon your pair. Stay with your pair no matter what. If something about him/her annoys you or makes you uncomfortable, kindly ask. For example, if the person talks too fast and you get lost on what they say, ask them to talk slower. Pairing serves as team building exercise. So splitting because some people don’t feel comfortable or because by his own will lead to a better solution, is not good. It just shows that the team has some sort of seam. To patch those seams we use communication and cooperation. Pair programming is a tool to help us with this.
Also another interesting thing that some teams do in order to improve the adoption of pair-programming is after a session or a couple of sessions they do a survey with questions about their feelings and then share to each other. This is a great way of learning about the other person and probably have a better session the next time.

I pair and I pair, but I am still stupid
“Wasn’t pair programming supposedly going to help us with knowledge sharing? But look Peter still doesn’t know anything about microservice XYZ and he is being here for 6 months.”

Sadly most companies have are interested or focus on the performance of the individual rather than the performance of the team. There’s a continuous search in many companies for the accountable person. All gravitates around the individual.

While poor Peter had done his best, he ends up being judged and performance reviewed based on a little dispute he had on the last couple of weeks around some coding principle or by not knowing how to solve some edge case in some obscure microservice that was just touch once or twice in the last 3 years.

Here’s the thing, pair programming will help acquiring knowledge faster but the knowledge is distributed knowledge. Some of this knowledge lives in my head some other in your head. With time it is gradually transferred but even if not all knowledge is fully transferred 100% to every single team member, it doesn’t really matter because continuous pairing will transfer the enough knowledge to enough heads so that the team and the pairs on the team will have enough distributed knowledge to solve a problem or perform a task.

Solution
Stop with the judgements. Always think that we all work to the best of our ability and don’t criticize others about what they know or they don’t. Think as a team and replace the “I am” with “We are”.

Understand that the knowledge will always to a higher or lower degree will be distributed. Continue to do retrospectives and rotating the pairs and the type of tasks that the pairs do. Sometimes a bug, sometimes a spike, sometimes a story, etc …

Every few months 3 or 6 have a meeting to evaluate the situation of the team in regards to knowledge transfer. But don’t just focus of how much do we know about XYZ or ABC, question yourselves how resilient the team is?. What would happen if one person would be gone? How will the pairing look like? Will we be able to overcome blockers, etc … It pairing is going well then gradually the team should feel more and more confident when it comes to knowledge.

Cannibalisation
It is hard to build a team if now and then cannibals come and take some of your colleagues and bring them to other teams. This is a huge managerial mistake that causes a lot of damage to teams and companies. This antipattern happens in so many flavours that is just almost impossible to detect.

Some examples of cannibals:

• Some manager or team lead or whomever says something on the lines of: “our team is doing great, the CTO congratulated us and said that in order to spread some of our good practices we will move person xxx to another team that needs help”.
• A very important person in the company says: “A brand new product needs to hit the market before Xmas. We need to assembly a team but HR will need more time that what we currently have. So we have being already talking(secretively of course) with some of you who will join that team”.
• The product owner of the other comes and tells us: “We would like to borrow one of you temporarily”.

You see? Those above are just some of the many ingredients that can be used in disaster recipes.

Good teams that use pair-programming have a certain degree of resilience and tolerance to the fact that one team member at some point will leave, that suddenly unannouncedly a bunch of new people will join or that something unexpected may happen. Pair programming will of course help mitigating and minimising a lot of the disruption that such events may cause. But pair programming is not a silver bullet, if you have the wrong company managerial culture and this events don't happen at a manageable, planned and agreed in advance pace that the team can absorb, there will be negative consequences for sure.

Solution
Protect the team no mater who the Cannibal is. Tell them “no, we are sorry it took us a long path to get to where we are.” If they insist tell them that their actions will harm the company. If yet they don’t care and they do it, raise awareness and raise your voice to other teams about how Cannibalisation has damaged a well performing team.

Sadly cases of cannibalisation of teams are not uncommon in large firms. It can be very difficult to stop and prevent. What begins a bit unnoticed as a one-of practice ends up becoming a bad managerial habit that harms seriously the company.

Do your best to fight it back by any means you have.

Driving fast
In pair programming there’s no speed limit, you can type as fast as you can. You can open and close browser windows and terminals and drag things here and there at light speed. All this is perfectly fine. As long as your pair can follow you. Both driver and Navigator need to be able to understand what is happening. If someone just went too fast and the other person didn’t understand, slowing down is needed.

Solution
The navigator should tell to the driver to slow down if is unable to follow due to driving very fast.

Deaf Driver
If the navigator is saying something and the driver is completely ignoring it and going in a tangent, the navigator needs to stop the driver and ask him what is he doing. What is being done should continuously be communicated and rationalised. A driver not wanting to listen to the navigator just shows lack of discipline.

Solution
The driver and navigator should communicate efficiently and agree on what is the next thing that is going to be happening. If the driver wants to play deaf and keeps saying, “just one sec”, “one moment let me check something”, etc …
This situation is quite common with people that are new to pair programming. If the navigator feels is not being heard, he/she should voice it otherwise the pairing with time if this situation happens too often will become ineffective.

Too many shadows
The shadowing technique is a technique in which one of the pairs both drives and navigate at the same time(does everything) and the other one watches. While it is ok for a more experience team member to explain something to a new joiner using the shadowing technique, if this is done all the time this will have a negative counter effect.

The learning takes place through practice and it is important that the amount shadowing is reduced to the minimum only when strictly necessary. If somebody that is new or less experience is just sitting back looking at the screen, that will not teach him/her as much as if he/she was to be in the driver seat.

This is also a very frequent wrong practice and often occurs because the most experience developer is in a rush because wants to complete the sprint goals or there’s no time.

Solution
The driver should drive and the navigator should navigate. Keep shadowing to the minimum or even try avoiding it. If you find yourself relying too much on shadowing, question yourselves why that is. If necessary raise in the retrospective that you think pairing is not effective since we are always in a rush and you don’t get to drive much.

Silent driver
Sometimes when beginning pairing some people think that the only one who needs to talk is the navigator. That’s not the case. The driver should also talk and not just be silent waiting for some sort of instruction. The driver will likely talk less but should not remain completely silent. It is important that the thought process and the current action that is taking place on the screen is communicated. The driver should say things like “ok now I am going to check on the database”, “this is the value coming through I can see in the debugger”, etc … If you see a navigator very frequently say “and what are you doing now?”, it could mean that the driver is just too silent.

Solution
Ask the driver to talk and word his actions and thoughts even if is just a repetition of what the navigator just said. Even if is unneeded, wording the thoughts and actions is good feedback for the navigator that they are on the right course, doing what it’s being agreed.

Think of a hospitals operation room. The experience old doctor is giving instructions to a young surgeon how to do a heart bypass. Both sides communication is extremely important even if is repetition.

Blitz navigation
They say, if you drink don’t drive but also you shouldn’t navigate. If a navigator for whatever reason is not capable of communicating at a pace that the driver can understand and reason, then the pairing will not be effective. If the driver thinks the navigator is explaining things to quickly or jumping from one topic to another too quickly, it is necessary to tell to the navigator things like: “please can you repeat that?”, “I don’t know what you mean can you explain me again?”. Is not rare to see navigators getting frustrated because the drivers don’t act as fast as they are expecting. This is dangerous because could lead to bad habits such as the navigator frequently taking over. If the navigator drives too quickly, gets frustrated and then takes over, this is a case of Blitz navigation. Sometimes happens deliberately and is a great way of ruining the pairing experience. Makes feel the driver useless for not being able to do things quick and there’s no learning since the driver now just seats back and shadows.

Solution
Again this can be prevented with effective communication but also with a patient attitude. The pace or speed needs to be the one that both are comfortable with. Maybe the driver doesn’t understand certain things and has some knowledge gaps or maybe just didn’t sleep enough hours. The navigator should be patient.

Don’t be a nerd
While it’s interesting and useful to sometimes quote some things from some book or something that some Java hero said once. It is extremely important to keep the ego at bay. No need to show off or act as a nerd. If what you say you think is going to contribute positively to the pairing session say it but if you are just doing it for your own ego, then avoid this. A pairing session involves a lot of talking but is not a theoretical lecture on philosophy of software. Don’t get me wrong, it’s fine to talk about theories, principles, best practices, articles etc … But try to be self-aware if you are digressing too much from the current goal at hand. Also listen to the feedback as you talk and ask if is ok to digress into a certain topic because you think is necessary.

Solution
Be self aware of what you are saying and if it’s on topic or you are digressing into something irrelevant. It’s ok to digress sometimes but ask your colleague if that’s something that talking about will benefit the pairing session. Also keep the ego at bay and don’t rebate a point on a subject that is irrelevant or off topic.

Not checking the mirror
The first thing we need to do before start driving is to check our mirrors. When we do pair programming we need to do the same. As a pair, depending on what kind of screen we have we need to decide if we want to use a mirrored monitor or we want to stick to the split view. Some people prefer to always look straight, it helps them with posture and also with thinking. Apparently some of us cannot think the same way if our head is turned to one side.

Solution
Try using a mirrored display approach to pairing and see how do you like it. Talk with your pair about which kind of display you prefer, play around with different options and observe how each influences your pairing experience. Choose what you feel more comfortable with.

Whispering
When pairing there’s no need to shout or talking too loud but what shouldn’t be happening is, your pair shouldn’t be telling you every now and then “I am sorry I can’t hear you, can you please repeat?”. If this happens too often, either someone has a hearing problem or someone is talking too loud. Also it can be that there’s a lot of background noise. The solution may vary but the important thing is too identify the exact root cause.

Solution
If there’s a lot of background noise in the open space that impedes you from hearing to your pair. You should raise this with your manager and this should be addressed, perhaps placing a sign, relocating the desks or setting some quiet time if none of the previous options are possible.

If you feel that you can’t hear what your pair says because you feel is whispering, check with a third team member and ask if they also feel like the person is whispering. If this is the case then kindly ask to the person to talk a bit louder so that you can all hear better. But if this is not the case, consider monitoring this issue and perhaps ask a doctor to do an audiometry test to you to asses if you need some kind of hearing aid.

Mumbling
As with whispering, mumbling also can lead to some difficulties when pairing. Some of us are quite extroverted and tend to think out loud but when the thoughts are not fully crafted yet it seems that we are speaking half sentences or mumbling. This makes us look doubtful or confused. It’s important to raise this or try to be aware of it.

Solution
If our pair tells us that we mumble we need to try to either explain them that we often talk out loud when thinking and that sometimes we have a tendency to mumble a bit or maybe we can try to train our awareness about it to try to have it under control. An interesting practical approach is when ever we feel tempted to say something but the thought process is not yet complete try to instead of speaking it out loud, write it down. Sometimes mumbling is a sign of impulsive character but in most cases with pairing it corrects by itself after a few sessions.

Headphones
Pairing with headphones, looks like an stupid thing to do, and yes it is probably one of the stupidest antipattern that you would encounter. It is a bit extreme but believe it or not there are cases of this. Yes there could be in occasions people so inconsiderate and egoistic that even if someone is trying to not even pair, but just shadow to see if they can understand something, they keep their headphones on. The only way to interact with them is by tapping them on the shoulder but even then they might not like it and feel their private space is invaded.

But wait a second, there’s one way in which headphones can be used for pairing. Can you guess? Exactly, to talk to each other if there’s a lot of background noise. Is important that the headphones both have a noise cancelling feature and a microphone. This is actually quite cool if you use it along side a mirrored screen, the pairing is quite immersive.

Of course this is just a useful tip if you find yourself in a busy office but if you are comfortably pairing remotely from the comfort of your own house you don’t have this kind of problems at all.

Solution
If it happens that you encounter an egoistic person that cannot be bother to explain or interact with you and you feel you are just sitting on the back seat without learning nor contributing, then tell them that you would like to interact more and you feel that is not appropriate to wear headphones on a pairing or shadowing session. If they don’t seem to care just walk away and talk to your manager about it. For some of the readers this is probably obvious but maybe some of the readers are new to the industry and I think they should know that this is not acceptable behaviour.

If you have a lot of noise in the office and you feel your pairing is negatively impacted by eat. Consider proposing to your pair using headphones and communicating via voice call while seating next to each other. Hopefully you will be able to buy a couple of really expensive headsets with the best features at the expense of your company.

Out of sync agendas
Imagine a developer is working on a feature but all of the sudden he is called to resolve some really urgent incident. Pair programming provides the team with a certain degree of resilience so that work can be continued even if one of the members is taken out of action.

But this capacity should not be misused for reasons that are not urgent. Let’s say we have a very busy agenda and we cannot do pairing, then we shouldn’t be doing it. Ideally only those people that can sync their agendas for the day or the time agreed should be doing pairing. If you know you are going to start a pairing session but in 20 minutes you are going to have 3 meetings in a row, you shouldn’t be pairing, someone else should pair.

Another interesting thing is that when practicing pair programming the team needs to be aware that alignment on lunch time and probably some other interruptions will be required. So it is expected that the pair agree at which time they want to have their lunch break.

It is beneficial if the pair splits only when it is strictly necessary. Having lunch at different times is not an strictly necessary reason to split the pair. But also is not considered an extremely bad practice. In my opinion it should be avoided, because it could potentially decrease the acquired knowledge, one of the pairs could miss out on something important. If while at lunch one of the pair remains working but is called for another incident, when the colleague comes back, he won’t know where his colleague went and also could find difficult resuming if the code was left in the middle of something.

Solution
With your pair before starting draft your plan for the day, be aware of when each others meetings will take place and avoid or postpone pairing if there are going to be lot’s of interruptions expected. Also if you can agree on the time when you will go for lunch.

Agree on the go with your pair about any pause or little break both of you may need such as getting a snack, toilet, etc …

Finally if one of the team members gets tired or needs a rest at different frequency, maybe using the “Pomodoro” technique could be beneficial and make you more productive and last longer focussed.

No swapping seats
It’s important to alternate between driving and navigating. You can agree with your pair when to swap seats. If we just stick to one role we won’t maximise the learning benefits that pairing gives us. Remember I mentioned already that the least experienced member will take the driver’s seat but as soon as possible it will be desirable to start swapping.

Solution
Agree with your pair when to swap seats. A day in the life of a programmer is never identical, each day has different challenges so for that reason it would be beneficial to swap seats at least once in each pairing session so that both of you get to experience a bit of driving and a bit of navigation.

Forgetting how to play Ping Pong
Some teams like practicing TDD(Test Driven Development), this a very beneficial practice in which tests are written before the implementation. TDD helps improving quality and also the design of our code. When a pair decided to do TDD, there a common practice used called ping-pong pair programming. In this technique the roles of driver and navigator are parked aside and what the pair does is exchange the keyboard following the tempo of TDD. This means that one member will write a test(red), the other team member will do the minimum to make the test pass and then will write another failing test for his colleague. The pair will alternate the roles of writing the test, implementing and refactor. This is a great exercise to collaboratively solve a problem and also improve the TDD skill.

It is not rare to see how a pair that is using driver-navigator technique to find it’s way around the code at the moment they stumble appoint a chunky piece of code they need to write, two things happen:
- they don’t consider using TDD and
- they use TDD they don't swap roles

Solution
When you need to write a new piece of code and you have managed to navigate to the place where the implementation should go. Propose to your pair to play ping-pong. Follow the TDD methodology and alternate roles.

Alfa typing
Imagine you are driving at a normal pace but your pair get’s impatient and tells you. “Just let me do it, we will end faster”. Even if there was a deadline, the navigator should continue to navigate or improve it’s speech so that the driver can understand easy, but just saying that is not appropriate. It just shows that learning and improving is not a priority. Basically you are just saying to your pair to sit on the back seat while you rush through the implementation because you are in a rush.

Sometimes this could be just impatience but many times is just lack of overall team organisation that ends up creating a feeling of urgency. When this happens pairing starts being effective due to Alfa typing re-occurring.

Solution
Focus on the task at hands not on the clock. If someone asks when is this going to be ready just say that is currently Work in Progress. If they get snappy or too inquisitive, say that you are working on it and it will be ready when it will be ready. Don’t stress about external pressures, because 99.9% of times estimations are inaccurate. Focus on the task with your pair and try to learn as much as you can.

Performance anxiety
Some people have a huge fear of their performance reviews, their managers or even they have continuously in the back of their heads the fear of being fired. This lack of control of their fear can create unnecessary urgency that can ruin the pairing experience.

To have a safe and healthy pairing experience the team and it’s members should be free from pleasure that will make them urge.

Also sometimes part of the anxiety can be created due to the the lack of transparency with the non-technical side of the team regarding the fact that they are going to be pairing. This creates a lot of anxiety in occasions because people don’t understand how they will be evaluated for performance many feel they will not get a promotion if they do pairing because it could be seen as they don’t know to work on their own.

Solution
To remove this fear from the team make it official and let everyone know that the team’s policy is to always do pair programming. Team members should be supportive and always give honest feedback to each other after pairing sessions. This feedback and acknowledging on strengths and weaknesses will help individuals improve.

Undercover Pairing
It is not shameful to ask someone to pair. It is not a sign of weakness nor an act of laziness. Those who wish pairing but in many occasions feel their teams or companies reject the idea, often do it because they feel something is wrong in the team and they seek improving the teamwork dynamics and also decentralise the knowledge that is often held within a few individuals.

Sometimes they pair in secret but they know their team or managers don’t approve it.

Solution
You should be proud about wanting to be a pair programmer, don’t hide your desire to help your team by practicing pair programming. If you see some manager or somebody keeps putting down your suggestions, tell them about the benefits of pairing. Or even better tell them about the drawbacks of not pairing.

Stop pretending you like it
Some people just don’t like it. But why? Just because they don’t. No matter what you do, you won’t convince them. If you have a few persons like this on the team or among the managers, it is going to be really, really difficult to try to get the team to do pair programming.

Solution
The solution actually starts in the recruitment process. You have to honestly ask the candidates if they would be comfortable pair-programming on daily bases. If the answer is no, then don’t hire them. Pair programming is a technique but is also a skill and as such it’s important to keep doing it all the time. Just doing paring once in a blue moon, doesn’t really bring much. The teams that make the most from pair programming are the once that have accepted it as a policy and practice it on daily basis.

Jira doesn’t support pair programming
On the lines of supporting the pair programming effort of the team, the environment and also the tools we use should be compatible with pairing. One example to illustrate this antipattern is when in JIRA the pair is not allowed to assign more than one person at the same time to a ticket.

This is quite frustrating because starts generating a subconscious feeling of lack of transparency in the team. The ownership is not shared and also looks like one of the members is doing nothing since nothing is “assigned”.

Agile teaches us that we should all share the ownerships and responsibilities.

Solution
You need to ask to your JIRA experts or admins to enable the feature that allows for more than one person to be assigned to the same ticket. If they tell you that the business above is not flexible with the JIRA layout, then you need to tell them that everyone should be aware that this team wants to do pair programming and that the JIRA board should be reflecting it

Re-Reviewing and branching
One of the benefits of pair programming is that big part of the continuous integration process is already embedded. If you are pairing you are already continuously performing a review. So you are safe to skip the classical step of code review. This can sound radical but the risk of skipping review when pairing is quite low. When people review code they need to put themselves into your shoes, check out the branch, read the ticket and context switch to perform the review. But in reality most of reviews are not that exhaustive because many reasons such as urgency or context switching complexity.

So there you go, pair programming can have your code reviewed on the go and this will speed up the process. Also since you are not in need for a code reviewer, if you feel brave enough, you can just practice trunk based development. Since there’s no really point on making a branch if the pair is doing an ongoing review as feature it’s being coded.

Solution
Talk with the team about why are you reviewing the code before merging it if you are already pair programming. Also ask to the team if branches are still needed.

Not using Pairing-Stairs
In order to make sure that the knowledge is shared across the team, it’s important to make a good pairing rota. A good pairing rota should be able allow us to swap pairs without disruption or lose of context. A commonly used approach is called pairing stairs.

Pairing stairs

Pairing stairs is just a diagram that teams often use during their briefing meeting to keep track of who has already paired with who. The diagram helps the team visualise who has already paired so swaps can take place. The team members will just draw a line each time the complete a pairing session with a colleague. In image we can see that Peter and Mark have paired twice while Alice and Susan just paired once. This board will give them awareness and will provide them the flexibility to agree and manage their pairing sessions.

Solution
Pairing stairs are a common practice to visualise who has paired with who and avoid repetitions. But note that while pair stairs allow you to visualise, they don’t really visually display who is the champion in the story nor they enforce a strict order.

No champions
When there’s a pair swap but the task is not completed, if both members leave the task and they just do a handover to another pair, this would cause confusion and waste of time. It is important that when you are pairing but a swap is required, if the task is not completed one of the members should stay and become the champion of the story.

Solution
Don’t fully handover an incomplete task when pairing. Instead one of the members of the pair should stay and “champion” the story. The member that stays should be the one that joined the task the latest.

Lack of understanding of Time rotation vs Feature rotation
Pair stairs tell us how to change pairs but they don’t tell us when to change.
There are two main styles of pair swap:

- Time based: once a certain amount of agreed time passes all the pair swap(following the pair stair)

- Feature based: the completion of a task by one pair triggers a pair swap even if another team did not complete yet it’s task.

Both styles are interesting are similar and both are beneficial.
The time based approach will teach the pair how to work on a deadline. Since we know how much time there’s left we should be able to plan accordingly knowing that one of the team members will be leaving the pair.

The feature based approach allows to at least one of the pairs to have the chance to fully complete a task/feature. But also can catch the other pair off-guard. So it’s a good exercise for the pair always be ready to expect the unexpected(swap event).

Solution
If your team is already pair programming but not putting into practice any particular pair rotation, consider implementing either a time based swap or a feature based swap. Play with the different times and sizes of the features and see what your time likes more. It’s likely that most beginning pair programming teams will use a feature based swap and the time between completion and swap will be used to slack a bit. This is fine but try to start building resilience into your team by implementing one of the two swap strategies.

This is just a experiment
A very common anti-pattern in many teams that are completely new to pair programming is to take it as an experiment with a limited boundary. For example they say, now only half of the team will pair and the other half won’t. In such situation pair-programming full benefits will not be unleashed. It needs to be put into practice by the whole team for a reasonable amount of time to start seeing it’s benefits. Doing pair programming for a day or a sprint is unlikely will change much in your team, but doing it consistently for a few months having in mind the best practices and also being aware of the anti-patterns can definitely have a more positive effect in the team.

Solution
If you are going to do pair-programming make sure that the whole team is committed to it and you have agreed to do it for at least a decent amount of time(e.g 3 — 6 months). That way for sure you will start making the most out of it and benefits will start to be noticed.

Not Pairing with other teams
Many times teams even if well built, can still live in a silo within the organisation. It is a good practice to sometimes invite members from other teams to pair together. This is a good way of making connections with other teams and also increasing the understanding of other systems around us.

Solution
If more than one team already has build some degree of dexterity and discipline with pairing consider swapping pairs across teams using the pairing stairs but include two teams in the pairing stair. In an ideal world if this was to be done frequently both teams would become completely capable to work in each other tickets. It has the potential of creating cross-functional teams if used correctly. This could be extremely beneficial for an organisation if multiple teams get to this point thanks to pairing.

No good remote pairing software
Even if a team is distributed remotely, pairing is still possible but good software is required. Pairing without screen sharing is practically impossible. When starting to pair make sure that you share screen. Also some editors allow collaborative live editing of source code files, if you have this kind of software, don’t hesitate in using it.

Solution
Use all the tools at your disposal to enable remote pairing. Don’t just rely on voice, make sure you have a way of seeing the other person’s screen.

More important task
This is a classic antipattern that sometimes happens in teams where certain people(often managers) cannot grasp the concept of pull based development. They feel they need to assign always someone to some story instead of letting the team self manage itself. In this kind of situations if somebody attempts to do pairing, it’s frequent that the pair ends up breaking up just because one of the members is afraid to fail to complete “some more important task” that is assigned before the deadline.

It’s really strange and also irrational when in a team or even a whole company the overall attitude is pure individualism. In this kind of places the performance of the team is secondary, what is important is the performance of the individual. Sometimes they don’t care if a ticket is not well groomed or how things will be tested. Just a mindset of throwing things over the wall.

This doesn’t help with pairing, it is very rare to see people because they feel managers are going to considered them week or “non-seniors”. When we are in such irrational environment we don’t really have much option.

Solution
When surrounded by a very irrational and individualistic environments where is clearly observable that the managers just pursuit their individual goals and disregard anything that causes even a bit of disruption, attempting to pair is a very far fetched goal that can probably just get you into trouble with some manager that has probably no clue about what Agile even is.

The best thing to do if you still want to work in that place is to try finding allies but not just on your team try exploring around the company and talk with other managers and see what are their views first on Agile and then on Pairing. If you find someone that brings you a bit of hope, find the way to join their team and once there you will be hopefully in a better position to influence about pair-programming and also Agile.