Two Years And A Thousand Learnings Later

By Nishanth Shetty

It’s been a little over two years since I joined Gojek and the journey has been nothing short of a dreamy experience — working along with talented individuals and experimenting with various ideas, I got a chance to try my hand at building new systems and features.

In this blog, you shall see my journey as a developer in Gojek.

The recruitment

The first I heard about the company was when the recruiter got in touch with me. I was impressed by the way they went through my profile with me. It’s one thing to be have done your research about the company. It’s an even better feeling when the org that wants to hire you does the same for you. I decided to take the job and I have been very happy with my decision ever since.

After my interaction with the recruiter, my thoughts were that if the recruiter was so involved with knowing about the tech before reaching out to candidates to make a good impression, then there must be something special about the company’s culture. I might not have been surprised if they spoke about Java, Python or any other widely used programming language. What jolted me was the comfort with which they spoke about Rust and the project I worked on using Rust.

I feel that an interview a two way process. Yes, an interview is a process where the company will assess you for your knowledge and see if you are fit for the role. But, it’s also a chance for a potential employee to know what kind of colleagues or culture they’re going to see in the team. I shot all questions I had in mind about the org, and was impressed with the answers I got. Everything went smoothly and I had an offer in my hand. I was officially a GoTroop. 🖖

Working at Gojek

Initially I joined a new team which was still being formed, where the team’s vision was undecided, but goals were clearly defined. My teammates had a mix of experience and we worked on building some tracing and logging systems.

After a few weeks of working here, I was asked to work with another team where only two people were working on a project and they were lacking bandwidth for the new requirements. The tech in the company was still evolving, and the team was fairly new. They just had the initial version of the system deployed and serving.

Those two folks were fully on maintenance mode for the existing system and couldn’t accept any more new requirements. A few other senior folks and I came to the rescue. We immediately started working on new requirements, revamping existing systems and building new features. It was a really fun beginning.

I have been working with the same team ever since — a two people team that has now grown out to be a big team of 16+ engineers with great impact.

The growth of the team, system and process is really astonishing. Now that I sit and write this, thinking about the things my team has achieved really surprises me. We have experimented with different ways of running sprint, testing, deployment, automation and stand-ups.

From manually deploying services in VM’s to having weekly deployment, automated CI pipelines, test, and kubernetes solutions with our own cluster managed by the team itself.

Currently we are running a two week sprint, a standup everyday where we each keep a personal ledger of tasks where we update the previous day’s activities date, we talk about what our tasks for the day will be, discuss on any blockers and clarifications and make announcements. Can’t leave out Jira when talking about sprint and tasks, right? So I’ll say it — I don’t like it as of now. 😂

I work out of Bangalore office and the team is in Singapore. We don’t just work, it’s also about having fun virtually from our homes and finding the right balance.

What did I learn?

TL;DR: I learnt many things, but importantly to test the damn thing well.

Building a system at such a scale is easy if you know how to do it right, but that’s the beauty of our industry: We don’t know how to do it right. 🤷‍♂️

We follow certain processes with certain expectations, we iterate them until we get something stable working for that moment until the next unforeseen thing comes up.

Question we ask is:

How do you know what is right or what you have done is right? You test it. Period.

Gojek follows test driven development; the entire org depends on it. Each code the developer writes has to be unit tested, then functional, integration, and a whole other bunch of testing processes. That’s not enough, there is a QA doing extensive testing on the feature you are developing. There are automated test suites running in the CI looking for issues.

With all these things, the guy who hated the test 4 years ago, now loves it. I started my career where building projects would have `-DskipTests` flag set , you just get things done without testing, if it runs, great. Ship it. I have a project which was built without proper testing and it’s been a nightmare for me to refactor, improve, or address issues. Procrastinating over it as of now for 3 years.

I started writing tests after I joined Gojek, which changed the way I was writing programs. As a developer we (I?) tend to write complex stuff, shove all the things we think need, make it complex, thinking that hard-to-understand programs would make one a great programmer.

I thought that’s good programmer skills — writing programs in complicated ways. Well, I was wrong.

Writing simple, readable, testable code is what good programmer skills are.

Unit testing each code you write enables you to do the same thing, your thinking changes, you will end up deleting codes that aren’t important because while testing you realise you don’t need to support that at all or you are too lazy to cover the case in a test which nobody will use (YAGNI). You will start writing simple, concise functions which do one job and do it well. Forces you to refactor. All in all, you would have a well tested unit.

This reduces the risk of issues going to production and blowing it up or launching nuclear warheads. (may be still possible, but reduces the risk significantly).

I used to say that or believed that “if the system doesn’t have enough issues and you haven’t debugged it, then you don’t understand the system at all”, because this is how I have learnt many systems in previous organisation, but that changed here.

Writing tests eliminates future risk/bugs, but it also helps to find the existing one too. You don’t have to sit and step through each line of code to see where shit hit the fan or start writing printfs.

Now you may ask, what guarantee is that you have written your test right? What guarantee is that your test case is actually covering edge cases?

That’s why we have reviewers or a pair, every change to the system is reviewed by the peer, one who has an understanding of the system and the feature you are developing. He is also responsible as you are for the development and deployment of the feature.

Another part of the development process in Gojek is that it also advocates for pair programming. Two developers work/write codes, help bounce ideas around and reduce bus factor. Though the current situation of WFH made it a bit hard for us to follow it, that’s something which I have done in the beginning.

There are lot more source of learning in Gojek, not just on the work you do. We have dedicated channels where people share their findings, RCA session where teams go about the issue they face, fixes, learnings with different teams.

So far I have talked about what I have learned while working at Gojek, but here’s…

What Gojek did for me

Well to begin with, it pays my bills and gives amazing perks, duh!

With all the work, I have ample time at hand, and I spend a lot of it on learning and building systems on my own. I have developed quite a few personal projects in my free time, and experimented with many tools, languages.

The whole team and company respects every individual’s time, they care for the employee.

The team and the leaders care about their teammates. Micromanagement is unheard of, instead they ask how they can help finish a task or get rid of blockers. The one-on-one meetings which team leads hold with teammates is really amazing, with fruitful discussion, sorting out issues, etc.

After working for years, I started to feel bored with what I was doing, and felt that it wasn’t enough. So, I started crafting my own projects, built systems, experimented with any tools. Trying to code more backfired and I started inching towards a burnout. I was looking for solutions.

Upon reaching out to both my current and previous team leads, I was advised well and they assured it’s not too uncommon and I needed to take time and try things not related to computer science.

So yep, when they say “Hard to get in, harder to leave”, I know it’s true. Seeing the progress on how a company has an impact on individuals in Southeast Asia really amazes me and makes me proud to be part of the company.

About the author

Nishanth Shetty is our Product Engineer who builds pricing systems at Gojek. You can find him on LinkedIn, here.

Read more stories from our vault, here.

We’re hiring. Always. 🖖
Click below to view open job positions.