Greater Sum hosted the annual Global Day of Code Retreat in Atlanta last week, and if you’ve never attended a Code Retreat you are definitely missing out. The day starts out by getting a bunch of developers together. You do not have to have any certain skills or certain experience level, in fact, the more diverse the better. Throughout the day we work in pairs to solve a problem. For each session, you must switch who you are pairing with, the problem remains the same but different constraints are applied. This type of structure adds valuable insight because you get to work with a variety of programmers from different backgrounds. The knowledge you get exposed to is diverse, even if you are all using the same language. It is encouraged for you to pair with someone who knows a language you are at least familiar with. If you aren’t an expert, that’s ok, just find someone who is confident they can help you find your way through the problem. You may just learn something in the process.
Typically the sessions are not long enough to solve the entire problem. This helps to emphasize that it’s not about the end result, but the journey we are on to get there. We have a quote hanging in our office at Greater Sum by Dave Thomas that says, “Often the true value of a thing isn’t the thing itself, but instead is the activity that created it.”
“Often the true value of a thing isn’t the thing itself, but instead is the activity that created it.”
This is a quote I come back to often, and I think helps to describe the true spirit of the Global Day of Code Retreat.
This code retreat was particularly insightful for me because I had never attended one before. Before we started we went around the room and introduced ourselves. We talked about which languages we knew best and which ones we were interested in learning. This was helpful in finding someone to pair with. You could pair with someone who was fluent in Python if you wanted to learn more about Python. You could pair with someone experienced in TDD if you wanted to learn more about TDD.
Using Test Driven Development was a requirement for certain sessions. For those of you who are not familiar with TDD, something I’ve learned is that it can be quite difficult to change your approach to problem-solving using the TDD technique. If you are not familiar with writing unit tests, this can also be a learning curve. TDD changes the way we write code, for the better, but it can seem a little backward at first. Typically programmers try to come up with the end result right away. They try to account for all the edge cases and the most efficient ways for the program to run. If you are familiar with TDD, you know that in TDD we emphasize taking small steps and getting to a passing test as quickly as possible. This aspect can be especially hard for more experienced programmers who are used to jumping right to the final solution.
in TDD we emphasize taking small steps and getting to a passing test as quickly as possible. This aspect can be especially hard for more experienced programmers who are used to jumping right to the final solution.
While I learned something from all the sessions I participated in throughout the day, my favorite session is when we had to Ping-Pong pair without being able to speak to our partner. At first, I was nervous that my partner wouldn’t understand what I was doing or how to pass the tests. However, as I was writing the tests, he would make them pass. If he wrote something that seemed incomplete, I would write a test that would make him finish the implementation. I was literally driving his code. It was fun. It really was a great example of how we can use tests to drive our code. Another session I found interesting, is one where we were not allowed to use conditional statements. This was actually very interesting because although some people said they literally couldn’t solve the problem, others found alternative ways to write their code and said it was actually written better than if they had used the conditionals. The restriction forced us to do something we were uncomfortable with and the end result was better code. I think that is a lesson I won’t easily forget.
The restriction forced us to do something we were uncomfortable with and the end result was better code. I think that is a lesson I won’t easily forget.
Although I learned many things at my first time attending this retreat, the thing that stuck with me the most was the importance and boundaries of the techniques that we call “best practices”. It was fun to get to program with more experienced programmers but also valuable to teach some people as well. If you’d like to attend a Code Retreat, the Global Day of Code Retreat is held every year in cities all around the world. You can sign up or find an event near you at coderetreat.org. Happy coding!