Every day, many developers of enterprise systems have to face complex problems for which incorrect solutions often end with a loss of enormous amounts of money. That’s why they constantly learn new paradigms, frameworks, tools, read books and broaden their knowledge in technical conferences. It’s a lot of time and effort! All this dedication is on behalf of creating a high-quality product — but what is the result? Obviously it depends (as every software architect would say), but too many times the result isn’t the best. It takes a while, has got too many errors, often the code quality isn’t high… And let’s better not mention testing. Why is all this happening then? Everyone does their best, spends additional time on learning, so what exactly is missing? The answer is quite straightforward - constant practicing. Let’s say a few words about “code kata” which can make a remedy for the mentioned problems.

### The secret recipe

The term was coined by Dave Thomas (author of The Pragmatic Programmer book, DRY acronym and The Manifesto for Agile Software Development). All this is about is an attempt at transferring practice done by artists or sportsmen into the world of software development. The key idea is to find time for regular practice sessions that are not connected with our professional projects. There are a few things worth remembering to make such a session worthwhile and productive:

• Exercitation without interruptions. It’s hard to stay creative when something is disrupting you, so endeavor to adjust the time and place so that you can work without distraction.
• One simple thing to try. You should be able to easily complete your task during one short session (30-40 minutes or so), without being forced to hurry.
• Repeat your task. Iterate during subsequent sessions multiple times until you achieve a quality solution.
• It’s OK to err. Remember that no money is wasted if you go wrong — thanks to it you have the possibility to stay much more open-minded. Remember that learning in favorable conditions is easier, too!
• Glean some opinions. After finishing the kata it’s worth asking for feedback on what you can do better when trying next time.
• Don’t focus on closing out. The process of practicing itself is much more important than the goal of completing your task.
• Make fun of it. It’s the last, but most likely the prime advice — if such a session is another duty for you, it’s a royal road to giving up very quickly.

The subject of the task doesn’t really matter: you can invent your own challenge each time or use plenty of ready concepts from the Internet — to name only a few sources:

Personally, I think that learning from real-life cases is quite a reliable and convincing way of verifying a statement. Let me introduce you to one of my practicing experiences and a few benefits I achieved from regularly doing code kata.

The concept of kata is not new to me but I’ve had a long break from coding exercises I used to do in the past. Life abhors a vacuum — finding half an hour for concentration is not so easy for me now. However: some time ago my team was integrating a big external platform with Allegro. Lots of designing, refinements, meetings… All this in order to connect two disparate worlds. Such complexity often causes concerns about making mistakes in convoluted processes which would be hard to debug in the future. To avoid them the workflow is often slowed, which makes me feel unproductive and unsatisfied with the quality of my work.

One day I came up with the idea of going back to regular code kata sessions. Because I’m a dad of a toddler who takes almost all of my time after work I decided to focus on sessions as soon as he falls asleep. The first few days were hard, but now I use to practice around 3-4 times a week. For now, I mostly pick some ideas from http://codekata.com/ in order to save time on thinking about what can be done today.

Thanks to total freedom of choosing what to train, I chose different issues each day. Once I decided to compare JVM test frameworks for Kotlin (jUnit, Spek, Kotest, Spock) — each following day my choice fell on binary search in a different way using another testing framework. Another day I tried to implement Bloom filters using different approaches and to find out which one was the fastest. I was quite certain that the approach based on bit operators would win and was really surprised when it occurred to me it was the slowest one. After a moment of investigation I found out that this result came from a mistake in algorithm design. I used one BigInteger variable to store the whole Bloom filter and forgot about BigInteger’s immutability: in each operation, I created one or more new objects — a curse of immutability in terms of performance. Yet another day I found a task concerning the calculation of LOC metric for Java files. Below you can see the sources from first and second attempt. As you see they are completely different — I believe that it’s the point of doing the same kata during multiple sessions. The exercise itself (when you experiment and learn new things) is much more important than result details.

Day 1:

package me.wedrowicz.codekata.countingcodelines.day1

import java.net.URL

fun countLinesOfCode(url: URL): Int {
var loc = 0
var countedCharsInThisLine = 0
var quotes = false
var i = 0

val whitespaces = listOf(' ')

while (i < text.length) {
if (text[i] == '"') {
quotes = !quotes
i++
continue
}

if (text[i] == '/' && text[i + 1] == '*' && !quotes) {
i += 2
while (!(text[i] == '*' && text[i + 1] == '/')) {
i++
}
i += 2
continue
}

if (text[i] == '/' && text[i + 1] == '/' && !quotes) {
while (text[i] != '\n') {
i++
}
continue
}

if (text[i] == '\n') {
if (countedCharsInThisLine > 0) {
loc++
countedCharsInThisLine = 0
}
i++
continue
}

if (!whitespaces.contains(text[i])) {
countedCharsInThisLine++
}
i++
}

return loc
}


Day 2:

package me.wedrowicz.codekata.countingcodelines.day2

import java.net.URL
import kotlin.text.RegexOption.DOT_MATCHES_ALL