Between The Code

thoughts on coding and everything in between

No Pain, No Gain – Code Katas

Code katas are not a new concept at all, but my recent participation in daily katas has compelled me to consider how valuable they really are.

I won’t bore everyone with the technical definition of what a kata is; a kata is basically a specific thing you do repeatedly in order to improve in that area.

For me, no matter what it has been that I have had to practice (studying, playing the violin, coding, etc) it has always been painful & difficult, especially in the beginning. But that’s kind of the point isn’t it? If it were easy, then I wouldn’t need the practice. It seems to me that there are some people out there for whom certain things just come naturally, but, as tempting as it may be, we can’t let ourselves get caught up on the abilities of some in such a way that it distracts us from using regular practice to improve ourselves. Instead of comparing our abilities (or lack thereof) we need to just work hard at getting better if we really want to be good (dare I say the best we can be?) at our craft.

Maybe you stumbled upon this blog post because you don’t know how to do a code kata, or because you need some encouragement continuing in katas, or perhaps you have lost all interest in regular, consistent practice – here is just a bit of advice I would have given myself before my first code kata:

1. Don’t quit & don’t make excuses. Sure, it will be hard and frustrating (or boring) sometimes, but the point is to get practice – that’s it. So just do it, and keep doing it.

2. After coding a problem kata to its solution, scratch it and start over from the beginning. You just might come up with a better way to do it or if nothing else, you will get practice with how quickly you can put it back together again.

3. Code kata for a maximum of 30 min. Keeping it in short sprints will help you get faster, it will force you to get & stay focused, and also gives your brain a break & a chance to work on something else.

4. Do a code review after you are done with your practice time. Have a co-worker or colleague open your solution and talk through what it is doing. Having to be accountable for the code we write helps us to learn and keeps (or makes) us humble.

5. Try something new – a new problem, a new language, a new code reviewer, no mouse – anything to mix it up and stir up any area that needs improvement. It is also a good way to avoid boredom.

6. Take constructive criticism and learn from it – let go of anything else. Constructive criticism seeks to teach you the better way, but any other negative or derogatory remarks or feelings do nothing to help you out so learn & move on.

7. Don’t be intimidated by the exercise. Don’t feel like you should know it all right away – that defeats the point of the kata. Of course you won’t have the best solution right away. We practice so we can learn and get better.

For those of you who want to continue improving your development craft here are a few kata websites my team and I have used. If you know of other sites, please share them – or come up with some of your own! Happy coding & good luck!

http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue

http://content.codersdojo.org/code-kata-catalogue/

http://codekata.pragprog.com/

http://12meses12katas.com/

Advertisements

2 responses to “No Pain, No Gain – Code Katas

  1. Stu Hubbard July 11, 2018 at 2:32 am

    Great idea and I can use it in several places in my work and personal life. After 30+ years in software development we have gone from the developers who treated work like an artform only they understood (spaghetti code) to now current day DevOps factories. It’s time to get aggressive about lean code instead of wondering brackets that eventually get the function done. Pair programming is a great way to get better and faster on a project. Hack-a-thons are another great way to get better by learning from others. Great blog topic!

    • Sarah Powell July 21, 2018 at 12:40 pm

      Practice always makes better! And learning from others broadens our understanding and theirs as well. I’m always advocating for quality of coding – not just “can we” but “should we” and why.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: