Leveling Up The Software Engineer
As the largest education startup in Indonesia, Ruangguru has a mission to build a world-class engineering team that would serve approximately 52 million students in Indonesia. With that challenge, we, as a Software Engineer in Ruangguru, cannot be ordinary with their day-to-day job is just coding based on their users request without any “special responsibility”. There are some initiatives that we approach in Ruangguru to level up the responsibility of our Software Engineers.
Product Brainstorm
The common problems in the software development lifecycle are the timeline that does not make sense with the scope of the product. To tackle that problem, we take part in the product or feature initiation that would be delivered. Together with our product team, we give continuous feedback to make sure the product can be delivered based on the preferred timeline. We also give our suggestion regarding the flow, business process, integration with the current product, and other business-related things from our perspective, to reduce the delivery time but still ensure the product quality. To make the product specification and the discussion result accessible, we use Quip to create a document that makes all of the stakeholders can collaborate with ease.
Design First
To build a world-class software quality, we always put the design-first principle to our software development lifecycle. We start to mingle with our peers to get the whole context of the product that we would deliver. After that, we brainstorm the high-level architecture design, database structures, endpoint contracts, algorithm, and other things that necessary for the product. All of the Software Engineers can contribute directly, give some advice and opinion, instead of a System Analyst or Technical Lead that in charge of the software architecture design. From that initiative, it increases our sense of belonging to the software that we code. Another benefit from the Design-First principle is we will not need to create the documentation at the end of the lifecycle.
Coding Time
Of course, there is no Software Engineer without coding. But the real challenge is how we do coding with the easy collaboration with each other, keep our code quality high, and of course, makes the software engineers stay happy.
In Ruangguru, we implement the microservice architecture to all of our product services. One of the problems that we encounter as our codebase grows is the lack of sense of belonging to the software engineers to the service that they do not work on it. At the end, when the problem come up in a service, we depend on the software engineer that works on it and makes the knowledge unscalable.
To tackle that problem we implement Monorepo in our version control system. So instead of creating multiple repositories for each of those services, we create a single big repository that contains all of our source code. We also create a shared library to reuse the common library to will use across the services e.g. Authentication Middleware, logging format, and error code dictionary.
We use the Merge Request feature to review the code that would be merged into our master codebase. We also maintain our unit tests on approximately 70% code coverage on average. This practice would keep our code quality high, although our codebase is getting bigger.
Deployment
With more than a hundred services that need to be deployed whenever the teams want, we cannot leave the deployment thing to our DevOps Engineers due to the limitation of the people. So, we create “Newton”, our internal service that handles service deployment-related things e.g. deployment to the Kubernetes, versioning, environment, and scaling configuration. To make it accessible to all of the Software Engineers, we create CLI (Command Line Interface) based tools called “rogu”. Using “rogu”, we can deploy our services, right from our local environment. With that internal platform, we can deploy the service to the environment what we need, maintain the versioning, and also the server scaling of the services.
Monitoring
The production environment is like a battlefield. We will not know what would happen there. Sometimes the database connection is broken or the service crash due to unexpected user input. Again, we cannot always depend on our DevOps Engineers to get the log, or to know what happens on the server. Because of that, we use Papertrail to pool all of our services log in a centralized place, use Prometheus to monitor all of our services metrics like CPU and Memory Usage, and use Grafana to show the data that gathered in Prometheus beautifully. We also create some alerting on Papertrail and Prometheus, to notify us if some error happened or something odd happened regarding the server usage. With all of the tooling that we used, the Software Engineers would also responsible to monitor their service without the hassle.
Takeaways
The Software Engineers at Ruangguru are encouraged to join the product initiation talks from the earliest time and give a suggestion from their perspective to make the product requirements aligned with the preferred timeline. We always put the design-first principle to our software development lifecycle to make our software architecture designing skill better. While coding, we try to make easy collaboration, with keep our code quality high using code review, and of course to make the Software Engineer happy. We create our internal tools to make the deployment and the monitoring easily.
As a Software Engineer at Ruangguru, we will have the opportunities to learn as a Product Manager, System Analyst, DevOps Engineer, and of course, become the Leveled Up Software Engineer. It is a great opportunity for the people that love challenges and eager to learn new things every day. Sounds very like you? Apply now via https://career.ruangguru.com/technology
