What I Learned in My First Three Months at GOJEK

By Muhammad Abduh

Hi there! It’s been three months since I joined GOJEK as a product engineer. In my opinion, being a product engineer at GOJEK involves a lot more than writing code. The code is just a tool for us to deliver a product, and we use many such tools and skill sets to build our products. In addition, it is also necessary for us to learn new things everyday. This learning culture is big part of working at GOJEK.

In this post, I’ll give a rough outline of what my first quarter at GOJEK has been like, and some things I learnt along the way.

Into the deep end

As a new person on the team, I was encouraged to take action and ask questions if I didn’t understand something. In line with GOJEK’s Engineering Principles, we always do pair programming when writing code. Therefore, you can say your pair is your own mentor at the time since he/she is the one who you share your thoughts with.

Our code needs to pass several steps until it is ready to be deployed, such as: code review by a teammate, QA, and bug fixing. Stand-up meetings happen every day, 1:1 meetings with our managers are frequent, and of course, there are some team coordination meetings.

A month into the job, there was a critical task that involved the migration of a large number of services to another cluster (services that our team is responsible for were also affected).

Without giving it much thought, I accepted the task and paired with a senior engineer on my team.

I’ll admit, back then I did not fully understand the context and the whys and hows of the current system. I took the challenge because it felt like a great learning opportunity.

It was like learning to swim in the ocean. 😅

There were some takeways from the experience, however. Here are three things I learnt:

1. Language no bar

In three months, I have worked on more than three new programming languages: Clojure, Go, Scala, Rust. We have various codebases and my responsibility included bumping up dependency libraries, changing CI/CD scripts, running the code locally, deploying to integration and production, so on and so forth.

There was a time when my browser was full of Stackoverflow and Reddit tabs.

Honestly, it was not an easy thing to do. Another challenge was refactoring code not written by me. But it was all worth it. Even though I haven’t mastered all the languages yet, I am starting to understand more about them. Programming languages often have similar paradigms, syntax, and even structure.

2. Creating multiple VMs

We are still using VMs for some of our services. But thanks to Proctor — our open-source automation orchestrator — deploying our services into the cluster is easy. Proctor is simple to use, you just need to use Proctor CLI, something like proctor execute create-vm, and it will do the magic to create a VM for you. Don’t forget to use load balancer for some newly-created boxes.

For this case, we use haproxy. Thankfully, we also have a helpful infrastructure that uses chef, which enables us to remove human bottlenecks.

You just need to match the tags in the chef config of the nodes and haproxy boxes, and those nodes are automatically recognised as downstream nodes of the haproxy.

3. The top three tools

I have actually learned more than three new tools, but these are the top three that I can think of:

• Aleph/manifold library

Aleph is a library for concurrency in Clojure. In my opinion, it has a similar style to Golang concurrency, to some extent. You make channels, you pass the value, pipe it to another channel, deref it. Enough said.

• Redis hyperloglog

Hyperloglog (HLL) is an algorithm to count how many distinct values are in a multiset. Instead of calculating an exact cardinality of the very large dataset, it approximates it. While calculating the exact cardinality of the very large data sets require the exact number of memory proportional to the cardinality, HLL uses less memory for doing so. It claims that it is able to estimate cardinalities of >109 with a typical accuracy of 2%, using 1.5 kB of memory, which is significantly less than the memory requirement of conventional counting. Redis supports this algorithm, check the docs for more information (or watch this space for another article about Redis HLL in the near future).

• go.mod

Starting with Go 1.11, Golang supports go.mod. Before go.mod, we always needed to store our Golang code inside $GOPATH. Using go.mod, we can code in any directory we want (except $GOPATH, it is not advisable to use go.mod inside $GOPATH). The dependencies of the code will be stored in a go.mod file in the root just like pip requirements.txt in Python or package.json in nodejs did.

You can just go to the root directory of the code and it will get all the dependencies needed. The good thing is, you don’t need to worry about the dependencies version because go.mod will not update our deps version automatically without being asked.

To wrap up this article, these are some of the things that I have learned in just three months at GOJEK. If you are as excited as I am to learn new things, head over to gojek.jobs, choose the position you are best suited for, and click apply. 👍'

As you can see, we have no lack of hard technical problems at GOJEK. What we also have is a supportive and collaborative atmosphere that helps you tackle those problems, regardless of which stage of your career you are in. If this sounds interesting, well, like the writer said, check out gojek.jobs, and let’s build great things, together 🙌