Skip to main content

Sharpen your programming skills

Dave Thomas the author of “The Pragmatic Programmer” says:

How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practicing; applying the theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.

But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

Laurent Bossavit says:

If I want to learn Judo, I will enroll at the nearest dojo, and show up for one hour every week for the next two years, at the end of which I may opt for a more assiduous course of study to progress in the art. Years of further training might be rewarded with a black belt, which is merely the sign of ascent to a different stage of learning. No master ever stops learning. If I want to learn object programming... my employer will pack me off to a three-day Java course picked from this year's issue of a big training firm's catalog. Nuts to that – acquiring coding skills is not an “instant gratification” process. This workshop proposes to discover a way of teaching and learning programming in a more appropriate manner, respecting the depth and subtlety of the craft.

What do they have in common? Both emphasize the importance of practicing the art of programming. Dave Thomas pioneered the concept of coding katas. In his own words:

Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer. I add a new kata every week or so. Invest some time in your craft and try them.

Dave Thomas' code katas were originally intended as individual exercises that a developer does by himself or herself. Even though these exercises are very useful for individual learning, Laurent Bossavit proposed a similar form for groups, which he called coding dojos. Laurent's dojos are extremely popular in Paris. Even Uncle Bob (Bob Martin) has written good things about them.

I have personally conducted dojos for corporates as well as students, and have found them to have immense potential for transfer of knowledge. I normally do them for groups of 4 – 16 participants.

The dojo happens in a room with a computer and projector. We start with an explanation of the problem followed by a quick design discussion, followed by programming. The programming is done in pairs, beginning with the first pair taking a seat near the computer. The remaining participants watch what is being programmed on the projector screen. The audience is a participative audience, that is, they ask questions to the programming team and even offer alternatives. It is the responsibility of the programming team to convince the audience that the code they are writing is appropriate. During this, as a facilitator and coach, I moderate the discussions, ensuring that they enable the programming process, not detract from it. I also spark of mini discussions on design issues and make programming best practice suggestions. Along with this I also transfer relevant knowledge periodically. So, if someone is coding a List, I might take the opportunity to talk about different types of Lists in the Java collections library, and their pros and cons. Other things that may come up are various Java API's, threading, performance, programming and design best practices, and JDK 1.5 features (generics, autoboxing, and annotations). The knowledge that I can transfer depends on the dojo topic and the experience level of the participants. However there are plenty of opportunities and the information is very well received, since it is in the context of a practical example. This is the real strength of the dojo. The participants improve their programming skills, increase their knowledge of the language, of design and also learn a lot of other theory all within the context of some practical examples. Coming back to the dojo, each pair programs for 20 minutes after which another pair replaces them... and so forth for the duration of the workshop. An important aspect of the programming process, is that the programming team must speak continuously while they are programming, so everyone else understands what they are doing. I think this will also help them clarify their own thoughts and help them overcome obstacles.

Exercises can be specifically created to address particular learnings needs. Dave Thomas and Bob Martin also have some sample exercises:

Coding dojos have been conducted in other languages such as Ruby by Future Platforms. The Agile Finland group also conducts regular dojos. The fact that Dave Thomas has a dedicated blog for his katas attest to their growing popularity.

Whether it is dojos, or katas, or some other form of practice, I would like to urge every software developer to spend at least some time practicing and fine tuning their programming skills. The easiest way to get started is by yourself, but a fun way would be get together with some buddies and do a self-organizing dojo.

If you find the concept of coding dojos interesting and stay in Pune, you might want to attend the open dojo I am conducting on 17th February, Saturday, in Pune. The details and the registration page are here.

Notes: This text was originally posted on my earlier blog at


Popular posts from this blog

Running your own one person company

Recently there was a post on PuneTech on mom's re-entering the IT work force after a break. Two of the biggest concerns mentioned were : Coping with vast advances (changes) in the IT landscape Balancing work and family responsibilities Since I have been running a one person company for a good amount of time, I suggested that as an option. In this post I will discuss various aspects of running a one person company. Advantages: You have full control of your time. You can choose to spend as much or as little time as you would like. There is also a good chance that you will be able to decide when you want to spend that time. You get to work on something that you enjoy doing. Tremendous work satisfaction. You have the option of working from home. Disadvantages: It can take a little while for the work to get set, so you may not be able to see revenues for some time. It takes a huge amount of discipline to work without a boss, and without deadlines. You will not get the benefits (insuran

Testing Groovy domain classes

If you are trying to test Grails domain class constraints by putting your unit test cases in the 'test/unit' directory, then your tests will fail because the domain objects will not have the 'valdate' method. This can be resolved in two ways: Place the test cases inside test/integration (which will slow things down) Use the method 'mockForConstraintsTests(Trail)' to create mock method in your domain class and continue writing your test cases in 'test/unit' What follows is some example code around this finding. I am working on a Groovy on Grails project for a website to help programmers keep up and refresh their skills. I started with some domain classes and then moved on to write some unit tests. When we create a Grails project using grails create-app , it creates several directories, one of which is a directory called 'test' for holding unit tests. This directory contains two directories, 'unit', and 'integration' for uni

Some thoughts on redesigning education

Some time back I read a blog post on redesigning education. It asked some very good questions. Stuff which I had been thinking of myself. I left my thoughts on the blog, but I would also like to start a conversation around these ideas with those who read this blog as well. I would like to know what other people think of the issue of redesigning (college) education. I have often thought about how college education can be improved. To answer this question, we first have to ask a very basic question. What is the purpose of education? To me, we need education for 3 things: To learn more about the world around us To lead positive constructive lives To earn a good living / fulfill our ambitions I think education has to a large extent evolved to fulfill #3 (with a bias towards earning a comfortable living). The semester system, along with multiple choice tests, and grading, has made our education system into an assembly line. Students are pushed into the assembly line, given classes, admini