On my second internship program, I got a chance to join GO-JEK’s internship program, that called GO-SQUADS. I think this internship program will same with other internship program that what I knew. The internship program that I had knew before is at the first day you will given the project description, assign the buddy, and introduce the team that you will work with.
But here I face different thing. At the first week, I join the mini coding bootcamp, there is no project assignment yet. At the mini bootcamp, I learn a lot of best practicing TDD as well. I also must follow the NON-NEGOTIABLE CODE RULES. If I brake the one of the rules, somehow I can find my code anymore, and it happen so often to me. So, here what I got from the bootcamp.
1. Keep it simple and stupid
When I given a problem statement, I need to figure out what classes, methods, and attributes should I create to solve the problem. After that, I create the method, auto generate the code that can be, implement the method, run the code, and done. Simple right?
But did you know? The solution that I created is complex. I create all the stuff by my instinct and actually I didn’t really need all of them to solve the problems. From this I learn the most important point is to fulfil the specification. Even my code is not good enough I can refactor it later.
2. Never love your code
The NON-NEGOTIABLE CODE RULES are my guideline whenever I write my code on the bootcamp. Even my code is good enough and have a comprehensive unit test, but if I brake one of the rules I should delete my code (rm -rf). I got twice rm -rf tragedy right before I start my code review.
From this tragedy, my code is not important thing. I had learn that following the rules is the most important things because I can create better code when I follow the rules. For example, one of the rules is comments or unused code should never be committed. So it’s better to create a good code that can explain itself rather than add comment to my code. When I refactor my code later I didn’t need to update my comments.
3. Commit message is my documentation
Every time I will start my code review, the first thing I need to show is my commit messages. Before I show my code, everyone should understand how it developed. So, if my commit messages not easy enough to understand, the reviewer cannot image how it was. 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 even it not listed on the NON-NEGOTIABLE CODE RULES. I image when my team cannot understand what the changes I did and should contact me to ask it. I will wasting time when my team ask me every time I do commit. Even though the commit message is getting longer, it’s okay as long as it clear.
Can you see the similarity from each point that I explain above? 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.
So, from the bootcamp, I feel the coaches guide me back to basic, to learn what I didn’t learn on collage. Being comfortable with the basic one will lead me to create an awesome one. Hopefully, GO-JEK will make another mini coding bootcamp so others students out there can join it. Maybe mini coding bootcamp to learn specific things like learn Go Lang, System Design, Microservices Architecture, and others technologies.
Cappy Hoding! 🖖🏾