For years I have been practicing around coding katas at the Developers Dojo in Paris. What I like about coding katas in the context of a programming Dojo is that these exercises are generally based on simple, well-defined problems that are easy to explore. In that way, they present us with an opportunity to improve our problem solving skills as well as our coding skills.
For instance: we want to implement a program that tells if a certain telephone number is included in a quite large list of numbers, using only a very limited amount of memory. Or the program has to compute that answer super fast, etc. At the outset of the programming session — or sometimes right in the midst of it — someone asks: are we allowed to change the number format ? Will there be more than one query? And so on. Every question we ask about the problem, the constraints, the resources (including the time we have for the coding session), the possible heursitics that we have at our disposal — or that we need to learn about — is a way of exploring the problem space of the kata. This exploration is at least as important as the coding involved in the session, and is core to any software development no matter its size or complexity.
The other day a colleague of mine signaled to our group that he had created a repository where “we can push the solutions to several katas, in Java, C#, JS”. As much as I use coding katas in my training sessions, I found myself questioning the utility of such repository. To me the point of a code kata is learning by doing, not getting to know what the code should look like once the kata is ’solved’. However, I don’t want to disparage what could still be a source of information about programming. So I responded : “you mean, some solutions?”
Coding katas are often criticized, being seen as problems that are too simple to present any educational value to a developer in “real life”. I personally would not mete out such a definitive judgment on coding katas and want to say to these detractors: it’s still better than the alternative, i.e being caught in real life programming situations that are complex beyond my capacity to solve them and learn from them. But also: there’s always the possibility of tweaking the problem statement to make the kata less simple.
Doing a code kata as a group — whether you are comparing approaches done by pairs or you are doing mob programming — brings a new dimension to the problem-solving situation. In effect, we need to understand each other and communicate in such manner that the group constitutes a problem-solving efficiency boost rather than an hindrance. (Spoiler alert: in both cases, you will learn a lot). I won’t pretend that I could handle any development situation with outstanding problem-solving abilities, but I know what hundreds of weekly coding sessions at the Paris Developers Dojo specifically taught me. Over the years, I’ve learned to :
- keep calm and patient even in times when as a group we seem to be completely lost and ineffective;
- shut up and listen, especially when I think I understand the problem and feel an urge to intervene;
- explain something (that I think I understand) in the best possible way;
- put a finger on the parts I don’t understand, and ask for help;
- find, compare, and elect better names for all the things our code is made of;
- debrief the session, explicitly extracting what I learned, and how my mistakes obstructed the way;
- explore my feeling of frustration when the problem — or the code — seems to stare at us with a smirk on its face;
- defend and illustrate the principle that there is no such thing as a stupid question;
…All the while having great fun.