Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • G general
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 29
    • Issues 29
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Insights
    • Issue
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • Frontend
  • general
  • Issues
  • #12
Closed
Open
Created Mar 07, 2019 by Paul Slaughter@pslaughter💬Maintainer

Format for Pair Programming

Description

Let's talk about how we can support pair programming to those who are interested. If we agree this is valuable, then we should probably add it to our FE docs somewhere...

Clarification!

This is not about how to pair program or enforcing a certain style of pair programming. Instead, let's talk about how to pair team members and handle the set up asynchronously.

What are the benefits of pairing?

  • Pairing potentially produces higher quality code or better solutions.
  • Pairing naturally shares knowledge of the code base.
  • Pairing increases the focus on the individual issue (not prone to getting distracted with emails / slack).

What are some challenges to pairing?

  • Some people may not be able to stream video reliably for that long. Maybe an audio call with one person streaming their screen is sufficient? You could also try the test/code pairing technique.
  • Some people may feel uncomfortable sharing their screen while programming (understandably!). This is why participating is optional. Also they could participate as a "Navigator" (participating verbally).
  • Issue selection is a big deal. Pair programming should be a positive collaborative experience, but some issues may require specific domain knowledge which may isolate the other contributor.

Option 1 - Random Pairing

  1. Around the 7th, ping the #frontend channel with:
Who's interested in some pair programming this month? 
If you'd like to be randomly paired with an awesome person, reply to this thread with "I'm in".
Once you have a pair, set up a 2 hour time slot and come prepared with an issue to work on. 
  1. Before the 10th, generate random pairs from everyone who replied "I'm in!" (and 1 unfortunate triplet if there's someone odd out)
  2. Around the 10th, reply to the thread with the generated pairs
Here's the pairs. Have fun! 

- @bob & @alice
- @ada & @cbabbage
- @mshelley & @jausten

Option 2 - Pair Requests

Support people announcing pair requests in a #frontend_pairs channel.

  • Individually led (both in creating and replying).
  • More visibility on issues.
  • More opportunity for mob-pairing.

Recording

Recording the session is a great way to make pairing more inclusive and better for knowledge sharing. Therefore it is encouraged!

Bear in mind that being recorded can be an uncomfortable or intimidating experience, so it should remain strictly optional. Please get permission from all participants before hitting the record button.

Once it's uploaded, post the link to the recording in the slack thread so that others can find it easily.

Edited May 24, 2019 by Tristan Read
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking