It's been a week since Brighton CodingDojo Meet 8 and i've been slacking on writing down my opinions. I think that i've caught the blogging bug because it starts to trouble me if i don't put my thoughts down in writing. As soon as they're published then they can stop buzzing round my head.
This session was in Ruby and proved to be very popular. I guess that people are interested in the CodingDojo for learning a new language, whereas I personally am mainly interested in team dynamics and development methodologies. Dom presented a good 'Intro to Ruby for Java Developers' and it didn't matter that some people weren't Java-ites as it was more a compare and contrast. We've been working with Groovy and Grails here for the past week which helped me to grasp the basics of Ruby.
The main thing that I noticed with this session was instances of 'analysis paralysis'. This may have been because people were new to the CodingDojo concept but it was very obvious. When you only have five minutes to achieve something and you can't picture the problem holistically then maybe it is time to implement one small step and help to understand the problem. e.g. we were working on the sudoku solver again and nobody really new how to solve a sudoku…people were starting to think about loops "step over each cell and if it is empty then see if a number fits" and this should lead you to write the code for the smallest bit rather than the containing loop, in this case write a unit test that picks a cell that you know is empty and should only allow one number then write the code to do it.
My only fear is the opposite of paralysis, which is looking really busy but achieving nothing. But if the activity is constrained by the user story and unit tested to make sure that it is atomic then it may well be a step in the right direction.