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.
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.
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.