There were regular coding dojos in my department until early this year. I never participated before because I was on that phase of my professional career where I didn’t have interest in coding.
When I regained interest, the dojos were over :-(. So I took the issue in my hands and went after the original organizers and asked them if we could do one any time soon. And that day was last week. Yay!
I didn’t know well what to expect, I must admit I never even googled a bit to find out what exactly the procedure was. I had heard a bit from my colleagues from my previous team last year when they participated, so I knew it was about practicing TDD and pair prgramming and that there was some kind of dynamic that made it fun.
This was the procedure we followed and the rules of the game:
There was a problem to solve (“the Kata”) and we got some description and constraints. The idea was to implement a solution in a TDD way.
We worked in a Mob-programming mode, rotating the keyboard every time so everyone would have the chance to write code.
The timeboxes were 5 minutes. Whatever code we wrote and was not commited when the timer beeped, needed to be reverted.
The person writing the code was not supposed to think or participate in the discussion, but just write.
After 90 min (actually a bit longer, but not two hours) we stopped and had a small retrospective about the session.
I really enjoyed the experience. I could identify inmediately the benefits of doing it regularly. In my opinion, there were obvious benefits and some not so obvious ones.
The obvious benefits
A challenge to your development style: you get a chance to practice truly TDD, which is in many cases not done in day-to-day project work. You practice pair programming (or even mob programming in our case) learn tricks from your fellow colleagues and provide some as well. You learn hands-on how it feels to develop that way, and not just the theory.
A chance to do something fun and out of the common daily tasks: you take two hours off from your daily work to sit together with some colleagues and solve a problem in a kind of “Uni style”, which depending on the mood you bring, can be a lot of fun while still being a learning experience. It allows you to even “free” or “distract” your mind from whatever tough times or problems you might be facing in your daily work. We laughed a lot together!
A challenge to your “team-working” skills: especially if you are not regularly working in pair. You need to be able to discuss with fellow team members about the possible solution, the approach to take, how to start, if the code adds value already somehow, taking design decisions in a group under time pressure (the short timeboxes), and everything within the boundaries of profesionality of course. This is a powerful soft skill training that is always welcome.
The “not-so-obvious” benefits
A chance to push off your limits: or a chance to extend your comfort zone. Because it can be a completely different dynamic than the regular working days. Changing habits can be really tough and a coding dojo is a safe place to start. Which brings me to the next point.
A safe place to learn: and also to make mistakes. This is the right place to try new things, to dare and do whatever is too scary to try out on the production code, or to dare and try new design approaches every time and see how it feels, if it’s a good way to go or not. Exactly the kind of things that are too big or too “expensive” to try on the regular projects you work on. Where else will you get the chance to start on a greenfield every time?
A chance to become a better you: because as the saying goes “Practice makes perfect”. And everytime you learn something new that can be only beneficial for your professional life, you get a better version of yourself. Continuous improvement at its maximum!
So, I am guessing I will be attending more coding dojos in the future. And if they are not scheduled, I will organize them myself.