Two weeks ago I had the opportunity to attend the GDCR at Pivotal Labs London offices. It was my third time participating in this event. The previous editions I went to were at Agil-AZ offices in Santiago de Compostela (Spain) in 2011, and Skills Matter London (UK) in 2012.
My review about the GDR is going to be about the changes I’ve noticed between these three editions. I’m going to focus on 4 points: knowledge of the problem, languages used, expertise of the attendants, community growth and coding practices.
Knowledge of the problem: In the first edition almost nobody knew about Conway’s Game of Life so the whole morning was spent familiarising with it. It had already changed a bit in the second event I attended, but I noticed a massive shift this year, since all the people I paired with knew about it. This allowed us to focus more on the practises and less in understanding the problem itself, so it was a very positive switch.
Languages: Java has been the language mainly used in these three editions. However, I’ve seen how the amount of people with some knowledge of functional languages have steadily increased. I was also expecting a massive rise in dynamic languages like Ruby or Python but, as far as I observed, their growth seems to have stabilised.
Expertise of the assistants: I was pleasantly surprised at how all three editions kept a good proportion between experts and novices. The balance maybe tilted a bit towards newcomers, but generally speaking it was a well adjusted crowd.
Community: From my point of view, the community hasn’t expanded too much, since the faces I could see in all three editions were more or less the same. But I’ve observed a strengthening in the relationships between members. The bonds among members in LSCC are very strong, and I believe the same happens with the members of Axilmente. It looks like most of them have been fighting battles together.
Practices: The focus on good practises like SOLID, TDD, etc. is becoming a standard de facto for the GDCR. In the first and second editions, facilitators had to explain what TDD was, asking people to concentrate on quality. In the last edition, however, all the people I paired with or talked to had a solid knowledge of these practices and many were convinced TDD users, focused on code quality.
Of course, it’s worth stressing that my opinion is probably quite biased because I only attended this event at three very specific places. Therefore, it might not be easily extrapolated to other locations.
Finally, I would like to thank all the organisers, facilitators and sponsors. The celebration of this event would be impossible without them.
PS: If you are looking for a deeper insight on code retreat and the patterns arising from its practice, I recommend you take a look at this book: Understanding the Four Rules of Simple Design by Corey Haines, cofounder of Coderetreat.