Overview

Paired Programming is a very common method of programming. Some companies pair 100% of the time! At other companies you may program solo, but pair 50% of the time when working on a particulary complex problem or if you’re learning something new.

Learning to pair is an essential skill of being a well-rounded developer. This guideline covers:

• the advantages of pairing.
• establishing a DTR.
• different pairing strategies.

The Why

Reasons why pairing is beneficial (to you and the team):

• Knowledge share: more people on the team understand the code that is being written and why.
• Less errors: with two pairs of eyes on the code, more errors and bugs will be caught quicker.
• Learn from others: sharing ideas and hearing other perspectives on writing code will expand your toolset for how to problem solve. You may learn something new from your partner!
• Team cohesion: pairing will allow you to get to know your team better.

DTR

When forming a new paired team or group, it’s important to start off by talking through expectations, limitations, and boundaries before jumping into any code. At Turing, we do this with a DTR (Define the Relationship.)

DTR Template

Moving forward, all Turing paired and group projects will start with a DTR.

Tips for best utilizing your DTR

• Keep DTR in a shared place that’s easy to access by all team members.
• Refer to and refine the DTR often throughout the project.
• If an issue arises within the group, refer to the DTR for how to handle the situation. If the DTR doesn’t cover this situation, add guidelines for how you and your team will handle this type of situation moving forward.

The DTR is a fluid, living, breathing document designed to help mitigate problems before they happen.

Communication

Another important component of pairing is communication. How well you communicate and work with other developers can be what sets you apart in a job interview.

Stand Ups

We recommend having a “stand up” meeting every morning with your partner (or team) to discuss what you worked on yesterday, what you will be working on today, and any blockers you are having or forsee.

• Note: a “stand up” is called a “stand up” because you have this meeting while standing and if you get tired of standing, the meeting has gone too long! These stand ups should only last 5-10 minutes. If further discussion is required, you can schedule a time to meet and discuss the issue later in the day.

Retros

Make time to reflect on progress, group dynamics, and the DTR. A retro (retrospective) is a time to meet as a team and reflect. We recommend doing a retro every 3 days to discuss: What is going well? Any issues (communication/working style/schedule) that need to be addressed? Create a solution together and document this in the DTR. This is a great time to give feedback to your partner. Whenever giving feedback, make sure your it is specific, actionable, and kind.

Pairing Strategies

Driver/Navigator

• Working together at the same time, in the same “place” (zoom counts as a place)
• Shared screen
• Driver: the team member that is typing
• Navigator: the team member guiding the code solution
• BOTH members should be collaborating on how they are thinking about solving the problem/asking questions
• Timebox so members can switch roles

Ping Pong

• Embraces the TDD (Test Driven Development) approach
• Ping: team member 1 writes a test for intended functionality
• Pong: team member 2 writes the implementation code to make the test pass
• Switch Roles
• Great for working together, but not at the same time or the same place.

Working Together via Github

• Use a branching workflow
• Use Pull Requests
  • Do not merge your own PR
  • Partner should review your code on the PR, discuss any questions or suggestions using github comments on the PR (hop on a call/zoom if further discussion is needed)
  • After all questions have been resolved, your partner can merge the PR into the main branch

Summary

• Communication is key throughout the entire process.
• Working together helps improve both professional and technical skills.
• Pairing takes practice. Figuring out how to work with others and understanding your own needs for how you work best is a process and may change due to circumstances. Use this time at Turing to practice and refine how you work best as a developer.
• Remember everyone is here to learn. “If you want to go fast, go alone. If you want to go far, go together.”
• Do not limit your own learning or that of others by working alone.
• We are all humans and individuals. Pairing will not go smoothly 100% of the time. Remember to ask questions before making assumptions.