My Docs
DeploymentTrelloCalendar đź—“ Family Promise Roadmap
LAMBDA_LABS_Family_Promise
LAMBDA_LABS_Family_Promise
  • Home
  • navigation
    • Resume
    • My Notes:
    • NAVIGATION
    • Calendar
    • Youtube:
    • Roadmap:
    • TEAM MEMBERS
    • Running List Of Notes Links & Pertinent Info From Meetings
    • Trello
      • Github/Trello Integration
  • UX
    • UX_TOPICS
      • Action Items:
      • Accessibility
      • Figma Notes
        • Tables In Figma
        • Notes
        • Frames in Figma
        • Prototyping In Figma
        • More Notes
      • UX-Design
        • Facebook Graph API
      • Ant Design
        • ANT Components
          • Buttons
        • ANT DOCS
        • Application (Codesandbox)
      • Examples
      • How to add external URL links to your prototype
  • CANVAS
    • Interview
    • Design
      • What's Inclusive Design?
      • Accessibility
      • What are Design Systems?
    • Canvas
      • Career Readiness:
    • Notes
      • User Experience Design
      • User Research
      • Interaction Design
    • UX-Engineer
      • Accessibility
      • Patterns
      • Design Tools
      • UX Principles
      • Design Critiques
      • Product Review
      • Quiz
      • Seven Principles of Design
      • Other Articles
    • Labs
  • Front End
    • Frontend:
    • Redux
  • Back End
    • Backend:
      • API
  • Research
    • Research Navigation
      • Front End
      • Back End
      • UX
      • PTM
      • General
  • DS_API
    • Data Science API
  • ROLES
    • TEAM ROLES
      • Bryan Guner
  • Action Items
    • Trello
    • Maps
  • ARCHITECTURE
    • DNS
    • AWS
    • Heroku
  • Questions
    • From Previous Cohort
  • Standup Notes
    • Meeting Notes
      • Stakeholder Meeting 1
      • 9/29/2021
  • GitHub & Project Practice
    • GitHub
      • Github Guide
      • Github Actions:
      • Live Implementation
  • MISC
    • MISCELLANEOUS
      • Links
  • Background Information
    • Background Info
      • Swagger OPEN API SPECIFICATION
        • Swagger Docs (General)
      • GITHUB:
        • Git Bash
        • Git Prune:
  • DOCS
    • DS AP
    • What is JSON Web Token?
      • Environment Variables
      • Git Rebase:
      • Git Workflow:
      • Linting and Formatting
    • Project Docs
      • Eng-Docs-Home
      • Basic Node API
      • Contributing to this scaffold project
      • Examples:
    • PROJECT DESCRIPTION (Feature List)
    • Labs Learners Guide
    • REACT
      • Create React App
      • Awesome React
    • Labs Engineering Docs
      • Okta Basics
      • Roadmap
      • Repositories
  • Workflow
    • Workflow
    • Advice
  • AWS
    • AWS
      • Elastic Beanstalk
        • Elastic Beanstalk DNS
      • Amplify:
        • Amplify-DNS
    • Account Basics
    • AWS-Networking
  • Career & Job Hunt
    • Career
  • LABS
    • Introduction
    • User Stories
    • Why Pairing?
    • GitHub
    • Planning as an Engineer
    • Authentication and Authorization
      • Authentication VS Authorization
    • Giving Feedback
    • Modules Grades Understanding Your ISA
    • Rest Architecture
Powered by GitBook
On this page
  • Why Pairing?
  • What's Pair Programming?
  • Pair Programming in Labs
  • How to Pair Program
  • Driver & Navigator
  • Ping Pong
  • Strong-Style

Was this helpful?

  1. LABS

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 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!

PreviousUser StoriesNextGitHub

Last updated 3 years ago

Was this helpful?

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 ** so you both get the contributions you deserve.

co-author your commits (Links to an external site.)