Notes for a lunch-and-learn presentation on pair programming
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
README.md

README.md

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
Summary
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 https://github.com/TeamMemberA/our-team-project.git

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
* Stub.by - 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
MACRO
    With flexible office hours,
    a 7-4 dev may not work well with
    a 9-6 dev
MICRO
    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

Disadvantages

* 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

Examples:

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

Antipatterns

  • BTW, Eric hates this word