Conducting a Coderetreat


  • Identify the number of attendees you would be hosting.
  • Calculate the number of facilitators you will need for those many attendees. The attendees are divided into a team of 6–12 and once facilitator is needed per team. Have some additional facilitators for backup.
  • Identify the facilitators in your organisation. Whoever is passionate about programming can become a facilitator.
  • It would be good if the facilitators have experience of Coderetreat. You can run a Coderetreat internally (or approach us, as long as it is a community event, we will help you for free).
  • Announce the event online. Make sure that you register the event on
  • DO NOT FORGET to ask attendees to bring their laptops with favourite IDE and language installed and ready to use.
  • One of the facilitators should be the main facilitator who will take the entire crowd through the Coderetreat slides and the problem statement at the start of the event.

On That Day

  • The crowd gathers at one place at the host’s location.
  • The host will welcome the attendees.
  • The main facilitator will take the entire crowd through Coderetreat slides that consist of the schedule of the day, 4 rules of simple design, TDD, pair programming, problem statement and retrospectives. Remember that the main facilitator has to take the people through the entire slide deck.
  • Announce the time when the event would end and people have to get back at the same place for the final goodbye.
  • The crowd is then divided into groups of 6–12. The number should be even as pairing in involved. DO NOT GO BELOW 6, we need to have unique pairs for every session. 6 will make sure that there are 5 pairs for 5 sessions.
  • Regarding dividing the people into the group of 6–12, there is one way to do that. While the people enter the host’s location, they can be handed over a number starting from 1, 2 and so on. When the host wants to start the event, they will always have the current count of the attendees. That count is divided into the number of teams (for instance if 60 people and 10 facilitators, the number of teams could be 10 of 6 people each).
  • Once the host has the number of teams, they can then start calling the numbers in a certain pattern (in case the team is of 6, the first team would consist of 1, 7, 13, 19, 25, 31. The second team would consist of 37, 43, 49, 55, 2, 8 and so on) or randomly.
  • Make sure that the team division is random. It is important that people who work together should not pair. So randomly breaking the crowd in groups will ensure that people land up in different groups.
  • If some attendees get late, they are distributed evenly in the team.
  • Every team gets a facilitator assigned.
  • If there are more facilitators then the teams, you can always have two facilitators per team.
  • Having backup facilitators would make sure that the situation of having fewer facilitators than the number of teams would be avoided.
  • In case the situation arises when the number of teams is more than facilitators, distribute those teams evenly in other teams.
  • Do not track the time centrally. Let the teams run asynchronously. The facilitator will take care of the timings for their respective group.

Problem Statement

  • The problem statement is usually Conway’s Game of Life.
  • You are free to choose any other problem statement of your choice. A few of them could be Langton’s ant, Tic-tac-toe.
  • The job of the main facilitator is to explain the problem statement. But he or she does not need to spend much time on explaining the problem. If people don’t understand they can always ask the facilitator of the team.

First Coding Session

  • First coding session starts with the introduction of the team and the facilitator.
  • Pairs are formed by the facilitator and the first coding session is started.
  • Provide a pen and paper to each pair.
  • First coding session usually is needed for understanding the problem statement better. So the first session only has TDD as a constraint.
  • It is important that the attendees learn about requirement gathering, and get rid of the habit of assumption. If the facilitator sees that some people have not understood the problem, and have already made the wrong assumptions, he or she needs to make them realize the same. In general, assumptions are dangerous. Developers can always verify by asking the correct person (in this case facilitator) or referring the material (Google).
  • To make sure that the people have understood the problem well, the facilitator can ask them questions regarding the problem statements (like ask them the output of a blinker pattern).
  • Make sure that the team members write clean code (good naming conventions, short functions etc.) and follow the TDD constraint throughout the session.

At The End Of First Coding Session

  • After 45 minutes, the facilitator stops the session.
  • The facilitator then makes the team members delete the code.
  • The team is asked to gather around and a retrospective is conducted.
  • The facilitator forms the next pairs, throws in a new constraint, and starts the next session.
  • Usually, 45 minutes of the session is followed by 10 minutes of retrospectives and 5 minutes of break. But avoid giving break after every session (as not everyone really returns in 5 minutes).
  • Depending on the team, facilitators can give breaks after 2 sessions or so.

Further Coding Sessions

  • Make sure that after every session, the code is deleted.
  • After the deletion of the code, the team is asked to gather around in order to conduct a retrospective.
  • It is usually a good practice if the team is away from their laptops during the retrospectives which help them focus on the retrospective. In case they are sitting in front of their laptop, they might start fiddling with the keyboard.
  • The questions during the retrospectives could be (but are not restricted to) “What did you learn from your session?”, “What went well in your session?”, “What didn’t?”, “What will you do differently in your next session?”.
  • For the next session, the pair is changed and a constraint is added.
  • Make sure that the team members write clean code and follow the constraints during the coding sessions.


  • Every facilitator has to make sure that the team pairs during the session.
  • The pairs should be swapped after every 45 minutes of the session.
  • The pairs should not be repeated.
  • If the number of team members is odd, then facilitator could either make three people sit together or facilitator could pair with the remaining team member. But the facilitator pairs, he or she also has to make sure that they keep checking with other pairs and their code at regular intervals.
  • Pairing is a wonderful way for the team members to learn. The facilitator has to observe the team and make sure that the pairs happen in such a way that everyone gets to learn something.
  • For instance, make a senior developer pair with juniors (so that the juniors get to learn) for a few sessions and then make the senior developer pair with someone using different language (so that the senior developer learns something new).


  • The constraint is the challenge that you throw in before every coding session. The problem remains the same throughout the day, it is the constraint that makes solving the problem more interesting.
  • Constraints are used to push the developers towards good programming practices.
  • The constraint that we usually start with and keep throughout the day is TDD.
  • Other constraints may or may not accumulate, depending on the constraint and facilitator.
  • For instance, the constraint for the second session is usually “no arrays” (helping them to choose better data structure). During the second session, the constraint provided during the first session (TDD) should also be used. The constraint for the third session usually is “no for loops” (pushing towards functional programming). During the third session, the constraint for the first session (TDD) and second session (no arrays) should also be followed.
  • But if you use a constraint like Code Swap (where the workstations are exchanged in the middle of the session, so that one pair continues working on code written by other pair, ensuring everyone writes readable code) may or may not be followed during the next sessions.
  • In short, the constraints that deal with quality or features have to be accumulated, whereas the stretch constraints and tooling constraints may or may not be accumulated. You will find a detailed list of constraints here.
  • Facilitators can give different constraints to different groups
  • Constraints completely depend on the facilitator.

Last Coding Session

  • Depending on when the event is going to end, which has been announced at the start by the host, the last session might extend.
  • For instance, if you have 2 hours before the event ends, you could easily have 2 sessions (45 minutes of session + 10 minutes of retrospective + 5 minutes of optional break)
  • If you have 2 hours 30 minutes for the session to end, you could have one session normally and extend the last session by 30 minutes.
  • In any case, whether you extend the last session or not, after 45 minutes you have to ask team members to stop coding, conduct a retrospective for the session, conduct a final retrospective for the day, and then let them continue coding.
  • The team members are not needed to delete the code during the last session. They can continue working on the same code after the session retrospective and day retrospective is done.
  • The final/day retrospective consists of the following question “What have you learned today?”, “What will you do differently in your job from Monday on?”.
  • As the time ends, the facilitator thanks the team and ask them to gather to the place where the final goodbye from the host is conducted.
  • If possible ask the attendees to tweet or write a social media post or a blog for that day and motivate them to be the part of next Coderetreat, either as an attendee, facilitator or host.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

UrlMapper Case Study: Coding

create a phone number

Switching from GlusterFS to Amazon EFS

Learning on Agile #1

Root Me: Active Directory — GPO

Unconventional intro to python — Mutability, higher-order functions and structured types (V)

Java Data Structures — The Building Blocks

Building Blocks of JAVA


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Siddhesh Nikude

Siddhesh Nikude

More from Medium

Rethinking Code Coverage

Soft Skills: As a developer remember to build relationships

Testing your API will never be the same….or easier!

Your Web Developer Abandon you?