One way of learning new things about your coding style and about yourself is by doing a daily code kata. It can be like a simulation of a year-long software development project, with all the ups and downs happening in a much shorter time scale (a few iterations). More on that below.
I encourage you to try a daily code kata yourself and be pleasantly surprised by the things you’ll learn in the process. Until you do that, read on. You will find out about my own experience and the lessons I learned out of my daily code kata sessions.
WHAT IS A DAILY CODE KATA?
For those of you who don’t know, a kata is an action you do repeatedly in order to get better at it. A code kata is a simple coding challenge that you can repeat daily in order to get better at coding.
To get started, you pick a relatively simple problem from a list of code katas that you can easily find on the world wide internet. (Here is one such list if you’re that curious). Then, you devote 30-60 minutes a day to solve that problem. Your primary objective, however, should be something other than solving the problem. You get to choose your objective right before delving into code. It can be anything between practicing test-driven development, practicing your refactoring skills, improving your IDE shortcuts muscle memory, etc. Some code katas are better than others depending on what your objective is.
Here is what I learned during my coding kata sessions.
NAMING THINGS IS HARD
Very early in my first session of practice, I stumbled across an incident where I had two variables with the same name. The variables were supposed to represent slightly different things. One was a list of books provided as an input, the other was another list of books received as output. Both my variables were named “listOfBooks”. A bad way of solving the problem could be to rename one of them simply to “books”. A good pair of names would be “givenListOfBooks” and “expectedListOfBooks”.
Later on, I hit another rough patch involving names. I was describing a collection of books that had no duplicates as a “group of books.” In that same codebase, I was describing a collection of random books that might contain duplicates as a “set of books.” This is an unfortunate name because the mathematical definition of a set is “a collection that contains no duplicate elements.” The error may seem obvious now, but at the time I was writing the code I did not pay enough attention to the meaning of words. Unintentionally, I was making things confusing for the poor soul maintaining my code. I was able to spot this naming problem not while writing the code, but when reviewing it after a few days.
AVOID THE “HAMMER-NAIL” PROBLEM
You may have heard it before: “If all you have is a hammer, everything looks like a nail.” Sometimes, it looks like the answer to all your problems are the very things you learned just recently. In my case, for the first few tests, I could easily make them pass by using the same programming language feature over and over again. Later on, that wasn’t the case anymore. As a result, now I am suspicious of the first solution that comes to my mind. It makes more sense to take a step back and imagine alternative solutions so that I can choose the most appropriate one.
BE CAREFUL WHEN READING THE REQUIREMENTS
As soon as I advanced well enough into the business logic of the problem, I started to get confused. What does it mean that “books are eligible for a discount?” Should I be offering a discount for identical copies of a book, or for different books in a series? Why am I using double negation in my implementation? To my surprise, a couple of my tests were checking for the wrong thing, thus leading to erroneous implementation code.
Thankfully, I spotted them early enough and it was easy to correct, but it was a good opportunity to remind myself to avoid assumptions. Requirements should be written as clear as possible and read with the attention they deserve.
BEWARE SKIPPING STEPS
After writing a particular test, I wrote a “wishful thinking” implementation of a method that could make the test pass. By “wishful thinking” I mean code that did not exist yet. My method depended on two other nonexistent methods that introduced new concepts. Moreover, I had no tests written for any of them. This is when I realized that I was skipping too many steps at once. While doing test driven development, it is important to introduce only one concept at a time.
Commenting out code that you’re not ready to commit is a sign that you’re skipping steps. Replace the commented code with a written note (or a post-it) that will remind you what you want to achieve. Then take small steps, write small increments of code and commit often in order to reach your goal.
KATAS ALLOW FOR SMALL SCALE SIMULATIONS
Just like the Harry Potter books kata is a smaller scale version of a problem that e-commerce websites usually face (discounts), the entire kata exercise provides the opportunity of running small-scale simulations of the problems you would normally encounter and observe after months of writing production code.
One example of a simulation that the TDD kata brought to my attention was related to keeping deadlines. I was supposed to develop a certain feature in a timeboxed iteration of 30 minutes. While I was trying to get it done, I focused on the wrong thing and reached the end of the timebox without actually finishing the feature. Sure, there was some progress, code had been written, but there was nothing that I could “show to the client.” I missed my deadline and I learned of it in less than an hour.
There is an upside to hitting such problems during a kata. I can run this exercise over and over again, and I can learn to manage and fix my missteps. I get to hit “reset” and redo it until I get it right. When the same aspect will arise while working on a real problem in a production environment, I will be better prepared to face it.
All the things described above are just the tip of the iceberg. They’re only the ideas that were fit to be explained coherently in a blog post. I also experienced countless little “a-ha” moments that have no place in this text but are very valuable.
I highly recommend you give it a try and see for yourself. I guarantee that you will learn a lot, while also having fun! We’d love to hear about your own findings and your overall experience with doing daily katas. Leave your comments below!
2 thoughts on “Lessons learned while doing daily kata”
Alin, thank you for sharing. 30 to 60 minutes every day very disciplined. Massive Respect!
I am interested in some statistics? (because I love statistics 😉
* How often did you do the “daily” kata, e.g. every day, weekday, etc.?
* How often did you manage to do it vs. only planned to do it?
* Did you spent the time in private or during work hours?
* After how many runs did you notice a difference, e.g. some learning?
* How often did you repeat the same kata?
Glad you enjoyed it, Peter! Here’s my answer to your questions:
* I did the “daily” kata mostly during the weekdays. I always pushed by kata commits into Github. So you can have a look and extract detailed statistics from there. The repos (so far) are:
As you can see, commits are not happening daily, there are some short breaks now and then.
* I planned to do it daily. 😀 But as you can see, perfection is hard to achieve.
* I spent the time mostly during the work hours.
* I could say that learning happened almost from the beginning, as described in the article. But you have to take into consideration the fact that I’ve been doing TDD and refactoring katas previously during coderetreats, coding dojos and other in-house practice sessions at MozaicWorks.
* So far, I have not repeated the same kata during my daily sessions. But I plan to do it right after I go through my latest pick (the social network kata). I wanted to leave some space to cool off some ideas, to re-do it with a “clean” slate and a clear mind.
Let me know if you have any other questions. I’d be glad to answer them!