The Worthiness of the Fizzbuzz Kata

I see a lot of misunderstanding around doing code kata in the work that I do.

Just this week, I had a conversation with my apprentice about Fizzbuzz. He felt it wasn’t a worthwhile kata to do because the problem was so trivial. So we had a talk, and today’s Saturday morning rant was born :)

The purpose of kata is to practice, practice the same motions, repeatedly, until they are natural and you can stop actively thinking about them.

Because that’s when you expose the underlying challenges, hiding in the weeds.

As programmers, many of us love programming puzzles. Some kata are great programming puzzles, and sites like CodeWars are great at gamifying this kind of puzzle solving. That’s one kind of mental agility, work on a different problem every time, get good at tackling a problem and finding a resolution. The focus is on the problem in front of your face. You move on to a new problem, more complex than the last.

That is not the purpose of kata, however.

There is no practice in always doing new things. If every time you sat at the piano you tried to play a different song, play through the notes awkwardly, then switch songs, you won’t learn to play any one song beautifully. You will in fact not learn any songs, you will be glued to the sheet music of the next song in front of you, slave to its instruction.

When the problem in front of your face is trivial, like fizzbuzz, you already know it inside and out. You need no instruction. It is unworthy of any active thought to find its solution.

Your active focus more easily shifts from the thing to the effort in achieving the thing, because the thing is unworthy. You focus on the journey instead of the destination.

You can now explore the art in the journey. You think about what kind of loop you use, or even if you use a loop at all. You think about how you write conditionals, and even if you need conditionals. You stop thinking about what you need to output, and you start thinking about how you output it.

I love facilitating kata in a group setting, because it allows me to wander and observe people’s thoughts and approaches. It lets me drop hints, and enforce constraints when someone isn’t shifting focus from the trivial problem to how they are solving it.

Sometimes I will also play “the requirements game.” People are given incremental requirements, and are not allowed to ask questions. Like “Count from 1 to 25”. Then I focus them on the smallest amount of code to satisfy that. Then “Oh, I forgot, print it to the screen!” As things progress, they don’t know they’re being led into Fizzbuzz until they get to the 3rd or 4th step. Then I turn it into FizzBuzzWoof. Then I introduce print vs screen. It’s a fun journey to take together that explores how requirements tend to change on projects and how to write code that can survive that change.

If you think about your day to day work, it is rarely interesting from a programming puzzle perspective. However where we most get into trouble is in how we write our code to solve these trivial problems in a way that can better survive change.

So, enjoy the simplicity of Fizzbuzz. There is much to explore.