DaedTech

Stories about Software

By

Code Kata? How About Product Kata?

When I was a kid, I spent a bunch of years doing karate. As best I can recall, there were three main types of activities around which we’d focus: kihon, kata, and kumite. I listed these roughly in order of sophistication. Kihon translates to something like “basics” and it involved executing the same punches, blocks, or kicks repeatedly, going for correct technique. Kata was something like “form” and this involved stringing together moves into more complex sequences and practicing those, presumably to emphasize rote practice of sequential movements. Kumite was sparring, and this was meant to be in-situ, improvisational practice, using the first two activities as building blocks.

There’s a lot of spiritual type stuff that goes on around martial arts, and it’s not my intention to rag on that in any way. You get out of things what you put into them and you find value that makes sense to you. But, at its core, these activities are really all about learning how to punch and kick other people and win fights. So you practice the basics, string those together into sequential movements and then have dress rehearsal sparring matches. This is all done so that when the time comes to actually punch and kick people in real life, you’re good at it. You don’t flinch when someone throws a punch because your countless hours of practice have made stepping into the blow, deflecting it and countering as second nature to you as cringing and protecting the head are for most people.

Learning to Punch People with Our Code

When I first heard of the martial arts concept of “kata” being applied to software development, I found it sort of interesting and weird. There’s intense marketing power in appropriation of this nature, and it can really make a concept take off. And, there are parallels between the two beyond the simple notion that deliberate practice improves technique. One of the main benefits to code katas is the practice of techniques like refactoring, TDD, etc. when the pressure is off. When in coaching/mentoring roles, it’s pretty common to see people try new techniques, only to abandon them when delivery pressure is perceived. To have “stickiness” for a software development technique, it’s essential that it hit a tipping point where the practitioner finds it less efficient to skip it than to do it. And doing a lot of code katas is a way to work toward that tipping point.

NinjaAssassain

Of course, as with any cross-disciplinary metaphor, there are gaps and those gaps can be problematic. Again, putting aside the spiritual overtones, karate is about learning to punch and kick people effectively. This is pursuit heavy on instinct and muscle memory and relatively light on cerebral cortex activity. A fight also spans seconds or, at most, minutes, where programming is a pursuit of hours, days, weeks, months, or years. I believe it was this sort of information gap that led John Sonmez to post about code katas. He heard the term “code kata” and mapped the martial art version onto it — one where you practice precisely executing the exact same movements until you can do them in your sleep. That’s not the intent of the code kata, but recall that we’ve been over what happens when you recycle terms with baggage for marketing purposes.

But I’m not interested in proposing a different name for code katas today. Rather, I’m interested in proposing a different target. A recurrent principle that I see in a lot of places these days is some variant of YAGNI. Be agile and don’t go nuts on up-front design because you might not need it. Keep your startup lean because you don’t want to build the wrong thing before getting feedback. Write only enough code to get a red test to turn green. It’s all made me wonder at times, “can you get too good at some facet of programming?”

This isn’t to say that there’d be anything necessarily wrong with raising software development to an art form. But what I’m talking about is a point of diminishing economic returns. Is there a point at which increasing your knowledge of the rules of a particular programming language doesn’t actually benefit you in any way except bragging rights, even if your job is to teach the thing? Would you know if it were possible to hit such a point, and would you know if you hit it? Would you know if you’d be better off solving different problems?

I don’t purport to have the answer to these philosophical questions any more than I purport to have a better name for “code kata” that preserves the marketing appeal and promotes additional clarity. But I am tossing out an idea for how to ensure that you’re not reaching a point of diminishing returns when you practice. If you’re a software developer, think about adding “product kata” to your practice routine.

How It Could Work

Here’s a site where you can get ideas for code katas.  They are, essentially, programming exercise for practice.  Iconic ones include exercises for scoring a bowling game or converting Roman numerals.  What I’d imagine is something similar wherein you defined product categories that relate to software:

  • Write a programming 101 E-Book about some tech.
  • Build an iOS app and submit it to the app store.
  • Start a programming blog and earn money with affiliate links.
  • Build a plugin for some popular application (e.g. a browser plugin that extends functionality of something like Trello).
  • Create a Windows desktop application and sell downloads of it.

I could go on, and so could you.  In fact, please do.  But to borrow from the effective marketing of the code kata (and also its divergence from martial arts kata), the idea is that you get practice building products in consequence free scenarios.  Write an E-Book on nights and weekends for a while and try to sell it.  Expect to make nothing from it, but to learn a lot: how publishing works, how to write, how to structure a book, how to get things in online book stores, etc.  It’s a pressure free environment where you can expect to fail, but you can also get feedback from your failures, acquire meaningful learning, and try again, building on that learning.  Each time, it should go a little better.

Since going off on my own as a free agent, I’ve learned a lot about how to build different sorts of income streams, and I’m still fumbling my way through it.  But the most important thing that I’ve learned is that it was a lot easier than I would ever have thought to just throw something together, get it out there, and make money.  During the part of my life that I spent working for companies, I had assumed that W2 employment was the easy way to make money and that other things (besides hourly moonlighting as a consultant) were impossibly hard and required gambling all of your time and money to try to start something.  What I didn’t expect was the myriad ways available to me to make a little money here and there on things that I did.  After a while, it starts adding up, making me wished that I’d started doing “product kata” a decade ago.

If product kata were a thing, people would start learning those lessons a lot earlier than I did.  Sure, your first app/book/plugin/etc would probably sell to no one except a sympathetic family member, but you’d have developed valuable learning.  Code katas help you get better at writing code, which, in turn, helps you get better at making money.  Why not cut out the middle step and just practice making money until you get good at it?

I’m not encouraging you to stop improving at programming, by any means.  If you just want to be really, really good at programming and aren’t worried about more money, for instance, then, by all means, practice, practice, practice!  But if you do occasionally wonder about the philosophical questions earlier and aren’t sure if you’re starting to experience diminishing returns as your stack overflow score tops 100K, there might be a path to learning here for you.  If you view software development skills as a tool in your general, problem solving tool chest, there may be a path for you here as well.  And there’s nothing to say that you can’t practice your programming craft and your product creation craft simultaneously in different sessions (or, maybe the same one, if you build a craftsmanship instruction product).

But don’t lose sight of the goal.  We make our livings writing software as part of the broader goal of helping people solve their problems.  And that is what we should practice — earning our livings solving problems for people.

  Subscribe  
newest oldest most voted
Notify of
Michael Borromeo
Guest
Michael Borromeo

Great post!

This ties into another great idea I’ve seen here (and a lot of places actually): shortening the feedback cycle.

If the cycle is just a programming problem (a kata) then you get great feedback on that small part but miss out on all the other fun stuff that goes into creating a product.

By making the cycle the whole product and by trying to go through several cycles in a short period, like you said, you can learn a lot in a short time.

Erik Dietrich
Guest

That’s exactly where my head is at with it. My experience has been that I’ve learned a ton about creating products as I’m playing with some stuff. If anything, I wish I could go back and rush things to market even more, so to speak. I wish that I’d started just kind of building things on a lark and learning from it early on.

lmm
Guest
lmm

> And that is what we should practice — earning our a living solving problems for people.

That’s the problem I see with this. It’s easy to “practice” making a product. But the only way you can tell whether it’s any good is if you can actually make money from it. You can write code and (sort of!) see that it’s good code even though you know that particular code is never going to be useful. But to get good at making things that are useful to people you have to actually make things that are useful to people.

Erik Dietrich
Guest

The first problem I saw was the typo I made in the part you quoted 🙂 Fixed. Anyway, I think maybe you could make interim judgments about products in the same way you could about code — by looking for certain properties and accepting it as axiomatic that they are “good”. For instance, code is “good” if methods are low complexity. I can objectively say that methods are of low cyclomatic complexity and subjectively call that good. In the product world, maybe I can say that an E-Book is mostly typo free and call that good. Or maybe I can… Read more »