Skip to content
Switch branches/tags
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Thursday, Nov 19, 2015

Lunch and Learn: Pair Programming

* Where we've been
    * BDD / TDD - writing tests first based on JIRA / User Stories
    * Modularity and code organization
    * Intro to Vim
    * Martin Fowler / Neil Ford "Explaining Agile" video
* Today
    * Our Pair Programming experiences from the last four days
* Where we're going
    * Lunch and Learn suggested topic board (Etherpad)
    * Doesn't have to be a single presenter using slides
    * Other potential formats?
        * Moderated discussion

Why do we pair program?

  • Avoid knowledge silos
  • Large (or overlapping) tasks / user stories
  • It's more than just typo spotting!

Obvious reasons for pair programming

  • Onboarding new team members
  • Overlapping functionality in multiple stories
  • If someone is learning a new skill or element of our codebase

Less obvious reasons for pair programming

  • Abstract tasks
  • Changing requirements
  • Shorter deadline (one week mini-sprint vs. our typical two weeks)
  • Quantity of work in the backlog
  • Prioritization changes

Getting started / pre-requisites

* Just jump in and deal with issues as they come up
    * We didn't find a rhythm until Day 3
* Dev environment
    * Use a comfortable editor and box configuration for both devs
        * Not a good time to experiment with a new editor
        * Not good if only one dev knows Vim
        * QWERTY / DVORAK
        * Avoid interference and productivity barriers
    * Multiple monitors vs. a single monitor
        * Having spaces for editor/browser/terminal/Slack
    * Standing vs. sitting desk
    * Whiteboard available
    * Notebook/paper and pen available

How to Git with multiple partners for fun and profit

Understanding git workflow - how to collaborate on a branch / PR
Thanks to @tomtom for his help on Slack
TeamMemberA and TeamMemberB collaborate on TeamMemberAs box.
They reach a stopping point and push to TeamMemberA's GitHub origin.
TeamMemberA makes a W.I.P. pull request for other team members to review and comment on.
If TeamMemberB then wants to work on TeamMemberA:story-1234-asdf,
he should add TeamMemberA's fork as a remote via:

git remote add TeamMemberA

git fetch --all

git checkout TeamMemberA/story-1234-asdf

...make code changes...

git add && git commit

git push

This will update TeamMemberA/story-1234-asdf, which in turn will update the pull request that is open for that branch. This also means TeamMemberA needs to fetch changes into his local story-1234-asdf branch after TeamMemberB pushes.

Maintain your typical workflow

The good habits you have for programming alone, make sure you still do these while pairing!

  • Plan
  • Break things into steps
  • Make TODO lists
  • Set goals
  • Decide stopping points in advance
  • Ask questions For example,
    • What will the URIs look like for AJAX requests?
  • Think in terms of a "stack"
* UI / View
* Controller
* Service / Resource
* - Mock data
    * Requests - YAML
    * Responses - JSON
  • Think in terms of a narrative
* A user does this...
* and then this happens...
* and then this happens...
* and finally...
  • Use breaks
  • Work in pomodoros
  • Pace yourselves
Contrasting opinions on pacing
    * Momentum
    * The value of "early wins"
    * Blocker-breaking stamina in the bank

The driver role and the navigator role

  • If less experienced in an area, you drive (e.g. directives)
  • Examples of GOOD driver / navigator behavior
  • Examples of BAD driver / navigator behavior

Personality and the human aspect

  • Align schedules on a macro and micro level
    With flexible office hours,
    a 7-4 dev may not work well with
    a 9-6 dev
    Take coffee and restroom breaks at the same time
  • As programmers, we often need a balance of social/collaborative situations and solitary situations
  • If you need alone time, make sure you take it You may miss your heads-down with headphones in-the-zone feels.

Bring in an objective 3rd-party

  • Knowledge silos => silo pairs
  • Use a 3rd-party rubber ducky (+1 @sharkySharks)
  • Avoid tunnel vision, which is still possible with two people


* Ties up two people
    * When a third person is waiting on one of those two people...

Added benefit: learn each other's workflow tidbits of knowledge


  • Use breakpoints in Chrome DevTools, use less console.log
  • John Papa Style Guide on Angular "Best Practices"*
  • Chrome tab navigation (Command + 1)


  • BTW, Eric hates this word


Notes for a lunch-and-learn presentation on pair programming



No releases published


No packages published