You might think it's like this:

What is pair programming and what does it actually look like?

1. One Station, Two Developers

• One Keyboard, One Monitor, One Mouse

2. One Driver

• The developer that writes code

3. One Navigator

• The developer that observes, proofreads, and strategizes where to go next, anticipates future problems.

4. These roles should switch throughout the working day.

5. Pairs should be actively code-reviewing and catching bugs.

IMPORTANT: Not to be confused with PARTNER Programming

• Two partners work side by side and collaborate on the same project.

Advantages of pair programming

1) Career

• In house built mentorship program
• Junior engineers quickly ramp up to Senior level
• Senior level taught new ideas/approaches
• Work flow synergy throughout team

2) Teamwork

• In an online survey of pair programmers from 2000, 96% of them stated that they enjoyed their work more than when they programmed alone and 95% said that they were more confident in their solutions when they pair programmed.(1)

• In a test class, less teacher interaction: 74% wrote “between my partner and me, we could figure everything out.” 84% of the class agreed with the statement “I learned Active Server Pages faster and better because I was always working with a partner.” (2)

• Varying backgrounds create superior hybrid of code, design and architecture

3) Faster Problem Solving

• Presents multiple alternatives and approaches to problem solving. (Two heads are better than one)

• Pair programming allows team members to share problems and solutions quickly. This helps pair programmers to learn to communicate more easily. “This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”[2]

To note for graphs: Program 1 was 1st test case, Program 2 and Program 3 are after the initial "adjustment" period.

4) Cross Training

• The project ends up with multiple people understanding many facets of the system or code
• If an employee calls in sick, goes on vacation, work continues
• Risk of losing key programmers or experts is reduced.

5) Toxic Environment

• Hot shots and ego have less clout in keeping their job.

6) Testing Expedience

• Especially in a new company that has not developed a testing/QA department, this is increasingly more valuable in defect detecting.

What could go wrong?

1. Lost productivity

• 2 coders individually pushing out tickets versus 2 coders working on one ticket.

• studies have shown that two programmers working on the same program are only 15% slower than when these programmers work independently, rather than the presupposed 50% slow down.[3]

2. Disengagement

• Developers who view the task as easy, take over, thus disengaging their partners

3. Ego

• Developers who are resistant having worked alone for most of their career

How to be a good pair. Things to consider:

Expertise-level & skill sets

• Decide if you are on the upper level or the lower level, which can change with varying situations.
  • Are you senior engineer or junior engineer?
  • Have you been in the industry longer?
  • How long have you worked in the industry?
  • Do you have a CS degree, are you self-taught?
  • Is the CEO your best friend or dad?
  • etc.

How much space do you take?

• Are you an Introvert

  

• Are you an Extrovert

• Do shy developers have less ideas than outgoing developers? Do outgoing people vet their ideas before saying them out loud? I venture to say, "no" and "yes" respectively. (Disclaimer: This was empirically derived.)

With those in mind: Check your privilege

• Reflect on your own perceived power. If you are on the "upper level" advocate for your pair, and become their ally.
• Let your pair speak and voice their ideas before you do, being mindful of interrupting.
• Echo their ideas when they are not heard.
• Empathize. Show you are listening by repeating what your pair says back to them.[4]

Final thoughts and observations

TLDR: I am in a bootcamp. I also play sports. Pairing is like sports. Teams win. Pairs Win. Companies Win. Bottomline wins.

I'm currently a student at Flatiron bootcamp in Seattle. I just recently finished my second pair programming weeklong assignment. I love the it. Beyond getting to learn with a partner, getting to know the partner and working through our trials and triumphs together, I love that we both could explain our code at the end of the day, without needing the other there.

I grew up playing sports. I captained a women's flag football team that competed in tournaments as well as bi-yearly in a women's league. If you play team sports, you know that it's vital to play to your team's strengths in addition to exposing your opponents' weaknesses. Of course, you expect the same from the other team. In the games, we strategize and use our strengths to expose their weakness. In practices, we would run drills to work on our weaknesses so that other teams would have less and less to exploit every week.

Individual programming or even partner programming is great for playing to each individual player's strengths. However, it can create a larger gap between what that individual is good at and bad at.

Pair programming is like the football team. We play to our strengths while grinding at our weaknesses. In the long run, we all become better players and better teammates.

I especially love it in my bootcamp, all of us come from a wide range of backgrounds with skillsets that span the gamut. This is the absolute best time to practice, have patience with and work on things your partner or you are feeling inadequate in. Pair programming is an excellent system to create leaders, bond co-workers, give developers buy-in to the culture, and to produce quality code and results.

cited sources:

1. Williams, Laurie; Kessler, Robert R.; Cunningham, Ward; Jeffries, Ron (2000). "Strengthening the case for pair programming" (PDF). IEEE Software. 17 (4): 19–25. CiteSeerX 10.1.1.33.5248. doi:10.1109/52.854064.

2. Cockburn, Alistair; Williams, Laurie (2000). "The Costs and Benefits of Pair Programming" (PDF). Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000).https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

3. Williams, Laurie; Kessler, Robert R.; Cunningham, Ward; Jeffries, Ron (2000). "Strengthening the case for pair programming" (PDF). IEEE Software. 17 (4): 19–25. CiteSeerX 10.1.1.33.5248. doi:10.1109/52.854064.

4. Herrera, Annalee, (2018). "Pair programming at Voom: How our code takes flight". https://blog.voom.flights/pair-programming-at-voom-how-our-code-takes-flight-423a05d63718