Bootcamp
In go-jek every new recruit has to go through the engineering bootcamp so did I. It’s been 3 weeks now and I will walk you through my experience of these 3 weeks.
The first part of our bootcamp is CORE ENGINEERING bootcamp, it was taken by sidu ponnappa, member of the Board of Directors of GO-JEK and Heads Data Engineering. In this part of the boot camp learned about how to write code which is easily maintainable and scalable.
Clean code
Express Intent
I still remember my coach said to us that never name a method/variable the first thing which came to your mind try try try until it makes sense. A reader should be able to read your code and just by seeing the name he should able to understand what is it this code does if it so then your code is worth spending time for. Not only code your spec name, your git log everything from start to end you write should express intent. This principle stands above all other principles we have been taught until now.
Etiquette
We all have to follow some basic programming etiquette these are non-negotiable etiquettes why, because if you even miss one of them in your code you have to rm-rf (delete) your code and start again.
All the etiquette seems very basic and easy to all of us, but soon we realize how hard to follow even simple basic etiquette.
If it’s obvious then it is obviously wrong
TDD
As the software system are complex and our brains are not sufficient enough to handle the complexity of it. What we must do is to break it into small pieces. TDD helps us to do that by narrowing the scope of the problem as we are working on the small unit and by integrating those units to create something bigger.
- whenever you start writing code you first break it into small units and then pick each small units and try to write specs of these small units.
- Then you write the minimal code which make those specs to pass.
- After that refactor it to eliminate all duplication created in merely getting the specs to work.
Why to work on a master branch
Most of the Open source follow this then why it is bad Because they compromise with speed as there are so many contributors and they can’t be trusted. On the other hand, while working on the floor speed of delivery is important if you are not working on master there can only be one reason.
- You don’t trust your team.
Pair Programming
Among all, the hardest thing I did was this. It’s hard but at the same time, it is helpful, when you pair with one of your team members and to solve a problem the first thing is to convince your pair to follow the approach you have in mind or get convinced. Whenever you program your pair help in rubber duck debugging. Not only that most of the time you argue each other about so many things but then you have to find best way out of the problem.
Communication
Other than technical teaching, our coaches also focus on teaching us how should we communicate. we have been taught that what should avoid fallacies like Argumentum ad populum, Anecdotal evidence, Circular reasoning, Narrative fallacy and also that how Reductio ad absurdum can be used to disprove an argument.