Sunday, October 13, 2013

A Kata A Day

"But such a day tomorrow as today."
-- Shakespeare, The Winter's Tale
Act I, Scene II, Line 64

"For ever and a day."
-- Shakespeare, As You Like It

A Kata A Day  

Epictetus, the Stoic philosopher, was record to have said,

"Practice yourself, for heaven’s sake, in little things; and thence proceed to greater."

Ever since Cory Foy's presentation at SCNA 2012 I have been doing a software kata at the start of every work day.  Yes, every single day with very few exceptions, even during the two weeks when I was putting in hellish overtime for a big release!  I find this practice is a great way to start the day.

Chong Kim recently blogged about using katas to improve one's coding.  I completely agree, in fact I have found that katas are a great way to learn new languages, styles, frameworks, ...

"Katas can stretch our abilities and, similar to how a kata would teach a martial artist to become comfortable with the uncomfortable, they help us write code we may not normally write."

So far in my year experience of daily katas I have used katas to learn: F#, Haskell, Clojure, JavaScript, node.js, SpecFlow, Mocha, continuation passing style, ...  So what sir, that is just a list of random programming languages and testing frameworks, have you actually gained anything?!?  Hmmm, that is a very hard question to answer, in order to truly answer it I would need to have done an experiment in which we have two programmers with equal ability and have one start their day with a kata while the other one gets an extra 25 minutes of sleep.  I did not set up such an experiment when I start around a year ago.  To make you for this lack of planning how about if we do a thought experiment?  Thought experiments were good enough for Einstein after all.

Say we have two programmers of equal abilities.  Elvis would like to take his programming to the next level and as such will start each work day with a code kata.  Mel on the other hand would just like to get to Friday and as such will sleep an extra 25 minutes each day instead of doing a code kata.  In a work month there are about 21 days, so in one month Elvis would have done 21 different code katas.  After about 3 months that would be about 65 katas which is enough practice time to learn a new skill or two.  In one year Elvis would have gained about 8 new skills while Mel would have slept around an extra 108 hours.  With 8 new or reinforced skills Elvis would find that he is well on his way to rock star status.

"Practice does not make perfect. Only perfect practice makes perfect."
-- Vince Lombardi

Here is the rub, those katas need to be deliberate practice, meaning they need to have goals, they need to push your skills, they need to expand what you think you can do, they need to make you better.  Merely sitting down and coding for 25 minutes is not enough.  You need to be mindful as you practice.  You need to have goals of what you want to do and you need to stick to them!  Use your katas as experiments.  Go to Rosetta Code and try something you have never done before.  Look up different programming language paradigm on Wikipedia and try them.

The principal of linguistic relativity comes in two forms: "(i) the strong version that language determines thought and that linguistic categories limit and determine cognitive categories and (ii) the weak version that linguistic categories and usage influence thought and certain kinds of non-linguistic behavior".  Regardless of which version you follow, the conclusion of our needs is the same, you are what you consume/do.  If you have used Higher Order Functions before in a kata then when you see a problem which is perfect for applying them you'll use them.

There is debate around if Eskimos have more words for snow than other cultures, but Kenneth Iverson inventor of APL and ACM Turning award winner and Paul Graham (all around genius) both believe that language influences how you think about a problem.  Graham calls this the Blub Paradox.

"programming languages are not merely technologies, but habits of mind as well"
-- Paul Graham, Beating the Averages

The programming language that you use to try to solve a problem not only dictates how you go about solving a problem but how you actually think about the problem!  Don't believe me, write the Prime Factorization kata in an Object Oriented language and Functional language.  What is the first hurtle that you hit in an Object Oriented language when solving a behavioral based problem?  Is it what type of objects do I need?  Does that really make any sense to think of when you finding the prime factors of a number?!?