Tag: codingdojo

Last week’s coding dojo session was a special one, not only because we brought a cake 🙂 but because it marked the first anniversary of those sessions at Murex Beirut. One year ago, I wrote a post sharing my experience on how we started this activity. Today, I am writing this post to share what has changed during this year.

Widening the scope

After twenty-eight sessions of practicing TDD, we decided it was time to adjust the scope a bit! Frequent attendees grasped TDD pretty well and suggested that we might benefit from those sessions to learn new technologies and practices.

After a brainstorming session, we agreed to label the session by one of four themes: Algorithms & TDD, New Languages, Kata & Workshops, and New Projects. We thought that by applying those themes we would increase the technical knowledge of all attendees, involve volunteers in the session preparation thus improving their presentations skills, and probably attract wider audience

Themes

Algorithms & TDD

We are all aligned that our primary purpose of this activity is practicing TDD, but in the case of complex algorithms using TDD is not always the optimal way (sudoku for example). Thus, we decided that in such cases we first would agree on the full algorithm then implement the code and write the sufficient tests to cover the different cases!

Lately, we’ve been using CodinGame to solve complex puzzles and algorithms, as the tests are already written, and they have an excellent graphical simulation of the puzzle execution.

New Languages

Learning new programming languages is one of the best approaches to improving someone’s programming skills; especially, when it includes learning different programming models (OO, functional, procedural, etc.) For those sessions, a volunteer learns the language alone and then presents it to the group in any form he/she prefers.

Kata & Workshops

We defined kata as a presentation or short talk on a particular subject given by someone knowledgeable on that topic. A workshop, on the other hand, is a collaborative session where all take part of experimenting something new.

So far, we’ve had five of those sessions:

A workshop on Git.

Two kata sessions on machine learning.

One presentation on Java agent and one on Android development.

Design patterns, development processes (Agile, lean, pair programming, etc.) and tools (docker, Gradle) are some of the candidates to be presented in next sessions.

New Projects

This is probably the hardest theme! The idea here is to implement an internal tool or app that can benefit other employees. Contributors to this theme will benefit from practicing TDD on a big scale project and learning new tools and technologies.

At this point, we are preparing a short list of proposals to get approval on one! Hopefully, we can kickstart it soon 🙂

In Numbers

We initially started with thirty-four registered participants, but that number dropped to fourteen. Honestly, I think this isn’t a bad number!

The below graphs show the distribution of all the forty-seven sessions we’ve had so far. The graphs are grouped by theme and topic / language.

By Theme:

Number of Sessions per Theme

Percentage of Sessions per Theme

By Topic / Language:

Number of Sessions per Language or Topic

Percentage of Sessions per Language or Topic

More to Come

Thanks to the participants’ commitment and their eagerness to learn and improve their technical skills we celebrated the first anniversary of the coding dojo sessions. We will keep running those sessions, and we will keep improving them as we go! I hope that in one year from now, I will be posting another blog to share what we have done 🙂

Two weeks ago we started running coding dojo sessions at our offices in Beirut, the first sessions we had so far were much better than what we expected. In this article, I will be sharing my experience (as the one running those sessions) starting from the preparation and ending by the feedback on those sessions.

What is CodingDojo?

CodingDojo is a meeting where a group of people gets together to solve a programming challenge following TDD. We select those challenges from several online sites like Google Code Jam and Cyber Dojo.Each dojo session is planned to take 2 hours including a 15-minute retrospective at the end and is scheduled once every week. All the participants are contributors, as we rotate on the driver (one who is coding) every 5 minutes. Thus, it is important to limit the number of participants per session to a maximum of 8. We carefully chose the session timings to be during lunchtime from 12:00 to 14:00 in order not to interrupt participants’ usual tasks. Finally, it is important to note that the participation to those sessions is not restricted to specific teams, rather anyone regardless of their programming expertise is welcome to join. After all, codingdojo is a place where we take knowledge sharing to the extreme.

From Paris to Beirut

It started almost 2 years ago as an activity within our team members only, but 8 months ago it was changed to involve interested people from other teams (in Paris only) as well. By the end of each session a 15-minute retrospective was held, during which we have always received positive feedback from the participants. For them, it was a chance to learn how to write code following TDD, learn new programming languages and techniques and enjoy a teamwork spirit to solve a programming challenge. We decided to leverage on the experience we gained in Paris and start similar sessions in Beirut. At that point, we had no clue on the participation level or its success rate but it was a risk we were willing to take.

Preparation

The first step of the preparation was to contact the HR team asking them for sponsorship as such an activity involves communication and involvement of many teams. We had a meeting with them, explained what codingdojo is and what is expected from those sessions; as expected, they were very supportive to such an initiative. They granted us their sponsorship and offered their help in global communication, coordination with the administration to provide lunch for participants and whenever needed later.

Second came the technical preparation for better running and managing such an activity. Writing code following TDD became a habit as I have been doing that for more than a year and a half (since I joined my new team). But still I decided to practice more by solving some challenges outside working hours.
For me managing such sessions was the main challenge and a new experience. For that, I started attending (via Visio conference) the sessions managed by Philippe (my teammate in Paris). During which, I tried to benefit from Philippe’s experience and save tips and advice he provided. Finally, we also agreed with Antoine (my teammate in Paris) to visit Beirut and assist me in running the first two sessions.

Communication

After setting the start date to be on Wednesday, July 15, 2015, we sent a communication email to all Beirut employees announcing the kick-off of codingdojo and opening the door for registration. In less than one day, more than 30 participants were registered. That was a surprise!!! We weren’t expecting that many participants, especially that many of them were not developers. Since running a single session with 30 participants was impossible, we decided to divide the participants into 4 groups/sessions over the following 4 weeks.

First Two Sessions

For the first 2 sessions, Antoine and I prepared very well by selecting and solving the problems ahead of time. Despite that, we made sure not to impose our solution, rather we tried to have an open discussion and agree with the rest on the next tests to write.The first 30 minutes of both sessions were the hardest. Almost all participants were not familiar with the concept of writing the test before the code that is why we made sure to be the first 2 to drive the code and when someone was coding you would hear us saying “That is correct, but you forgot to write the test!” when others were coding. After that, things started to go smoother! Participants got acquainted with the concept and were aware when they missed the tests. For us, the first two sessions were great and much better than what we expected. We expected to have someone trying to control keyboard or dictating his solution. On the contrary, everyone respected the 5-minute limit they had. They were all sharing the solution with others. It was clear to us, from the feedback (listed below) we got from participants during the retrospective, that they enjoyed their time and are willing to attend future sessions:

Nice, good experience; you learn from others

Nice technique to learn when trying to write the first test and nice way to think incrementally

It is hard to do it alone; it is easier with a group

I am not a developer and not familiar to Java, but it was good to see the mindset of the developers

Nice to meet people from other teams

Nice practice because you are enforced to follow a convention; taught us new best practices

I like the idea of refactoring; the complex code was refactored into couple lines of code that made it more readable

TDD is a bit slow; the pros are the interaction between each other

My Feedback

Running those sessions is not an easy task, it requires a lot of effort before and during each session. Before any session, the leader should prepare the right environment for the participants. During the session, the leader should always be focused on what the driver is writing and at the same time listen to suggestion proposed by others and answer the questions raised.
Despite that, it is a great experience from which you learn and gain a lot.
Later in coming sessions we might be introducing some new challenges like increasing the problem complexity or trying new programming languages. I hope that people will remain motivated and enthusiastic to attend the coming sessions!

P.S: The code we write during those sessions will be committed to this GitHub repository.