Software Engineers Level-up At Ruangguru. Here’s how.
Hi, I’m Harits. I am a software engineer in Ruangguru, the largest education startup in Indonesia. One of our missions is to build a world-class engineering team because we want to serve all 52 million students in Indonesia.
That’s a big challenge.
So, we software engineers can’t be ordinary. It’s not just following directions and day-to-day coding. At Ruangguru, we level up. We create a number of initiatives that will help us tackle our problems effectively.
Here’s how.
Product Brainstorming
We take part in the initiation process of a product or feature. This is to tackle a common problem in the software development life cycle when the cycle timeline does not align with the products.
We collaborate with our product team, provide continuous feedback, and make sure the desired product can be delivered within the preferred timeline. We also discuss the flow, the business process, integration process with existing products, and other business-related factors from an engineering perspective.
Our main goal remains: we want to reduce the delivery time without risking product quality.
We also create a document using Quip. Such document has helped all stakeholders collaborate with ease, where anyone can access information on discussion results, product specification, etc.
Design First
We follow a Design-First principle in our development lifecycle because it allows us to build world-class quality software. First, we mingle with fellow software engineers. We talk, discuss, and reach an understanding regarding the whole context of the product we will deliver. Second, we brainstorm on high-level architecture design, database structures, endpoint contracts, algorithm, and other necessary topics. Following the Design-First principle also spare us the need to create documentation at the end of the life cycle.
Here’s where it becomes remarkable: all software engineers can contribute directly to the discussion.
Everyone’s opinions and suggestions are valuable in the process, and this increases the sense of belonging we have towards the software we’re coding.
Collaborative Coding
We found collaborative coding a challenge to high-quality coding, and this is how we’ve overcome it.
With the growth of our codebase, software engineers tend to lack a sense of belonging towards the services they don’t work on. That’s one of the problems we encounter because we use the Microservices architecture on all our product services. Ultimately, when a problem comes up in a service, we depend on the software engineer who worked on it. That makes the knowledge unscalable.
In hopes of tackling that problem, we implement Monorepo in our version control system. We create a single big repository that contains all of our source code instead of creating multiple repositories for each of those services. We also create a shared library to reuse the common library and it is usable across services e.g. Authentication Middleware, logging format, and error code dictionary.
We also use the Merge Request feature to review the code that would be merged into our master codebase. We maintain our unit tests on approximately 70 percent code coverage on average. This practice keeps our high-quality code even when our codebase gets bigger.
Deployment
With more than one hundred services deployed whenever the team pleases, we cannot leave deployment to our DevOps Engineers. There are manpower limits there. So, we create “Newton,” our internal service that handles service deployment-related issues e.g. deployment to the Kubernetes, versioning, environment, and scaling configuration.
We also created tools based on the Command Line Interface (CLI) called “rogu.” The goal is accessibility for all software engineers. Using “rogu,” we can deploy our services from our local environment. With such internal platform, we deploy the service to the environment we need, maintain the versioning, and scale the server of the services.
Monitoring
The production environment is like a battlefield. We don’t know what’s going to happen. Sometimes the database connection is broken, or the service crashes due to unexpected user input. Again, we cannot always depend on our DevOps Engineers to get the log or know what happens on the server.
That is why we use Papertrail, which helps us pool all our service logs in a centralized place. We use Prometheus to monitor all our service metrics, like CPU and Memory Usage. We use Grafana, which beautifully shows the data gathered in Prometheus. We also create alerts on Papertrail and Prometheus. They notify us of errors regarding server usage.
All these tools also help software engineers monitor the services hassle-free.
***
All in all, software engineers at Ruangguru are consistently challenged. From joining product initiation, prioritizing the Design-First principle, maintaining quality in collaborative coding, to creating internal tools for ease of deployment and monitoring.
So, as a software engineer at Ruangguru, we have opportunities to learn as a product manager, system analyst, DevOps engineer, and of course, become leveled up.
Ruangguru provides a great opportunity for people who love challenges and are eager to learn new things every day.
Sounds like you? Join us in our world-class, challenge-filled, high-growth and fun engineering team here: http://bit.ly/rgtechnology
