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

Planning a User Guide - Part 3/5 - Co-ordinate the Team

Photo by  Helloquence  on  Unsplash This is the third post in a series of five posts on how to plan a user guide. In the first post , I wrote about how to conduct an audience analysis and the second post discussed how to define the overall scope of the manual. Once the overall scope of the user guide is defined, the next step is to coordinate the team that will work on creating the manual. A typical team will consist of the following roles. Many of these roles will be fulfilled by freelancers since they are one-off or intermittent work engagements. At the end of the article, I have provided a list of websites where you can find good freelancers. Creative Artist You'll need to work with a creative artist to design the cover page and any other images for the user guide. Most small to mid-sized companies don't have a dedicated creative artist on their rolls. But that's not a problem. There are several freelancing websites where you can work with great creative ar

Inheritance vs. composition depending on how much is same and how much differs

I am reading the excellent Django book right now. In the 4th chapter on Django templates , there is an example of includes and inheritance in Django templates. Without going into details about Django templates, the include is very similar to composition where we can include the text of another template for evaluation. Inheritance in Django templates works in a way similar to object inheritance. Django templates can specify certain blocks which can be redefined in subtemplates. The subtemplates use the rest of the parent template as is. Now we have all learned that inheritance is used when we have a is-a relationship between classes, and composition is used when we have a contains-a relationship. This is absolutely right, but while reading about Django templates, I just realized another pattern in these relationships. This is really simple and perhaps many of you may have already have had this insight... We use inheritance when we want to allow reuse of the bulk of one object in other

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 (insuranc