Why Katas Work

Musicians, singers and athletes have something in common - they do a lot of practice to become the best. They may have a show or a competition from time to time, but they practice every day.

Martial arts practitioners do katas over and over. At some point it becomes a form of art.

Can the same be done with code? Can you practice to code a certain piece of software over and over until it becomes art? Uncle Bob certainly thinks so. I started doing some katas a few months ago but a question was still nagging me : do they really help me become a better programmer? Does practice matter?

According to The Talent Code, the answer is probably yes.

The book explains how to harness your talent, how to become an expert in your field. And it seems that all world experts, no matter their field of expertise, have spent a lot of time (10 000 hours) practicing. Not just any kind of practice - you can't just play around and hope you'll learn something. There is a concept of 'deep practice'.

There are three parts to deep practicing:

• Chunk things up - slow things down, do a simple part of the whole
  
• Repeat - a lot
  
• Learn to feel what you are doing
  

I think that's what I've been unconsciously doing with katas. I wrote the same application every time. But every time I was improving, basing the next iteration on past experience. I was using more keyboard shortcuts, less code, better idioms to express myself. I was learning from my mistakes and becoming more efficient.

I believe that katas help me to  'deep practice'. It forces me to reflect on what I've done and learn from my mistakes. In the end I believe it helps me to improve.

That's good enough for me to keep doing it.

Essential Bookshelf - Pragmatic Programmers

I read lots of books. Lately I've been evangelizing the virtues of two of the books that had a deeply impacted me lately. This is the review for one of them.

The first book I want to talk about is Pragmatic Programmer, from Journeyman to Master by Andy Hunt and Dave Thomas. I read this book in 2001, after I worked for a year or so, and it totally changed the way I think about software.

There were lots of great advice under the form of catch phrase (DRY - Don't Repeat Yourself, No Broken Window, the Law of Demeter...). The authors even wrote about usage of metaprogramming and compilers in (almost) everyday software. But that's not what influenced me to become a better programmer.

What inspired me was that the authors have a deep passion for programming and it shows. They talked about investing in yourself as you would in an investment portfolio. "Learn a programming language every year". "Learn your tools". "Care about your craft".

I first heard the expression "rubberducking" in this book as well - if you can't find a human to talk to, talk to the duck.

However programming goes beyond coding. The code is important, but so is knowing your tools, the command shell, deploying an application in a real environment, build files and build automation. Programming is a social activity, you need to show your code to peers to get feedback and improve, you need to talk to your customer to know his requirements. You need to care, improve, learn!

That made me realize that the knowledge I have today is already obsolete - I needed to be aware of where the future might be heading, which technologies might come out on top in a few years. I started to read more books and blogs. I went to local user group meetings. I started a few pet projects in a few languages. And I realized that I would probably be programming even if it wasn't my day job - I was just lucky to get paid for it.

If you haven't read this book yet, it's a must for every programmer who is passionate about his craft.