GO-SQUADS Tech 4.0 Engineering Mini-Bootcamp: An Unpredicted Journey

Aditya Singh Sisodiya
6 min readJul 18, 2021

--

For macOs : rm -rf
alias sudo = “sudo rm -rf” 🔚

On my recent internship , got a chance to join Go-Squad 4.0 which is an internship program held by first Indonesian unicorn leading tech company , GO-JEK . Before joining the internship my thought was ,it will be the same as my previous internship which I had knew before is at the first day you will be
given the project description, assign the buddy, and introduce to the team with whom you will work .

But here it was quite different and pretty interesting . Unlike most internship program, we were given a chance to have a hands-on GO-JEK’s mini-bootcamp along with highly experienced people from GO-JEK as our coaches.

On the first week of joining the Gojek, there were daily sessions comprising of soft skills which are relevant for our future journey in the tech industry such as Adaptability , How to give and receive feedback ,Time Management and here our first week came to an end.

Now on the second week (14th-18th June) comes the most awaited and interesting part of internship before joining the teams — The Mini Bootcamp!!!!!
Brief : Each day was divided into 3 checkpoints (morning, afternoon, evening) and each checkpoints added a new learning in the journey of bootcamp.So, here are my takeaways from the amazing bootcamp.

1. YAGNI (You aren’t gonna need it)

On our first day of bootcamp , we were handed over the problem statement ,cleared our doubts and gave some initial instruction :
1. Commits on atmost every 10 min

Keeping in mind about problem statement ,now I need to figure out what the code structure is going to be like, what all classes, methods, I need to create to solve the problem. After understanding the problem , breaking into smaller parts then implemented some classes and method, run the code and done. Simple right?

But did you know? The solution that I created was a complex one as it contains lot of redundant code which is not at all required to solve the actual problem . From this I learnt the important point of fulfilling the specification to the point.

“Discipline can never be taught. It is a self-learning process.”

2. Never love your code

We were introduced to a set of rules Non-Negotiable Rules (NNE) which usually used to got updated everyday after showcases . The purpose of the rules were to teach us some of best practices the way GO-JEK engineer’s had been implementing throughout their projects. It includes TDD , bracket format, uniform space, naming convention and lot more…but the main catch was if I have written a good code even with proper unit test, documentation but if I broke anyone any one of the rule listed in NNE , I have to delete my whole code (rm -rf) and have to re-write it again till next showcase. I got rm -rf twice everyday except last day 😌. It wasn’t delightful at first, but after a while I finally got used to do it and tried to be more careful next iteration.

3. Commit history is my documentation

We were informed to follow the baby step procedure means code break down the problem in every possible single step and then write the code and commit .Whenever , I start my code review, the first thing I need to show is my commit history (the best way to present it is tig ). Before I show my code, everyone should understand what was my approach towards building solution which can be shown easily through tig . If my commit messages are itself not self explanatory then the reviewer will not be able to imagine the thought process which I took to solve the problem and will also have to do rm -rf as these rule was also included in NNE . That is why every commit message should express intent. It means the commit messages should related and express the code changes.

Creating good commit message is important thing to do as the intuition behind the code changes get initialised with your commit message , if it itself express the intent of your changes then it decreases the load over you to explain your code to your teammates every times.
Would you like to do that ???
NO , then follow conventional commit 😄 from now onwards.

“Every decision is correct at the time it is made”

4. Good quality discussion

After the first task , each day we have to pair programming with someone whom we don’t know which was the most crucial part of this bootcamp . We were 22 so breakdown into 11 teams and almost there were 8–9 different ways to approach a single problem and we were told to converge on only one most feasible approach . Here comes the picture of the group discussion where each group have to tell why there approach is best from others, which led to good enrich debate between TDD vs OOPs concept. We were also trained to spot a fallacy or bias as well as not making one during our arguments or speech. Fallacy and bias are illogical mistakes that are made when a person want to point an idea or his/her argument.
The learning to takeaway is discussion is must before moving to any approach and has to choose a certain path between two divergent. (like in TDD vs OOPS we choose OOPs because problem statement was most feasible for it). Another one , whenever you have something in mind just speak it out , as it could’ve been the best idea for your team.

“75% of our time working is spent for communication, while the rest is for coding.”

5. TDD and Pair Programming

We were practicing two mandatory skillsets that required in GO-JEK — Test-Driven Development and Pair Programming. Test-Driven Development is a technique which encourages to write tests first before actually implement the feature or function. This technique also leads to our main subject here, which is to always start a problem with a small step.

Along with TDD, there is also Pair Programming. This technique help reducing mistake made by engineers with their work. How it works is two people will be solving one problem together, one person will be the driver (typing the code) and the other one will be the navigator (talk through what to code). That way, if there is any difference on how the implementation made, both of them should discuss and converge on one idea. Also, if there is any mistake made, the other person should tell the pair.

Did you notice one common thing in above all those points ? The similarity is all of them are BASIC. I didn’t need to learn about algorithms, design pattern, implement SOLID principle, and others to follow the rules. It is very easy to follow and the result will better.

Yup corona sucks 😶

So, from the bootcamp, I feel the coaches guided me back to basics, to learn what I didn’t learn on college. Being comfortable with the basic one will lead me to create an awesome one. Although this bootcamp is a short version of the real bootcamp (the real one takes up to 3 months), there were so much I learn, an unpredicted journey. Thank you GO-JEK, coaches, and GO-Academy for supporting us through this foundation program before we meet our real-world projects.
Thank you for reading my journey, see you on another blog 🙌

Scortier , Signing Off !!

--

--