This last weekend was the tenth annual Global Day(s) of Code Retreat, with over one hundred and fifty Code Retreat events running on either the 15th and 16th of November. Not having been to one before it was great to find there was an event being run by Barney Dellar and Natalia Zon from Canon Medical Research at their office in Edinburgh, so I signed up to head along.
The basic idea of the Code Retreat is to look at how we as software developers code by coding the same basic problem in a series of exercises during the day with various restrictions. The basic problem is based around Conway’s Game of Life devised by British mathematician John Conway back in 1970, although during the course of the day it’s unlikely that anyone will get a working solution as your code is thrown away at the end of each exercise!
Each exercise lasts forty-five minutes, which is followed by a short retrospective session and a break, and then we start again. First off we had a simple attempt to solve the problem, to get used to pairing and the Cyber Dojo environment that we all used, however from there it got more difficult.
Session number two we were heavily restricted in the length of methods we could write, and in my case that was made more difficult by myself and my second coding partner coming at solving the problem from totally different directions! As a result of that in session number two I came up with a better explanation as to my thinking, which then came totally to nothing as session three we weren’t allowed to talk to or communicate with our pairing partner at all, except through the code we were writing, and we took turns to write tests and implement the code to pass the test.
Session four thankfully we were allowed to talk to our pairing partner, but had restrictions of not being allowed to use conditional or loop statements to solve the problem, this was just the kind of challenge that had a lot of the developers at the event still thinking about how to do it as they were leaving at the end of the day!
In session five we were exploring the Kent Beck idea of Test and Commit or Revert so if our tests failed for any reason we had to revert to the last successfully passing code, and delete what we had written since then. This is to encourage you to make small simple changes and always have working code rather than perform big changes that could potentially break.
The final session, Barney who along with Natalia was leading the event told us that since it was the last of the day we could do what we liked, resulting in lots of experimental solutions. However it was a ruse, and after twenty minutes he swapped the pairs around, and then five minutes later swapped development environments handing us all what was effectively legacy code with non-working tests, and in some cases in a language the new developers were not familiar with. The retrospective after that was interesting with all of us trying to explain where we were going with the half finished solutions that were passed on to others.
So was it worth giving up a Saturday for? Absolutely. Usually as developers we’re trying to learn development techniques at the same time as doing our actual work, it’s rare we get a chance to actually just look at how we code, and as such it was a really worthwhile day. Canon Medical Research actually ran the day twice, firstly on the Friday when it was mainly their own developers who attended, and then the public session on the Saturday. Certainly if you have a large number of developers it is the kind of event that could be run internally if you’re wanting to improve the coding skills of your team.
Last Friday was the annual CodeCraftUK conference in Glasgow. As a community organised event it’s much more reasonably priced than some of the bigger conferences, and also has a rather different structure than most of the big conferences – as they say on the conference website they put the confer back in conference, focusing instead on small group guided conversations and workshops. Since we have a daily parliamentary train that uses the Winchburgh Loop to go direct to Glasgow from Kinghorn that could get me to Glasgow in time for the conference I picked up a ticket and headed along.
Before talking about the conference, a little side note about the parliamentary train, if it ran more frequently it would actually be a pretty useful service – there have been a couple of occasions we’ve been going to events in Glasgow when there were events on in Edinburgh, in particular big games at Murrayfield when the normal route of taking a train to Haymarket and changing to the express service just really wasn’t attractive and we opted to drive instead. If there was a regular service direct to Glasgow, we would have used the train instead. Even with the meandering route the train takes, especially with the evening service there is little difference between the time it takes to go direct and going into Edinburgh and changing to a faster train.
Anyway, on to the conference.
First off I opted for a guided conversation entitled “What lies behind a job title?”. We had a mix of people in the group from recent graduates through to people like me who have been in the industry for years, and also from a variety of company sizes.
The conversation certainly confirmed my experiences over the years aren’t unusual. We had examples of companies, often the bigger ones, with rigid hierarchies, where teams had to have certain numbers of senior, mid-level and junior staff. There were also the common frustrations of junior engineers who were told what to do by seniors, seniors who only seemed to have reached that level by way of being in the role for a long period and so on. However there were other examples of more progressive companies that had done away with levels in job titles as they were regarded as unhelpful. There were also so amusing anecdotes such as a participant who is CTO in a small start up and said there was only one other developer, but that he used the CTO title because it opened more doors talking to larger organisations.
I along with quite a few others from the first conversation moved onto a second session called “Being T-Shaped”.
One interesting take away of the T-Shaped session is that there is not a single understanding of what being T-Shaped actually is. One explanation came from Agile Kanban practice where software development is split into a number of stages, the T shape idea coming from team members having most experience in one of the stages, but able to work on tasks in other stages if need be. However other participants in the conversation took T-Shaped as having a breadth of soft skills alongside deep technical skills in a particular area. Again this was a conversation that showed the differences within big and small organisations. In smaller organisations being T-Shaped is almost a requirement of the role, whilst in larger organisations there is sometimes push back against people working in roles that are not their own.
After the next break I opted for one of the workshop sessions, an hour crash course introduction to Machine Learning.
Machine Learning is one of the current buzzwords that sales and marketing people love to use, with really very little comprehension of what the term actually means – certainly they often confuse artificial intelligence in their products with genuine machine learning (check out this Wired article for an explanation of the difference). For what was necessarily a brief introduction we built a Jupiter Notebook that used freely available dataset, python code and TensorFlow to recognise handwritten numbers. This used a neural net that was trained with 60,000 handwritten numbers, and across the participants in the workshop achieved between 98% and 99% accuracy when given a second testing dataset of 10,000 numbers. Although it was a whistle-stop tour, we did get something working at the end of the session to take away, plus some recommendations of where to go to learn more.
For the afternoon sessions I went along to a two part workshop on Mob Programming, given by somebody who has been leading a team working entirely as a mob for the last five years. Alongside giving us experience of working in a mob to accomplish a task, he was also able to give some good advice.
For the first part of the workshop we were in a mob of six, and given the simple task of programming FizzBuzz, but using C++, a language quite deliberately picked because most of us would have little experience of it. We also followed the recommended practice for teams starting mobbing of having a driver who was at the computer and only allowed to do what they were told, a navigator who was doing the thinking, and the rest of the team not allowed to talk until their turn as navigator. We then rotated around the roles in order every two minutes and forty-five seconds. The rest of the mob not talking proved to be the critical practice, in that otherwise the mob has the potential to be dominated by some of the group, having the navigator being the only person allowed to speak ensures even quiet members of the team have a chance to speak and participate.
One of the key criticisms of mob programming, almost always from people who have never tried it, is that having the entire team working on a single task is slower than having everybody working on different parts of the problem. The workshop leader however is working at a company with two similarly sized and experienced teams, working on the same codebase, but one using mob programming, the other team using more traditional methods. Bearing in mind the usual caveats about it not being a good way to compare two different teams, the teams are working at a similar velocity, and certainly the company has not had reason to ask one or other team to change because of any significant difference in the work delivered.
The arguments in favour of it are an extension of the arguments in favour of pair programming in that the team is reviewing code as it is written, rather than the write, review, repeat loop that more traditional methods produce. It is also a good technique for ensuring consistent knowledge sharing amongst team members, and is an excellent way to on board new team members as they are just brought into the mob right from the start.
Certainly as an introduction to mobbing it certainly showed me what a beneficial technique it can be. There were several participants in the second part of the workshop who had been mobbing themselves for a while, and some who had been skeptical when their teams had started. All of them found the technique useful, and many said they would struggle to go back to not working in a mob. It’s not for everybody however, another participant in the workshop mentioned a team member who despite being an excellent part of a mob decided it wasn’t for them and swapped to a team who weren’t using the technique. On the basis of the workshop it’s certainly something I’d like to try in a team.
So was it worth the trip across to Glasgow? Definitely – and I’ll certainly be looking out for the conference next year. I probably learnt more from the workshop sessions, and the mob programming was especially beneficial, but the guided conversations were also good too. When you compare the cost of the bigger conferences, which sometimes veer towards being sales pitches for particular products, the conference is a bit of a bargain, and a great opportunity to learn from each other, not just from whoever is giving a particular presentation.