Silent Pair Programming

On Thursday 31 October I participated in a Silent Pair Programming event organised by the London Software Craftsmanship community. During the sessions pairs are not allowed to talk about the problem and they can only discuss secondary issues as the IDE, keyboard shortcuts, etc. The goal of the exercise is to communicate with code and maximise its readability. Here are a couple of my learnings from the session.

If the partner writes a test which requires too much of implementation code at once, one way to solve it is to make it pass by hardcoding the response and then writing a smaller test. Once implemented, the following test should prove the hardcoded response insufficient and in consequence to its removal by generalising the production code.

When working on the production code, it might be worth following Kent Beck’s Composed Method pattern (from “Smalltalk: Best Practices and Patterns”). That is, let your partner follow your thoughts by implementing the method (almost) entirely with well-named private methods and variables. Programming language specific features and APIs should be hidden in the private methods. The reason is that they are often too generic to convey the intent. Once the test is green, the pair might want to minimise the code by inlining some of the private methods, if the underlying generic code does not obscure the readability.

If you don’t understand what a piece of code written by your partner does, you might want to select it in the editor and hand over the keyboard to them, so that they refactor it towards more clarity.

If you can think of any other tips for Silent Pair Programming sessions, please feel free to post them in the comments :)