Why Pairing?

Why Pairing?

What's Pair Programming?

Pair programming is a commonly used practice in the industry. Many companies strongly recommend or require their developers and data scientists to work out problems together as they continuously deliver software.

Pairing is also a technique directly correlated with Agile development workflows, and its benefits are often seen in the medium to long-term across development teams. Because the benefits of pairing aren't immediate, the practice has uneven adoption—but it's seen overall as a good thing!

However, we believe in Lambda School Labs that working in pairs directly correlates with your success as a learner, because:

• Pairing gives you an extra set of eyes on the code you're delivering—even before you submit a pull-request. This allows the pair to work through features thoroughly.

• Pairing forces you to talk through your work—a vital skill for any beginner attempting to break into the industry.

• Pairing allows you to work slower in the short-term but catch mistakes before shipping them to production.

Pairing can be difficult to pull off correctly, and it can even be uncomfortable to have someone else looking over your shoulder while you work. Our hope is that you can benefit from the techniques laid out in this module as we ensure that you pair to ship tickets at least 3 times throughout your labs journey.

Pair Programming in Labs

It's required that you pair program to ship the tickets your team scopes for each sprint—at least 3 occasions throughout your Labs journey. Your experience with these practices is vital to allow you space to articulate your approaches to software development.

Pairing will force you to talk through the technical tasks at hand and prepare you for interviews by giving you practice talking through your work as an experienced software developer or data scientist.

In each pull request you make, be sure to document the following:

• Who you paired with

• What pairing method(s) you used

• How did it go? What did you learn?

How to Pair Program

There are a few methods you and your teammates can use to pair program. Try out a few and see how things go naturally as you get better and better at the practice. One of the main principles to live by is "one screen, two devs." In pairing, you always want to be focused on the same screen, same code, same problem together.

Driver & Navigator

The driver and navigator technique is probably the most commonly used. You may apply these "role definitions" however you see fit—and ensure that you switch roles as you see fit. And **don't forget to **co-author your commits (Links to an external site.) so you both get the contributions you deserve.

• The driver in this scenario would have their hands on the keyboard, and in a remote setting will share the screen from which the pair operate. The driver should always be talking through whatever it is they're doing.

• The navigator sits in the observer's seat as the driver is driving development. This role gives directions as the pair move toward solutions. They confidently debug and fix code on the fly.

The benefits of the Driver & Navigator technique are that it allows the pair to:

• apply specific yet different perspectives to the task at hand.

• have one developer (driver) focused on implementing features, while the other (navigator) focuses on the bigger picture of the features being implemented.

• communicate thoughts, ideas, key learnings, and foundational concepts in a clear and concise manner.

Ping Pong

For those interested in flexing their Test Driven Development (TDD) muscles, the Ping Pong method is perfect. If you want to implement features in a test-driven way, then it's recommended you pair using this method.

A common flow for the Ping Pong method can be:

• Developer A writes a failing test. Ping!

• Developer B writes the implementation to make the test pass. Pong!

• After each pong, both have a short retrospective where they may refactor the code together and augment the test to reflect the refactor. Now would be a good point to also switch the ping/pong roles.

Strong-Style

When one developer is more advanced than the other, this technique helps with that knowledge gap-fill.

The rule: "For an idea to go from your head into the computer, it MUST go through someone else's hands".

In this style of pairing, you'll commonly see a Driver & Navigator setup, with the navigator being the "stronger" developer of the two.

As a driver in this scenario, be sure that you do your best to learn and understand the knowledge of the stronger developer. You most likely won't be able to grasp everything, so it's ok to attain "partial or incomplete" knowledge. Learn how to become comfortable with having a lack of understanding in the knowledge transfer. Ask questions like, "Why did you choose this technique over xyz?" Stay curious and positive—and have fun!