Wednesday, July 31, 2019

Pairing notes from session by Michelle Gleeson

Every time: Starting a session

  • Can you both see the monitor? Get comfortable.
  • how long will you be pairing for, when will the breaks be (every 45 minutes)
  • when swap? (every ten minutes, every green test, other little goals?)
  • talk through the business logic / user story

Every time: after a session:

  • what was hard about the session
  • what were the unexpected benefits?
  • how can we make it better next time?

Key takeaway:

  • most benefits realised when you combine pairing, clean code and test-driven-development.

Why pair?

  • whole team accountability
  • higher standards
  • can go on holiday (no key-man dependency, no bus-factor, no handover)
  • continuous handover
  • continuous code review
  • build strong team relationships (how long does this take?)
  • increases inclusion and authenticity
    • story about girl who hated her job until that team started pairing
    • opportunities for juniors to work on critical items
    • everyone learns lots of tips and tricks
  • deliberate action: challenge your own thinking
    • story about submarine verbalising routine possibly-dangerous actions

How to pair?

  • no phones
  • one monitor
  • same thought process
  • low level hum of quiet discussion
  • if on laptop, plug in a keyboard (no hogging screen)
  • mirror displays
  • no slack

Quickstart to get a team used to pairing

  • identify why (measurable goals, e.g. 150% improved cycle time)
  • agree to a two week experiment
  • work through discomfort
  • be courageous
  • review regularly
    • what's hard
    • what are the unexpected benefits
    • how can we make it better
  • block out time in calendar and link slack status to it so you don't get interrupted

tips and tricks:

  • offsite pairing might help
  • team charter to make sure values aligned
  • development style: use a linter!

advanced:

  • mob once a week. Several developers sitting around a shared TV, passing around the keyboard.
  • use a timer to swap
  • track who you pair with to make sure you get everyone. Make a chart.
  • pairing cycle: make a test pass, refactor, write next (failing) test, pass over the keyboard
  • everyone knows what's going on, manager can ask anyone
  • team size 4-6 (bigger gets inefficient)
google clean code by robert martin
17 november code retreat. kata. pair with someone for 45 minutes then delete your code. dojo. new challenge for each pair.

Friday, July 26, 2019

How to avoid writing unit tests


  1. Use the type system -- compile errors are better than test failures
  2. Use libraries instead of writing your own code (and having to test it yourself as well).
  3. Say no to unnecessary features. Be ruthless. Every new feature means more testing.
  4. Test all the glue with a single integration test. Testing glue with unit tests is a waste of time:
    1. glue unit tests only ever fail when you're refactoring, so they are all maintenance and no protection
    2. they are not useful as documentation (there's no point documenting glue)
    3. This does NOT apply to unit tests for business logic (as opposed to glue)
  5. Write simpler code.