It’s 2020. I still can’t believe time flies that fast :] I’m now working as a software engineer (iOS specialist) what I have been doing for over 2 years since I graduated from university and… I’m still alive :woohoo: Sounds great!!!
I really enjoy this journey… There are a bunch of things that I picked up day by day and they are very interesting…at least for me.
Some might already know and some might not. I’ve been working at Grab since last year. I’m very proud of being a part of this company where I’m working and contributing to “Driving Southeast Asia Forward” mission. So, first thing first…
What is Grab?
Yea! What is Grab 🤔 From Grab’s LinkedIn.
Grab is Southeast Asia’s leading super app — providing transportation, logistics and financial services. We aim to solve key problems in the region and improve the lives of millions through technology.
Grab now has R&D centers in several countries: Singapore, India, USA, Vietnam, Indonesia, Korea, China, Malaysia, Romania. Not sure if I missed any places.
So big? is it? Grab? With thousands of engineers and numbers of R&D centers, we have currently, I consider Grab as a big tech company… hmm at least in SEA. It also the biggest one I’ve worked for so far.
Check out #GrabLife and we’re hiring :3 https://grab.careers/
Let’s see what I’ve learned so far…
Code quality
Yes, sir! Quality. I’m talking about code quality here at Grab where every line of code is counted. Make sure the code delivered with the best quality is one of the highest responsibilities of an engineer.
Unit tests are the first-class citizen, code coverage and automation tests are also our engineering OKRs. If your code is not good enough, it never gets merged. To ensure high quality, we have a group of engineers who are always ready to look into your code whenever a Merge Request is submitted. And there is a CI to verify the quality of your code as well: all unit tests UI tests are passed, the convention is followed, code coverage is over the baseline,…
I couldn’t remember how many comments I got for my first MR 😣 I just remembered one rule: If u don’t wanna be ashamed, your code has to be good :<
Documentation
The 2nd thing is about documentation, one of the most important things. I’ve learned how to keep reading a loo…ooong document patiently what I couldn’t do previously. Because without reading the documents, I can’t even do anything. I have to have enough knowledge about the problem we wanna solve before actually solving it. And good understanding of the docs helps you easily find edge/corner cases beforehand. So understanding docs is a MUST.
Not just about reading, I’ve learned to write docs in a proper way.
Honestly, it is not the first time I’ve written a document at Grab. In my previous company, I wrote a bunch of engineering documents which were for engineers (only). That’s the main difference.
Now, I write documents for broader audience. The documents are not only for engineers anymore but they are also for everyone who is working on the same project. From PM to QA, to designers, to all stakeholders, and to…my manager. I have to make sure everyone is on the same page and has the same knowledge on the matter.
New Software Architecture “RIB”
The definition from RIB’s Github:
RIBs is the cross-platform architecture framework behind many mobile apps at Uber. The name RIBs is short for Router, Interactor and Builder, which are core components of this architecture. This framework is designed for mobile apps with a large number of engineers and nested states.
I won’t tell very detailed about what is RIB, how to use it, what are the benefits of using it??? As there are thousands of articles out there already mentioned the same thing. I will drop some links below instead :D
I would say that I like it. Actually, in the beginning, I saw it a bit similar to VIPER, which I already had experienced earlier, so it wouldn’t make me confused at all. Unlike other architectures, such as MV*/VIPER, a RIB doesn’t have to have a view, it can be pure business logic. The elements like presenter and view are optional for RIBs. From my own experience, I rarely create a presenter. Routing is guided by business logic rather than view logic. RIB seems to be built on the concept of business logic driven 🤔
A/B Testing?
Yay! the most interesting part. I hadn’t done that many A/B testings before Grab.
There are so many A/B testings performed every day. The main purpose is to understand user’s needs, offer the best experience for them and to experiment with our initiatives as well.
Every feature is back by a feature flag. A feature flag is basically a command-line switch that is built on a very basic concept of programming…condition statement (if-else, switch-case). It’s a way of decoupling feature releases from deploying code. It also helps us control the rollout and ability to rollback when an incident happens.
With the numbers of experiments, we perform these days. I’m not sure about the exact number but it would be HUGE. There was one more thing I picked while working on this. That is to stop being over-engineering, let’s come up with cheap solutions first. The cheap solution counts on how much effort/time it takes to build something.
Yeah! u don’t hear it wrong…CHEAP… we definitely don’t wanna put so much effort and time into something that may be deleted after a few weeks of experimenting. Honestly, engineers love cheap solution, my manager loves cheap solution, the product manager loves cheap solution…we all love cheap solution :3
The first time…a lot
I couldn’t remember exactly how many new terms/definitions I heard during the first week at Grab. There were so many first times here 🐼
The first time being an on-call engineer
So being an on-call engineer means you have to be the first one to acknowledge when incidents happen. The responsibility of an on-call engineer is to understand what goes wrong and drive the resolution, maintain reliability and availability of services. The on-call engineer has to be reachable during the on-call shift in both working and non-working hours.
… being a release engineer
The next first thing is to be a release engineer. The release engineer is quite straight forward compared to the on-call role. The main responsibility is to ensure the health of the release branch. It means a build can be provided and distributed at any time. If it can’t, you’re better to get it fixed :3 (eg: compile issues). And one more thing is to remain the stability of the current release, this relates to crash-free rate.
… heard about RFC 😥
It’s true that I hadn’t heard about it before I joined Grab which was invented in 1969 😞
RFC means “Request For Comments”. This is a practice used at Grab by all teams to share engineering designs with the intent to gather feedback for improvement and avoid development collisions.
This is a great source of learning. I have learned so many things through this process. And also shaping my head for upcoming projects.
Conclusion
That’s a great journey at Grab where has been teaching me so many things where I learned from world-class engineers around the world, where I’m inspired/motivated every day to keep up the good work, where I’m encouraged to step out of my comfort zone to reach the bigger goal…and we’re still hiring. Let’s check out the career site: https://grab.careers/
Actually, I can’t mention all of things in this post to keep it not too long. These are a few highlights. There are many more interesting things purely on the engineering side that I’d love to share in another post. Thank you all for reading ❤ ❤ ❤
