The Joy of Coding: GO-JEK’s First Code Retreat

By Satyajeet Kanetkar

You know the story: it’s twelve in the night, your eyes are red, the screen is bleary. You tell yourself, “Let me take this shortcut, I’ll rewrite it later”. But you never do. The ‘shortcut’ lives on to become a huge monster that is now supported by an entire team. Maybe a good night’s sleep would’ve been a better idea after all?

Developers around the globe want to write good code, but don’t, due to the often cited chorus, “business reasons”.

Software Development is one of the few professions where practitioners are expected to sacrifice quality for speed almost on a daily basis. Teams are said to have incurred Technical Debt when they knowingly sacrifice code quality for increased development speed (in the short term). It’s a fancy term, but the analogy of treating inferior quality as ‘debt’ works well. You can sustain only so much debt before you collapse under its weight. You need to repay the debt by rethinking your decisions and correcting shortcuts you or someone else took.

Given all of the above, the skill of knowing when to take a shortcut and when to do it right becomes crucial . You must know how to build the hack and how to fix the hack. Developing this ability is one of the most important exercises you can do as a software developer.

What is a Code Retreat?

In the frenzied race to market, nobody asks how we write code on a given day. A Code Retreat is just that; asking how. You set aside a nice sunny day just for code. You talk about the process of designing, writing, testing, building, naming, reviewing code. It’s a revision of the basics.

For example, you spend time implementing the solution to a dummy problem (usually Conway’s Game of Life) in the best possible way, many times over. It’s code without compromises, without pressure to ship it in time or a manager hovering over you.

After every round, you discuss in detail what you understood from the process, how a problem was approached, issues faced, the attempts to solve them and how the progress made. And then… delete all the code and start over!

At the end of the day we share lessons learned and how they can be applied to daily programming. Often, new techniques are discovered, others are found to be lacking, and some prove their importance time and again.

How we did our first Code Retreat

We got a total of 12 volunteers for the first session. (Simple rule: The lesser, the better.)

Niranjan Paranjape, our CTO, was facilitating the exercise. Yes, our CTO. Everyone at GO-JEK codes. It’s one of our coreengineering principles.If your CTO ever has a session, make sure you grab the opportunity. The day was structured as follows:

• 7 rounds, 45 minutes each
• Each round had a special constraint with it’s rationale explained by the facilitator.
• Delete all the code (rm -rf) at the end of each round.
• Pairs would be shuffled after every round. No two people could pair more than once.

The problem to be solved was Conway’s Game Of Life, with the following initial guidelines:

• One must pair with someone
• Pairs must follow the ping-pong pattern. One member writes the test and the other writes the implementation. They switch between these roles after every iteration.
• The pair must follow TDD (Test Driven Development).
• The programming language must be chosen such that both the participants in the pair are familiar with it and at least one is proficient in it.

First Round

• Everybody was getting used to the idea. Nobody is used to being asked to write the best possible code they can.
• A lot of pairs spent most of their time discussing their approach on paper.
• Only two pairs got far enough to write their first test.
• Retrospective: Spending too much time upfront leads to analysis paralysis and other related disorders. Pairs should get to writing tests for the smallest possible functionality as soon as possible.

Second Round

• Constraint: Implement the solution without using a pen and paper.
• Most pairs had issues establishing conventions and deciding on a modus operandi because the only written form of communication was code.
• Retrospective: Two ways to TDD: Top-Down and Bottom-Up. Top Down is more exploratory in nature; when you don’t know the problem domain. Bottom-Up is suited when you know exactly what you’re building and even have some of the parts lying around.

Third Round

• Constraint: Implement the solution while trying to be the evil implementer.
• The implementer must write the minimum necessary code while being as evil as possible. Evil means implementing the code in a way which is completely unexpected by the test-writer.
• Most pairs felt that looking for the most evil way to implement a test was an excellent way to come up with formidable tests that otherwise wouldn’t have existed.
• Retrospective: Thinking up unusual ways to implement a solution often reveals gaps in tests that are otherwise missed.

Fourth Round

• Constraint: Implement the solution without speaking to your pair, aka, silent pairs.
• Some pairs found it difficult, and kept removing their pair’s code. A few others claimed to have achieved zen mode and requested that the remaining sessions be the same way. 😛
• Retrospective: Pairs often spend needless time discussing solutions upfront instead of aiming to achieve the minimal functionality asap and iterating later.

Fifth Round

• Constraint: Here the two members play a different role: the one who writes code plays smart, while the other plays dumb and asks as many questions as possible. They keep switching between these roles.
• This forces the implementer to write the code in the most readable way possible. It kills the urge to come up with crazy one-liners and terse pieces of code that do too many things.
• Retrospective: Often the effort needed to explain code is much more than just simplifying the code itself.

Sixth Round

• Constraint: Implement the solution without a fancy IDE or editor 😱
• This round establishes one’s dependence on compilers, IDEs, editors and other tools that make development easier. It serves as a reality check of one’s proficiency in a programming language as it requires you to set things up from scratch.
• Participants were found dealing with issues which revealed gaps in their knowledge of the language.
• Retrospective: You will discover something new about a language when working without IDE superpowers.

Closed Circle

• At the end, we had a feedback session where everybody discussed their experience and the lessons learned.
• Participants talked about their experiences, how they felt while programming in a way they’d never done before.
• People shared what they thought could be improved in the exercise, what it lacked, and what it got right.

What came out of it? (tl; dr)

We experienced first-hand the importance of some ideas that can be easily applied in day to day programming:

• Reducing time to the first test. Iterate on the design by adding more tests as you go.
• Two Paths: Top-Down: where one starts writing tests for the higher level components and slowly drills down to the ‘leaf’ nodes. (it’s okay to have failing tests) and Bottom-Up: where one begins with the most granular components and builds them out completely before moving to higher levels.
• Do TDD like you mean it. Write/modify tests first, no exceptions whatsoever.
• Evil implementations are good for you. The tipping point where you need to write the ‘correct’ implementation is not as far as you think it is. Attempt to write the bare minimum code to make tests pass.
• Pair more, Talk less, Move Fast. Don’t spend time designing upfront, you ain’t gonna need it.
• Do not depend on IDEs, understand their magic. IDE specific features are often proprietary and the automation is unusable in restricted environments. IDEs hide complexity which can crop up in awkward places later on.

Code Retreats are Fun. Do them often, do them rigorously. Happy Hacking 😃

If you want us to open this for all, please do leave a comment. We’re kick-starting this in Bangalore for now. Hoping to have more sessions in Singapore and Jakarta. Or… If you want to hack with the best, the easier thing to do would be to join us 😉. Check out gojek.jobs for more.