Engineering Bootcamp at Go-Jek
Programmer needs discipline more than anything.
As a grad strait from the campus with offer letter from Go-Jek in hand, everyone’s exited and thirsty to solve the real life challenges for the first time. With the first step into our professional careers we entered Bootcamp program which is aimed to shape the way we code to make us write software that is scalable, maintainable and that works.
First thing we learn’t is
A programmer can write code that machine understands, but a good programmer writes code that humans understand.
Remember those instances where you revisit your code that is written weeks and months ago and saying to yourself ‘What the Fuck!’. You have no single clue what is your code doing or what does that variable named ‘X’ mean.

If your team is working together to build a product and nobody cares about writing clean code, you are headed strait into a bog in which you sink in. Maintaining your code base as it grows, becomes next to impossible. Slowly your basement’s walls starts cracking and ultimately one floor falls on another and collapses leaving debris.
Because your code will be maintained by other team mates, ownership of code changes, writing a code that follows community standard is as important as writing a working code.
As we are rookie programmers with a ambition of becoming a star developers, we setup some non-negotiable ground rules before we start coding. Punishment to violation is death of your code:
rm -rf my_loved_codeGround rules
Your code must be as clean as possible. Naming should show purpose of it’s existence. Avoid compression and loosing context.
- Indentation and spacing must be consistent across all Classes, Methods, Specs. Use only spaces for indentation.
Ex: Ruby — 2 spaces, Java — 4 spaces. - Have a new line at the end of every file.
- Follow community standards of the language/framework in naming.
Ex: In Java use camel cases, In Ruby use snake cases. - Follow a standard file and project structure of particular language.
Ex: For Java and ruby respectively.
.
├── README.md
├── build.gradle
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
└── src
├── main
│ └── java
│ └── com
│ └── gojek
│ └── bootcamp
└── test
└── java
└── com
└── gojek
└── bootcamp
.
├── Gemfile
├── Gemfile.lock
├── README.md
├── lib
└── spec
└── spec_helper.rb- Use namespaces. C++ provides namespaces. In other languages you can create a class that only consists of states(variables) to use as namespace.
- No comments. When your code is expressive by itself who needs comments. It’s our responsibility to make sure code provides understanding.
- No unused code must be checked in. You only write code to meet requirements, nothing more. Premature Optimisation is root of all evil.
- Runtime environment must be consistent with IDE environment and CLI(Command Line Interface). Because, at production level you have to configure and run code in command line.
- TDD. No code will be ever written without a test written and watched it fail. To know what’s TDD, here.
- Git and commit patterns.
1. After creating a standard project structure, do git init and commit with . author name in message.
2. Write the spec, watch it fail (RED), write a code that passes the test (GREEN) and commit with spec implemented message.
3. Refactor and commit. - Detailed README for every project minimum containing project description, Dev environment setup, Build instructions, Run instructions.
Any violation in above rules will result in a ruthless rm -rf.
Second,
If it’s not tested It’d broken — Martin flower
TDD and Unit testing
Writing a specification in terms of code and passing that specification helps us to keep the direction of code evolution crisp.
When we write code that might sometimes have 10’s of modules 100’s of classes, when a bug occurs, tracking the core of the problem becomes next to impossible. If you have automated unit tests you know exactly where the malfunctioning started.
Third,
Always know where you are and where are you headed.
Calibration day
Every first day of the week i.e Monday we solve popular problem of Conway’s game of life. When we solved it for the first time it’s working but the code is basically unmaintainable. Over the next 3 weeks of followed coding standards and TDD, we observed development in ability to write a code that can evolve faster.
We do Code cycles to solve a problem, which constitutes of 10–20 minutes of Dev cycle of writing specs and code that passes, code review and debate over different design approaches.
Only do shit you are proud of.
is the golden rule we follow in Go-Jek’s bootcamp 003. We can relate to times where we pickup a project to contribute but to understand boring pages long documentation makes us vexed.
Code in a way, to draw a context you don’t even need a detailed documentation, code itself is enough.
Have a good day!
