When you attend Coderetreat for the first time

Cover Image for When you attend Coderetreat for the first time
Sergej Brazdeikis
Sergej Brazdeikis

Why this blog post

I did attend my first Coderetreat event and I wanted to share my learning experience and also give tips for those who are considering to attend it for the first time.

A Coderetreat is a day-long, intensive practice event, focusing on not getting things done, but on process quality of doing it.

My experience

I went to the event open minded having pretty low expectations:

  • Wanted to see variations of how people are solving exactly the same problems in the same conditions
  • Saw it as possibility to do networking

Event program

The event started early morning 9 am until 5 pm. It was consisting of sessions with the same length of 45 minutes:

  • Three sessions until the lunch at 1 pm, and another 3 sessions afterward.
  • During each session attendees did work in pairs.
  • After each session new pair created.
  • After each session the code gets deleted.
  • In between the sessions short 10 min retrospectives and 5 min breaks were happening.
  • After all the sessions there was longer feedback session to wrap the even.

The problem we were solving was to create a Pacman game.

Constraints

The sessions had combinations of challenges and Constraints:

  • Pair programming.
  • TDD only approach. Write tests before writing actual code.
  • "Ping-Pong" game while pair programming:
    • Person A writes a failing test.
    • Person B writes code to make the test green.
    • Person B does refactor while keeping it tests green.
    • Person B writes a failing test.
    • Person A writes code to make the test green.
    • etc.
  • Name code parts after real intentions - self-explanatory function names, class names, test names and etc.
  • No code duplications.
  • As few elements as possible.
  • Naming all objects as verbs.
  • Do baby steps: while playing the "Ping-Pong" game we had only 2 min to write a failing test and then make it green.

The last one was really fun me - especially when you are not familiar with German keyboard and are not used to PC keyboard :)

The learnings

While solving the problem under different constraints I did find following learnings:

  • 2 min "Ping-Pong" game:
    • Knowing well your tools is important. It directly impacts your development speed.
      • Know the shortcuts of your IDE. It saves a lot of time.
    • When in a hurry, we tend to reduce the quality of the code. Instead of this:
      • Enable other time-saving techniques like using IDE shortcuts and etc.
      • focus on less - do what is actually important.
    • In general time limits makes you focus on things that actually matters.
    • It is possible to write really really small test cases and still have a good progress with the code.
  • Pair programming
    • I saw once again that it is very non-common practice in day to day developers life. Many people were seeking to practice it.
  • Few elements as possible
    • There is a tendency to create classes for everything. Even when we don't actually need them. Having this constraint pushed us to think if certain classes were really needed. The result code had fewer classes with same code quality.
  • TDD
    • If it can be applied in crazy conditions like "2 min Ping Pong game", it definitely can be applied while working in your company :)
    • It can be very natural technique. It was very strong feeling when everyone around you is doing it.
    • It makes you focus on writing the code which is actually important. No useless or not so needed code.

I've learned about the existence of the product JetBrains Toolbox. For me as the IntelliJ fan that was still a surprise.

One more thing - I really didn't expect that the code without if/switch/while statements can be so satisfying. Oh yea!

Memorable phrases

I've heard some phrases which did stick to my mind and are worth mentioning:

  • "Writing software is like an art. You refactor it until you start liking it."
  • "Pair programming is more like a rally than formula one. There is a pilot, who is writing the code and there is a navigator who is the brain and navigates the direction of the code."

What I liked the most

The ability to pair program with 6 very different people in a single day. You can reassess your mindset, habits, and way of solving the problem in a very rapid way.

The quality of the event. It was clear what happens when and why. The open feedback approach on everything was great. Only good words about the event.

Networking with professionals. People were more open then on the meetups or conferences. It was very good atmosphere during the event.

Tips for newcomers

It is a learning day

Have positive mindset about the event. You will learn many things. Optionally you can aim to gain certain knowledge:

  • like practice certain language
  • learn on unit tests
  • learn on TDD
  • etc.

If you don't know well certain frameworks or languages - it's not a problem. It is a learning event. Everybody is coming to improve on these topics.

Development environment

Before coming to the event spend a time on setting up the development environment for the languages you want to develop with. There will be no time for this during the event. Only the failing test is needed.

There is a repository with many languages prepared for this type of event already - https://github.com/swkBerlin/kata-bootstraps

Last words

The attendees gave positive feedback about the event and the sessions. I did not hear a single person who didn't like the event. From my side, you probably already see that I loved it. I will definitely do it again.

Also, I do recommend to every software engineer to attend at least once a Coderetreat event. You will learn a lot of stuff for sure. The only question is how much you will remember. These are events happening globally. You can find one closest to you.

I really want to thank the organizers - Software Craftsmanship Berlin for such a great event! Thanks a lot!

Next step for me - apply learnings in the day job.

Thanks!

Sergej Brazdeikis
Sergej Brazdeikis