Coding Dojo🥋

A training that goes way beyond the code.

It’s been a while since I’d like to do a Dojo Coding with my co-workers here in Lisbon, to have some fun, learn and improve programming practices and meet my other co-workers. Time was passing and now I had the right opportunity to suggest and apply it with all the others interested.

But first of all, what is a Dojo?

This is a Dojo :)

Dojo refers to a training place specifically for Japanese martial arts such as aikido, judo, karate, or samurai. And what does this have to do with programming? Why is it called Programming Dojo? That’s the main point:

You, as a developer, need to train, and a lot!

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.
- Dave Thomas

So, Coding Dojo is a secure, inclusive, collaborative and fun place to improve your programmers skills.

Following this principles, we really need to know that is not a place to a “SHOW” or a “Competition”, is a lot more then that.

Coding Dojo Requirements:

  • A comfortable meeting room;
  • A computer with the desired development environment already up and running;
  • A projector so that all participants can see what is being done;
  • Snacks and pizza are a plus :-)

There are two main meeting formats:

Randori Kata:

In this format, the two initial participants solve the problem together, following TDD and Pair Programming in time-boxed rounds (usually between 5 and 7 minutes). At the end of each turn, the pilot joins the audience, the co-pilot becomes pilot, and a new copilot joins the pair from the audience.

Prepared Kata:

The session goal is that everyone should be able to reproduce the steps and solve the same problem after the meeting.

In this format, someone has already solved the proposed Kata prior to the meeting (alone or in group) and the solution is presented to the audience during the session. Instead of showing the final code and tests, the presenters start from scratch, explaining each step and allowing the other participants to ask questions or make suggestions.

The sessions usually follow the same process:

Problem Choosing (5 to 10 minutes)

Before the meeting, the participants receive an e-mail with 3 to 5 options of problems to be solved. Each option is briefly presented and the participants vote on which problem will be solved.

Problem Discussion (10 to 20 minutes)

Once the problem is chosen, the group discusses the different approaches to solving it, usually ending up with an agreed approach and a list of TO-DO items, to guide the pairs during the implementation.

Coding Session (1 to 2 hours)

With an agreed approach to solve the problem, the participants start the coding session in one of the two formats — a Prepared Kata or a Randori. They should practice Pair Programming and Test-Driven Development as a general rule.

Retrospective (10 to 20 minutes)

At the end of the session, the participants stop coding (even if the problem was not completely solved) to reflect on the experience and share the learned lessons with the group (and also can send the code to be versioned in GitHub or Bitbucket).

Benefits:

Each programmer will see a particular benefit, so I will list the most common:

  • Better communication:
Pair programming with some pressure

We are in a secure and fun place to help each other, so, we’ll lose the shame and our communication will be improved a lot, besides losing the fear of making mistakes in public. And the pilot is never alone, the co-pilot is there to help in each step and if something goes wrong the “Sensei” (usually the creator of that session) will help to unblock.

  • TDD - Test-Driven Development:

Tests are made before the implementation, following these steps:

1. Write a test for a new function. The test should fail;

2. Write code until the test passes;

3. Refactor until the code is suitable; for continued development

4. Goto 1.

  • Baby steps

The next step to take should always be as small as possible.

- Yes, as small as possible.

Conclusion:

This article is a bit of what I’ve already learned about Coding Dojos. I have tried to group the knowledge acquired in the work, in the preparation for our Dojo and through related researches (references at the end of the article).

The methodology used in Coding Dojos may be used for other areas because the benefits over time are the same, so if you are not a programmer, do not worry. Make Dojos with friends to put together ideas for new projects or to find a better way to solve a problem in your company.

Questions?

Please comment below and try to do some dojos with yours friends! :-) #Share #CodingDojo

:-)

References:

Basic:

http://codingdojo.org/

Problems:

http://dojopuzzles.com/
http://rubyquiz.com/
http://www.programming-challenges.com

Others:

https://medium.com/gdg-aracaju/o-que-%C3%A9-um-coding-dojo-f5f229443714
https://www.infoq.com/br/articles/codingdojos
http://www.dtsato.com/blog/wp-content/uploads/2008/06/sato-codingdojo.pdf
http://blog.buzeto.com/2010/12/minha-experiencia-no-dojo-brasilia.html
http://blog.andrefaria.com/5-coding-dojos
http://www.spoj.com/