Pair Programming - Is it really effective??

So, I have been working in a "strict" pair programming environment for about 5 months now and this is the first project of my career in which I have been subjected to sit with another person for the whole 8-9 hours of the day while I (or he) codes. Also I have been pairing remotely for half of those days (half of our team is at onshore). I learnt these practices and principles while working with another vendor for the same client in Sydney, Australia.

Hence, I thought it will be a good idea to share my thoughts and experiences as well as point down the things which otherwise I have to re-iterate over and over for every person looking for advice from me before starting with this practice.
Note: All the points that will be mentioned here going forward are from my own personal experience and specific to the project I worked in. Though I think most of the dev community who has worked in this setup would second my opinion.

What is "pair programming"?

You must have already googled it up till now. So moving on...

Common terms used here : 

"Driver" - One who is having his ✋✋ on the keyboard for the moment.
"Navigator" - One who is just a spectator....?? No! One who is just reviewing the code on the fly?? Absolutely No! He/She is the one doing all of it while thinking of alternate ways as well as (as the name suggests) navigating whenever he sees a turn where the driver can make a mistake.

The "correct" way:

There are many ways people tend to follow pair programming, but I think it can only be effective when you follow these steps.

1. I cannot emphasize enough on the importance of communication between the pair. The driver is supposed to verbally explain whatever he/she is thinking while writing those precious lines of code. The navigator is supposed to patiently listen, question the driver on his approach and provide inputs when required.
   
   Remember: If the driver is supposedly a mute person (or someone who thinks action speaks better than words) and does not communicate while coding, then I am sorry you're not "pairing" but only wasting your and other person's time as well as precious developer hours.
2. Second most important thing I believe while pairing is context switching. If you're the only 2 developers of the "team"(poor you!), please skip to next point.
   
   
   But, if there are other devs in the team it is very important that people switch pairs as well as the module they are working on. Why? good thing you asked...
   Because it's a common human tendency that people get their minds synced if they work or be together for a long period of time. In that case the driver often knows what the navigator will be pointing towards next, which essentially makes the pair work like a single dev with a single mind and same approach. This make you lose the benefits of having a second opinion.
   Also if one dev is continually working on a module and pivoting with the second person for long without switching to work on something else then he will be spending most of his time explaining or sharing context with the new dev each day which becomes very frustrating after a period of time, and that would be the time when he/she thinks he can work faster alone.
3. Pairing even for trivial tasks. I have been suggested to work solo numerous times when the work in hand was very trivial or just a cosmetic change, but let me tell you - even when the task may look simple you never know which pesky semicolon can haunt you for an hour. Which is otherwise, though possible, but less likely. Also, sometimes the most trivial or tiny gears run the whole system.
4. Don't leave your pair alone. If you are working with another developer on something and feel the need to discuss something with the designer/product owner/business analyst or anyone else associated to the problem in hand, include your pair in that call/meeting. So that he/she can also gather some insights and may raise some useful questions or points which you may have skipped or forgotten about.
   
5. One of the motto of a company I worked with - "Always be kind". Keep your attitude and ego at home and come with an open mind. You may be "Usain Bolt" of programming but even you can make mistakes or learn something new.

Let's talk about some pros and cons:
Pros:

• On the fly (as well as kind of mandatory) code review. (I hereby admit to be guilty of pushing the code w/o code review - when urgently required, which is otherwise impossible while pairing).
• Better bonding with each of the team members. You learn from other people's strengths and help improve their weaknesses at the same time.
• Better sharing of knowledge as well as insights about handling a type of problem. For instance, I learnt all the shortcut keys of my IDE in just a couple of days by watching my pair use them. Also, I suggested an unconventional way of approaching a solution which was otherwise not looked upon.
  
• Way less distractions - Can't emphasize enough on this advantage. I am always so engaged while pairing that I almost forget to even check my phone and emails. This may sound bad to some, but believe me e-mails are one of the biggest distractions for a developer. Also, it will not look good if you check your emails or Facebook while your pair is watching your every move on the same screen - until it's very important.
• Less re-inventing the wheel - since each person in the team would have worked on all parts with almost every one, they may know whom to contact when in distress for one kind of problem.
• If you switch context enough then you may get to wear different hats with different people every time which makes work more interesting and hence productive.
• Even if a person has a scheduled long leave or is planning to leave the team, someone else will have context of whatever he did. So less knowledge transfer sessions required.

Cons:

• Hard to convince management that paying for 2 brains to work on the same problem is not bad! Believe me, I am still trying.
• Since, pairing demands continuous communication among the pair, it can be very very exhaustive. So, proper and frequent coffee breaks are mandatory.
• Very hard to pair remotely if you have a bad network connection. I had to add this specially because I never like to pair while I am working from home and my ISP is in a mood to get cursed.
• Require even number of people in the team, which is not always possible.
• Hard to pair if we have such a combination of persons:
• Both the persons do not have any idea how to approach the kind of problem they are tackling with.
• Both or any of the persons do not like to be verbal and prefer to work in isolation.
• One or both the persons get distracted very often due to calls, meetings or small breaks.
• Both or one of the pair have hatred for another person - which is quite possible sometimes.

Also, if your'e planning to try convincing your peers and/or managers in favor of pairing, this resource may help in the same. 

=> https://mrdias.com/pair-programming-slides/#1.

And if you want step by step guide for pair programming this will really help. 

=> https://www.wikihow.com/Pair-Program