This is a repost from my old blog thecompilerdoesntcare.com and was originally posted in 2017.
For a long time now I have been talking about starting a group at work, where we meet up and practice our skills, outside of our normal projects. It is always hard to focus on becoming better at something specific, if you are only writing production code. It’s like a musician only playing concerts. While he still learns something from playing a concert, he will impact his skills more effectively if he practices scales, chord progressions and full songs over and over again. In the same way we can exercise our skills in a more focused way if we do simple tasks, with specific goals in in mind.
I started such a group this Friday, and this post is a recap of the magic that happened.
The Set Up
At my job we have what’s called “Academy Friday” every other week, where we are not allowed to work on customer projects (unless we want to try out something new that is not billable to the customer), but rather we are encouraged to work on whatever we find interesting. This means working on our own personal projects, having reading groups, or just watching video tutorials. For extra inspiration the company have bought a bunch of stuff ranging from VR gear to RFID tags and scanners, to Beacons and Raspberry Pi’s.
It is within this format that I have started a Coding Dojo, where the idea is to spend all or part of our Academy Fridays doing Code Katas and other exercises to work on our programming skills.
My idea was that I would say a few words about what a Code Kata is, and then we would watch a video of someone doing the Bowling Game Kata, using TDD. Then we were supposed to pair up, and do the kata ourselves and when we were done, talk about our experience and our results in the group.
It didn’t go down that way though.
What actually happened
My hope was that the group would eventually become self sustaining and people would bring new exercises and katas with them that we could try out, and that a better was of organizing the group would emerge organically.
This happened much sooner than I had expected.
The video of the guy doing the kata immediately sparked the question “why should we do that kata – now that we have seen the solution?!” – a great question by the way.
Because katas are not about the result, but rather the process of getting to the result, I convinced him that we should try it out anyway, and see where it took us. The guy in the video solved the problem in Java, and we were going to use C#, so of course people spotted places where the use of LINQ would result in much nicer code.
Now that we had agreed that this kata was what we were going to do, I asked people to split up in pairs, but because we were an odd number, it created a bit of confusion, and someone ended up suggesting that we could just solve it on the big screen, with me doing the coding. Cool idea, which turned out to result in great discussion and a lot of good input.
The Result
We ended up spending 6 times as long solving the problem using true TDD, and still ended up with a result that few of us was happy with. It just screamed “REFACTOR ME!” but we where out of time.
This turned out to be a good thing, because it meant that we could agree on “homework” for us to before our next meeting.
We would all refactor the production side of the code without changing any of the tests. Then, when we meet up next time, we will all have different versions of the same application which we can review on the big screen and talk about in the group, before we start our next task.
The Coding Dojo in the future
Based on the feedback from this first meeting and the enthusiasm of the seven developers that attended it, I think this will be a great success in the company.
I think it will create social bonds across teams, and it will foster a feeling that the software we write should be of the highest quality. Just from the passion with which people commented on the code we wrote together, it was clear that when possible they all care a lot about it. With this spreading and more people joining the group, I’m sure that it will have a huge positive impact on the quality of and attitude towards the code being produced in the company.
There is also the added bonus of learning from each other, something I value greatly – being one of the more junior developers in the company.