As the part of my journey at Gojek, I am the part of the “Bootcamp” where we learn core software engineering principles, good coding practices and soft-skills like speaking and writing, all aimed to shape us into a better engineer in the future.

Before I joined Gojek, I was quite confident that I write good code and adhere to good coding practices. After a week at work, I realized how much of a fallacy that was.

A typical day involves Code, “rm -rf”, more code, followed by more “rm -rf”s. But it has taught me several fundamental takeaways:

Never love your code

Yes never love your code. This is the first thing we were told. We were given t-shirts with the slogan “rm -rf — Never love your code”. The essence of this is not that do not take pride of the code you wrote; code is art and you should be proud of it. But what actually means to not love your code is “Do not hesitate to change your code, if required, delete and start from scratch”.

Fail fast, fail early

Never carry a wrong idea/spec/code to the next stage. Appreciate failure and incorporate changes so that mistakes are not repeated. It’s good to catch a flaw when things are at their nascent stage than making a discovery right before release deadline.

Attain clarity before jumping to a solution

Unclear requirements and insufficient analysis are some of the major reasons why many software projects fail to reach a release. It is important to analyze carefully and detail down every tiny bit of the requirements even before writing the first line of code.

Swim together, sink together

Development is supposed to be teamwork. A failure of one is thus a failure for the entire team.

Code is art which is utilitarian

Quoting Sidu here. His explanation of why code is art was exceptionally brilliant. Code is an art form. Code is imagination of things expressed in logic. Hence, code should be beautiful in structure, in output and in execution.

The deadline was yesterday

Every customer reply to when do you want the product to be ready. Mostly, people are in a hurry to get things done and want the delivery faster. So its up to us to negotiate the proper timeline backed by informed estimation (which implies 3 above).

Explicit clarification is always better than an implicit assumption

Never make an assumption. There are just too many variables hidden in plain sight — culture, locale, language, way of living etc. all can be variables in designing a software. So when in doubt seek explicit clarification. This also helps to refine our deliverables and helps to set proper estimations.

Question everything

Implication of the above. When in doubt ask. Also, do not accept any pattern, design on directive without understanding the logical reasoning behind it.

Good code is not the substitute of bad documentation

No matter how beautiful and performant the code is, no one will use it if there are no proper usage instructions. Strive to make code self documenting, else it will supper from code rot and no developer will ever be willing to touch your code.

Test Driven Development

Let tests guide your design. Write a failing test and then write the bare minimum amount of code to make it pass. This really helps in iteratively implementing complex requirements with ease.

Automate all the things

Once, twice, thrice and now automate. If something is repetitive and takes more than 5 seconds, automate it!

Keep it stupid simple

Model your problem in simple English. It makes much more sense to self and to others about what the requirements are.

It’s been four days — days full of enlightenment about mistakes that I have been committing since the day I started coding. I’m anxious to know what else we will come across in the remaining 9 weeks of the Bootcamp.

Computer Whisperer. Open-source contributor. Find me at

Computer Whisperer. Open-source contributor. Find me at