Our latest coding dojo involved working on a variation of the traveling salesman problem in Groovy again.
We had 8 people participating this week so we returned to the Randori format, rotating the pair at the keyboard every 7 minutes.
Give the number of people it might have actually been better to have a couple of machines and use the UberDojo format.
What We Learnt
- The importance of just getting started stood out a lot for me in this dojo – there have been quite a few times when we’ve met intending to do some coding and spent so long talking about coding that we didn’t end up writing anything. Luckily Dave took the lead in this dojo and got the ball rolling. The code we wrote originally wasn’t perfect but it helped create the momentum to keep the session going so it was valuable in that way.
- Another interesting feature of dojos for me is that it really doesn’t matter if you make mistakes – if you write really terrible code in a dojo it’s probably a good thing since you’ll probably not go and repeat the same mistake on a real project. I learnt a lot about the perils of not refactoring early enough and having too much state in our code from our Isola Dojo a few months ago.
- We refactored much earlier than we normally do in this dojo and I think it worked really well for allowing us to progress later on. Often we fall into the trap of just chasing the green bar a bit too much and we forget to clean up the code after each cycle but we had that a bit better in this one.
We also backed up a bit after around 3 cycles after realising that the code was becoming a bit horrific and spent 1 cycle working it into shape for the next one.
- We fell into the trap of going several cycles with broken tests while trying to do some redesign on the code – the steps were clearly not small enough!
Later on we corrected this when refactoring the code into a more functional style by taking very small steps and running the tests after each small change – this was a far more effective approach.
- Although we were working in a dynamic language it didn’t feel that the conversations were that different when discussing the code – we were still talking about types when working out what to do. I’m not sure whether this means we haven’t quite got the idea of dynamic languages or whether there isn’t such a big difference between the way you talk about your code in them.
For next time
- We might continue with another problem in Groovy – it’s been quite fun working in a language that runs on the JVM without the verbosity you sometimes get when writing Java code.