Pair programming

Saturday 10-11am

Paul Julius (PJ) presentation / discussion

Recommended the www.pomodoro-book.com for doing 25 minute sprints, including commits.

GIT good for granular / regular commits - put label on commit even if not pushing to central repo.

Discussion about distributed version control anti-continuous integration. Ref Martin Fowler blog on distributed version control and branching dilemas. Keep it simple. Look also at distribute CIT.

PJ also posted a counter-blog to this (www.pauljulius.com)

Infinitest - determining the right tests to run at the right time, so things are not forcing entire test suite to be run on every commit/push.

Aim is to understand and improve developer cadence / rhythm.

Michael Feathers testing criteria/rules

TDD principles: No coding until we have a broken test made. Only code until the test passes, no more.

Delete superflous code, beyond what is needed to pass the test, as it has no test coverage.

If you're not doing TDD you are not a professional developer - like an accountant not using double entry book keeping - nobody would hire you. TDD is double entry coding... so you know you're right.

PJ never does coding w/o TDD. 70% of time doing pair programming.

Discussed challenges of TDD with UI focused apps. Extract as much as possible into helpers that can be easily tested automatically. Focus on business application with a think UI layer.

Test represent the requirements.

Use the Pair Stair to track who has paired with who, to mix the team around. Option: First 2 people in the office pair together, then the next two, etc.

With any practice, try it seriously for 2 weeks, measure success, and then decide.

Beware of pairing wrong people where one always takes back seat to dominant stronger dev, compare Han Solo vs Chewbacca....

Styles of Pairing

Ping pong - Write test, give to pair to write code to pass. They then write test and give pack to you to write code to pass.

Board - Ball = one has keyboard (code) other has mouse (nav). Boarder no nav, not even alt-tab!! Usually the more experienced dev has the mouse, knows where to navigate, what to do.

Baseball coach style = senior writes test, gives to junior to write code to pass. Repeat.

Rubbery Ducky problem solving = explain the problem to the rubber duck / stuffed toy.

www.pauljulius.com www.ci-guys.com