Simple phrases to make your TDD pairing more enjoyable
Communication during pair is a skill like any other. Learn, adapt. Improve.
We explore more than technical details in TDD February. A large part of TDD comes down to how you interact as a team.
How is code shared?
How are responsibilities shared?
How are disagreements voiced?
What does unfinished work look like?
How does design happen?
Add these phrases to your pairing toolkit
Do you mind if I write the obvious implementation?
Following the driver-navigator structure can be very taxing for both participants if the driver is too passive. At the same time it’s disrespectful to the navigator to take over on a whim.
Therefore to build trust as a driver, give a little hint of appreciation each time you share an implicit agreement with your navigator and seem to predict what they’ll want to write next by asking this question: Do you mind if I write the obvious?
How would our customer know it works?
Testing implementation vs. behavior is a hot topic. One that even the best disagree on. You will naturally disagree on this area the most with your pairing partner.
When you find yourself in a situation that seems too technical to you, or chasing a trivial detail, ask this question: How would our customer know it works?
How would we describe this feature in release notes / press release?
Issues about too much or too little detail can also come up in larger ensembles. These will include non-technical participants: product owners, the customer herself, stakeholders, external collaborators.
Everybody loves playing developer for 5 minutes, but such whims do not produce helpful documentation or project plans.
Reorient the focus and intent of the conversation instead with this leading question: How would we describe this feature in a press release?
Sorry, I don’t understand enough to agree or disagree. Could you break it down with me?
Sometimes you get stuck on an argument or detail just because. Some old disagreement pops up, a mix of passion and discipline gets in the way, egos get activated and you butt heads.
Take a deep breath and zoom back out. Tunnel vision hampers way too many successful collaboration. It’s worth knowing how to react in this situation.
When you fail to find objective reasons to agree or disagree and you find yourself disagreeing to win an argument, use this statement to deescalate the situation: Sorry, I don’t understand enough to agree or disagree. Could you break it down with me?
See it for yourself
This is the unedited blurb of the last live stream, covering a conversation with Bryan Finster and Adrian Stanek, as well as an hour-long live coding TDD + Pairing session with Marc in the second half of the episode.
There are many instances where these phrases pop up or could be of benefit. Can you find them?
Link to the stream below
Conclusion
Thank you for showing interest in TDD February and being a part of it.
Step beyond the reductionist “TDD is X, not Y” and adopt it for what it is. A discipline and method that amplifies the skill of the engineers and teams that apply it.
Test-driven development helps:
create incentives for you to think more deeply about your problem and solution
document your chosen language and areas of focus
write in plain english what you want to express or test
foster collaboration in small steps in a way that is compatible and adaptible to pairing
Hope to see you on tomorrow’s stream for more live coding and a step into the more advanced topics for high quality testing and TDD!