From Novice to Code Master

By Ali Qornan

How does one become a master at something? Let’s take music as an example. It helps to know the theory and to understand the mechanics of your instrument. It also helps to have talent. Having a good partner to watch your back doesn’t hurt either. But there’s more to it.

Why are The Beatles, who formed in Liverpool in 1960, considered one of the greatest bands in history? Why doesn’t everyone else achieve the same level of success?

The difference between master and beginner is the amount of practice.

The Beatles applied the fundamentals they learned over and over again, using feedback to get better every time. All told, they performed for 270 nights in just over a year-and-a-half. By the time they had their first taste of success in 1964, they had performed live an estimated 1,200 times. Most bands today don’t perform that much in their entire career.

The 10,000 Hours rule

In the early 1990s, psychologist K. Anders Ericsson and two of his colleagues at Berlin’s elite Academy of Music conducted a study. With the help of the Academy, they interviewed twelve expert pianists (8 men and 4 women) and 12 amateurs (7 men and 5 women).

The amateurs never practiced more than about three hours a week over the course of their childhood, and by the age of twenty, they had totaled two thousand hours of practice. The experts, on the other hand, steadily increased their practice time every year, until by the age of twenty, they had reached ten thousand hours.

“To become a chess grandmaster also seems to take about ten years. (Only the legendary Bobby Fisher got to that elite level in less than that amount of time: it took him nine years.) And what’s ten years? Well, it’s roughly how long it takes to put in ten thousand hours of hard practice. Ten thousand hours is the magic number of greatness.”

Malcolm Gladwell, in his book “Outliers: The Story of Success”

The interesting thing about that number, of course, is that ten thousand hours is an enormous amount of time. It’s all but impossible to reach that number all by yourself by the time you’re a young adult. This would require encouraging parents and some measure of wealth, which would avoid the need to hold down additional jobs that would eat into valuable practice time.

What Happens in the Software Industry

In the software industry, we take developers trained in theory and throw them straight into the deep-end, working on a project with no real precedent to draw from. It’s like taking a group of kids to fight against the big gang in the town. But that is not an issue because, in software engineering, we do our practicing on the job, and that’s why we make mistakes on the job. But at the end of the day, we want to be great while still managing the objectives. For that purpose, we need to find ways of splitting the practice from the profession. A practice method that is effective and without taking up too much time.

This is where CodeKata comes in.

The CodeKata

Kata is an exercise in Karate to execute a specified series of a variety of moves, with stepping and turning, while attempting to maintain perfect form. It teaches the student about proper form and position to helped them visualize different scenarios for each motion and technique. Traditionally, kata is taught in stages. Previously learned kata are repeated to show better technique or power as a student acquires knowledge and experience. It is common for students to repeat every kata they have learned but at an improved level of quality.

CodeKata is an attempt to bring this element of practice to software development. The intent behind CodeKata is similar to Karate Kata. Each is a short exercise. It repeated multiple times, adding little improvements in each cycle. Some involve programming and can be coded in many different ways. Some involve thinking about the issues behind programming and design. These are unlikely to have a single correct answer.

Remember that the point of the kata is not arriving at the correct answer. The point is the stuff you learn along the way. The goal is the practice, not the solution.

How Is This Accomplished at Gojek?

At Gojek, there’s a program for employees called Engineering Bootcamp. Basically, it is weeks of intense hands-on learning designed to unlearn and equip skills needed to be a world-class engineer.

At Bootcamp, the way coaches taught us (participants) is similar to CodeKata. We have a code drill session in the afternoon to solve one problem by using Java. After the class ends, we solve the same problem again as homework in the evening using Ruby. There are many things we did in our code drill session, that really helped us develop in CodeKata. Those are:

1. Set Rules

We have rules called Non-Negotiable Etiquette. If you violate one of the rules, you have to rm -rf your code and start it again from scratch. What is rm -rf? It is a basic command on Unix system to remove files or directories from the machine forever.

Non Negotiable Etiquette

If you violate one, rm -rf! never love your code </3

1. Indentation and spacing between code constructs (classes/methods/specs) must be consistent.
2. Use only spaces (no tabs) for indentation.
3. Newlines at end of file.
4. Follow accepted naming conventions for your language/framework.
5. Follow accepted naming file and Directory structure for your language/framework.
6. Use namespaces.
7. No comments/Unused Code/Unused file/Unused folder must ever be checked in.
8. Runtime environment should be consistent with IDE environment -  i.e there should be no difference in running a build or a spec from your IDE and from the command line.
9. Use .gitignore.
10. Ensure there is a README.md that includes problem description, dev environment setup, build instructions, and run instructions.
11. Test Driven Development (this should show in clear pattern in the commit log - one spec, one code change per commit)

Can you imagine the feeling when code that we wrote with blood and tears needs to be deleted for one small mistake? Is that acceptable?

Yes, you must not love your code.

That small mistake is not tolerable in production and even development. It could cause bugs, errors or other things that may become a bottleneck. But of course, we don’t rm -rf in work 😂. It’s just a practice so that we don’t get overly attached to the code, remain careful about mistakes, and most importantly — maintain quality.

2. Practise Pair Programming

As the name implies, pair programming is where two developers work on one machine. We only have a keyboard and a mouse for each pair. One developer acts as the driver who codes while the other serves as the observer who checks the code being written, proofreads and spell-checks, and also figures out where to go next. These roles can be switched at any time: the driver will then become the observer and vice versa.

Pair Programming greatly helps us in CodeKata, because:

• It’s harder to procrastinate. Working as a team means you can’t stop and check your email, Slack, Facebook or WhatsApp every few minutes.
• When someone shares a problem you are going through, you feel less defeated and more positive about trying again.
• Increases software quality without impacting much on time to deliver. It will cost only 15% of the development time according to this study. But with increased quality comes big savings later in the project.

3. Have a Short Cycle

The point of CodeKata is to get experience from practice. In order to achieve that, we solve the same problem multiple times. We try different approaches and solutions to experience each advantage and disadvantage. While we work on it, we also try to add little improvements for every cycle. But sometimes, we can also treat the cycle as an iteration of solving the problem.

Because CodeKata is a practicing method and not project development. It’s not supposed to be worked on for the long run. For that reason, we only have 20–30 mins for every cycle (sometimes even shorter).

After the Mini Retro, we showcase our code to other participants in the class. Why do we need to do it? Even though the whole class is working on the same problem, we may interpret it differently and have hundreds of possible different solutions. Doing a showcase will tell others about progress and approaches. It will trigger a discussion and synchronize the context for everyone. At the end of the day, we will converge at the current best solution.

It’s similar to Agile Development. You deliver something to the customer as soon as possible to get feedback faster.

A Few Final Thoughts

My tips for CodeKata are:

• Find a place and time where you won’t be interrupted.
• Focus on the essential elements of the Kata.
• Remember to look for feedback for every major decision
• If it helps, keep a journal of your progress
• Have discussion groups with other developers, but try to have completed the kata first

Thank you for reading this blog! Hope you found it helpful. Cheers! 🙂

If you’d like our updates to reach your inbox directly, subscribe to our newsletter!