Earning your developer black belt with code katas

In this post, Denise and Ben from our bespoke development team the SuperVillains, share how they've been using Code Kata to improve their coding skills.

The only real definition we have of Code Kata comes from Dave Thomas, who coined the term. The premise is an exercise in coding which helps a programmer hone their skills through practice and repetition. Kata is a Japanese word for detailed choreographed patterns of movements practised either solo or in pairs.

Code katas are short, open ended exercises with no single correct solution. A simple search on the term will bring lots of simple coding exercises (katas) to do, and explain how you can learn from repetition.

What is a code kata?

It was first introduced to us by one of our teammates, and his interpretation of this term was for the team to solve a challenge using a single computer and keyboard, over a predetermined time, with each person getting a set amount of time on the keyboard - 5 minutes or so. The challenge being to learn of each other while trying to achieve the code goal. It sounded like fun so we decided to give it a try. 

The importance of peer and pair coding

In SilverStripe, and in particular the SuperVillains (although we are a little biased), we rock at Peer Review and Pair Programming, it’s a core part of our development processes. It’s used as a way to share knowledge between team members, and to ensure only top quality code makes it through to production websites. There have been times when only one person on the team has had experience with a project's codebase or technology, and this leaves a knowledge silo in the team, with the other members trying to catch up, or worse ignoring the situation. For those times we have found that: first, don't let that one person get sick or go home, ever. And second, it's easier to catch up to speed if someone that knows a bit more than you helps. That's where peer programming techniques shine. We know this and rely on it a lot, so we decided to give "Code Katas" a go, and add it to our arsenal if something good came out of it.

Our first experiment with code katas

We did two Code Katas. The premise was simple, choose something we wanted to work on, set the timer for one hour, choose which computer to use, and start coding. We decided every 7 minutes the person using the keyboard should change. The first one was kind of messy. We only had a vague idea of what we wanted to do before going into it, we hadn’t defined a “box to tick”, or had a concise plan of attack. We weren’t strict on timing of the Kata, only deciding to use a stopwatch halfway in, we just used the rule of thumb of "yeah, I think I feel 7 minutes older. NEXT!". Winging it is a fitting term.

The second time

The second time went much better. We went in with a clear plan of attack, sussing out what we wanted to achieve before jumping into it, and using a pretty online timer for keyboard turns. This helped the Kata run smoother, and by completing what we set out to achieve felt like a goal was completed within the team.

So… did we like it? Would we do it again? Was it useful? 

It was fun, we didn't end up hating each other or screaming "I TOLD YOU TO PUT A SEMICOLON THERE!", so that's a win right there. It did help make the team tighter and stronger. Seeing how someone else codes and obsessively indents and moves the line you just wrote to another file (because modularity / reusability / they just didn't like it there) can surely make you understand their thought process, which is a good thing… Yeah, really!

We learnt a few lessons that help code katas be successful in our team:

Lesson 1: Respect coding conventions

When you code, if you know the peer reviewer is going to have a fit because you didn't follow coding conventions, you keep that in mind and actually start caring. Either that task is going to be in your to-do list again, or someone else will waste time fixing it.

Lesson 2: Vocalise your decisions

Since you can't touch the keyboard if it's not your turn, the person with the power will have to vocalize his decisions, or the team is not going to get anywhere. If they has to say why they are moving that piece of code, why are they changing that variable name (even though $variable12 was perfectly understandable), then you sometimes come to think they are right, that it is a better way of doing it, using it as a way to justify actions or changes. Now if they aren’t right but keep on using bad practices after you explain your reasoning, then you can secretly start hating them. So try to always be right. SuperVillains don't care if you hate them, but you might care.

Lesson 3: Define the objective

We learnt to define what the objective of the session was going to be. Lesson learned after the first session where right from the start we wasted our 7 minutes talking to each other about what we wanted to do next. 7 minutes with the keyboard trying to decide how to name your project isn't productive, you know? So set a few achievable goals, like "set up the buildchain", "create a Plant object", "make it do photosynthesis", "kill the plant". You don't need to define how to create that object, or how the functions are going to be structured, but at least a high level objectives definition is necessary to make this worthwhile.

Lesson 4: Establish base knowledge prior

Another piece of advice. Even if this exercise is meant to share knowledge across people, it's still better to have a base knowledge about what you are going to be doing, and the technologies you will use. If someone says "I'm going to add jQuery to the buildchain" and you have no idea what jQuery is, then that's a problem. And it’s not even a matter of "you are slowing your team down", but also you won't have much of a great time trying to catch up on terms and the general idea of what you are doing. So have your project idea ready, and before a Kata, read up, very basic stuff, no need to be a pro since you are there to learn, but at least good basic knowledge and context on the subject.

Lesson 5: Commit time to learning

Also, we don't think this should be done if you have a tight timeframe. Things will turn pretty ugly pretty fast. The main idea of the exercise is to treat it as a learning experience, but it's definitely not efficient in terms of productivity. By the ninth time the keyboard owner uses his time to check something on Google you will be kicking his chair. Or worse. So do it with time and do it for fun.

We had a retro after the Katas (of course, Agile!), and the general consensus was that we would do it again… but for a finite set of cases.

Code katas are great for:

• Learning and knowledge sharing

• Tackling specific challenges you don’t have the skills to solve individually  

• Encouraging intra team communication - you need to talk. Like a lot. If you don't like talking or explaining yourself, you might have a hard time with this, but honestly, you should try to do it, power to the soft skills and all that.

Code katas are least suited when you’re time poor, they’re not enjoyable if you’re rushing or under pressure to quickly solve a problem.

In the end we did recognise it as a good exercise and we will do it again. People will complain about your text editor choice or keyboard settings, but next time it will be your time to complain. You can learn new keyboard shortcuts, or how to run a command you didn't even know exists. It does make you a better programmer when you vocalize what you are doing and try to make others understand your thought process, and at the same time understand theirs. At the very least, if this doesn't help you in any way, in your 7 minutes you can make the moment memorable by changing the environment settings on your teammate's computer, that's always fun.