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

My HSQLDB schema inspection story

This is a simple story of my need to inspect the schema of an HSQLDB database for a participar FOREIGN KEY, and the interesting things I had to do to actually inspect it. I am using an HSQLDB 1.8 database in one of my web applications. The application has been developed using the Play framework , which by default uses JPA and Hibernate . A few days back, I wanted to inspect the schema which Hibernate had created for one of my model objects. I started the HSQLDB database on my local machine, and then started the database manager with the following command java -cp ./hsqldb- org.hsqldb.util.DatabaseManagerSwing When I tried the view the schema of my table, it showed me the columns and column types on that table, but it did not show me columns were FOREIGN KEYs. Image 1: Table schema as shown by HSQLDB's database manager I decided to search on StackOverflow and find out how I could view the full schema of the table in question. I got a few hints, and they all pointed to

Fuctional Programming Principles in Scala - Getting Started

Sometime back I registered for the Functional Programming Principles in Scala , on Coursera. I have been meaning to learn Scala from a while, but have been putting it on the back burner because of other commitments. But  when I saw this course being offered by Martin Odersky, on Coursera , I just had to enroll in it. This course is a 7 week course. I will blog my learning experience and notes here for the next seven weeks (well actually six, since the course started on Sept 18th). The first step was to install the required tools: JDK - Since this is my work machine, I already have a couple of JDK's installed SBT - SBT is the Scala Build Tool. Even though I have not looked into it in detail, it seems like a replacement for Maven. I am sure we will use it for several things, however upto now I only know about two uses for it - to submit assignments (which must be a feature added by the course team), and to start the Scala console. Installed sbt from here , and added the path

Five Reasons Why Your Product Needs an Awesome User Guide

Photo Credit: Peter Merholz ( Creative Commons 2.0 SA License ) A user guide is essentially a book-length document containing instructions for installing, using or troubleshooting a hardware or software product. A user guide can be very brief - for example, only 10 or 20 pages or it can be a full-length book of 200 pages or more. -- As engineers, we give a lot of importance to product design, architecture, code quality, and UX. However, when it comes to the user manual, we often only manage to pay lip service. This is not good. A usable manual is as important as usable software because it is the first line of help for the user and the first line of customer service for the organization. Any organization that prides itself on great customer service must have an awesome user manual for the product. In the spirit of listicles - here are at least five reasons why you should have an awesome user manual! Enhance User Satisfaction In my fourteen years as a