There were a couple of problems which became apparent early on. One problem we noticed which Danilo also pointed out in his paper was that keyboard shortcuts are a bit of a problem, both in terms of us developing on a Mac and using IntelliJ. My UK keyboard layout also provided an area of difficulty - we’ll probably try and use one with an Australia layout next time.

We started off using the Hamcrest library for doing assertions but eventually resorted to using JUnit assert methods as these were better known by the group.

We didn’t stick strictly to the navigator/driver roles when pairing - as we were able to adopt a TDD approach most pairs used the ping pong pairing approach to keep both people engaged.

After 2 or 3 goes each we noticed that people were always working with the same pairs when they were at the keyboard - we started to mix it up so that everyone got a chance to pair with the others. I think this helped to make it a bit more interesting and allowed us to achieve the goal of working with as many of the group as possible.

We had the Object Calisthenics rules written up on the board which worked much better for keeping them in mind. We didn’t keep strictly to them but one idea suggested was that if we violated them three times that could serve as a signal to refactor to the rules.

The problem was a bit too big to allow us to complete it although we managed to get much further than last time. We are going to look for some smaller problems for the next Dojo.

It was reallyhard to come into the code afresh at times and try to be productive straight away. I think some of this was down to not being fully engaged when in the audience. Certainly the pair just before your go you need to be completely aware of what is going on. It was also pointed out that it is much easier to come into a pair if we are getting the green bar all the time - it makes it much safer.

We had 2 or 3 pairing sessions in the middle where there was only discussion and no coding - luckily we managed to turn this around after this wake up call and managed to make quicker progress after this. Calls from the audience to code and stop designing helped drive this.

The necessity of taking small steps was again obvious. Often we adopted the approach of trying to implement the solution from a very high level test instead of drilling down into smaller tests and then making these pass. Eventually the small steps approach won through and by the end we were chalking off much smaller tests with greater frequency.

When rotating pairs bring the new person in as the driver with the person who stayed on from the previous pair taking a navigating role to start with to guide the direction of the code.

Keep a list of the next tasks/tests to write on the whiteboard next to the code. Anyone in the audience can add to this list. The idea is to try and keep the audience engaged while not distracting the focus of the current pair.

A bit more up front design and discussion of the problem before diving into the code. We still had the situation where we thought we understood the problem but struggled to implement it until we drew it up on the whiteboard about half way through.

Get the audience to follow the current pair more closely. We often had the situation where the audience was discussing one part of the problem while the pair at the keyboard was coding another part. Trying to get the two parties more aligned is a challenge for next time.

Get thepair to be more vocal about exactly what they are trying to do. The need to articulate ideas is even greater when there are others in the room trying to follow your train of thought so putting extra effort into this when at the keyboard may work better.

Try a smaller problem next time - probably one from the Online Judge website.