Pair programming is an agile software development technique in which two programmers work together at one workstation.
One member, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two people work together to design, code and test user stories.
- perhaps talk about what pair programming looks like at Artsy today (ad-hoc).
- Improve Quality - code review is done before or while the code is being written. (Yuki)
- Lower Development Costs (Yuki)
- Pair Learning (Knowledge Sharing) (Christina)
- Team Building (Christina)
- Ramp up new team members
- Share domain knowledge
- Increase collaboration
- Gain the benefits of instantaneous feedback
- Really specific and intricate issue/implementation
- When indivisual research is necessary
- When you feel you have been pairing too long
- Personal ideas
- 2 monitors
- 2 mice (or 2 cursors)
- 2 keyboards
- Pile of paper: useful when you want to draw to explain to your pair
- Mac's Screen Sharing
- Screenhero
- Optional: Extra Tablet + Video Communication Service (e.g. Facetime, appear.in, etc)
- Extra Laptop
- Useful for indivisual research. Caution: don't use it too much!
The driver and navigator is the tradition style of pair progamming. In this style, one member, the Driver, has the keyboard and control of the input. Their job is to type and focus on the minute-to-minute coding. The other member is the Navigator and takes on the responsiblity of paying attention to the code being written as well as keeping in mind the bigger picture and guiding the driver in the right direction.
- Write the code according to the navigator's specification
- Listen intently to the navigators instructions
- Ask questions wherever there is a lack of clarity
- Offer alternative solutions if you disagree with the navigator
- Own the computer / keyboard
- Ignore larger issues and focus on the task at hand
- Trust the navigator
- You are writing the code
- Thinks about the code that is to be written - the 'what'
- Clearly communicates what code to write
- Explains 'why' they have chosen the particular solution to this problem
- Check for syntax / type errors as the Driver drives (is the safety net)
- Make sure that the driver sticks to the small task at hand
- Outline and note down high level tasks / issues
- Ongoing code review
- Wait until the task is complete to bring up design / refactoring issues
In the ping-pong style of pair programming, one member of the pair takes the role of writing the tests while the other pair is responsible for making the test pass. If both pairs are particularly familiar with test driven development this is can be a successful style of pairing. Ping pong pairing can also work where the pair responsible for writing code to make the first test pass then immediately writes a test that the first pair will be responsible for adding code that passes and so on.
(Yuki)
- Discuss problem set and requirements up front to ensure they are well defined and both pairs have a clear understanding.
- Communicate what you are thinking both driver and navigator.
- Establish trust.
- Be Patient.
(Christina)
- Switch driver and navigator roles (every half hour).
- Take breaks:
- Take moments to celebrate as you complete tasks and overcome problems.
- When the pair is blocked.
- When an expert is paired with a novice, the expert should be prepared to play the role of mentor.
- The person who knows less about the system or language should do most of the driving.
👏🏾👏🏾👏🏾