
Journey from Frontend to Backend and Cloud Engineer: A Career Story
M. Zakyuddin Munziri
@zakiego
Originally written in Bahasa Indonesia.
Note
This article is a personal reflection on my career journey, containing experiences and lessons learned, without in-depth technical discussion.
Starting Point
It has become common for most beginner programmers to start their journey as a Frontend Engineer.
This is because building the front-facing part of a web application is the most visible work, and its benefits are quickly felt. As beginners, we naturally want to harvest what we plant as soon as possible.
From personal experience, my journey started with learning HTML and CSS, then progressed to JavaScript, jumped to Next.js, and only then stepped back to learn React (a more detailed story can be read here: Kilas Balik 2021)
Starting to Cook in the Back
Honestly, I'm not a pure Frontend Engineer. From the beginning, I leaned more towards being a Full-Stack Engineer. This is because when building frontend using Next.js, I eventually became familiar with the API concept, which is one of Next.js's features. However, since Next.js isn't specifically a backend framework, I felt less confident claiming to be a Backend Engineer.
Time passed, and at my current workplace, I was very fortunate to have ample room to learn and grow.
There came a time when I was assigned to join a sub-team to migrate a backend service from Express.js to Nest.js.
Regarding Express.js, I wasn't completely clueless—I had used it before, but not deeply. But what about Nest.js? I had never used this framework at all. Like it or not, before working on the core task, I had to first learn Nest.js.
During the first week, my head felt like it was throbbing every night. This is an opinionated framework—like having its own world, different from other frameworks. It wasn't easy to understand.
Provider, inject, guard, DTO—what do these terms and concepts mean?
Despite feeling very uncomfortable, confused, and struggling to understand, I kept pushing myself to learn. Because of a belief that it's all just a matter of whether you want to learn or not. I kept forcing myself to read documentation, read code, going back and forth until I gradually understood.
A week passed, I started getting used to the class-based writing style (honestly, I had never written classes in JavaScript before—everything was functional-based). Since I was starting to understand Nest.js, little by little, work on this migration began. Until finally it was done, and that PR was successfully merged into the main branch.
Playing in the Cloud
Even though no one ever asked me to, I once learned GitHub Actions just out of curiosity. From there, I always tried to implement CI/CD as best as possible, even if it was just for personal projects.
This past idle time exploration bore sweet fruit. Coincidentally, when I first joined my current team, it was a completely newly formed team. So we started from zero. There were no established rules for how the coding process would work.
Everything was determined by the first generation.
Because of this void, I started taking the initiative to implement CI/CD. From initially just doing the build process, I was then tasked with deploying to the cloud.
There was another stroke of luck—I had also learned Docker before, even though no one asked me to. All just out of curiosity. The ability to use Docker is important for deploying applications to servers.
Honestly, I didn't have deep experience managing production apps in the cloud, like AWS, Google Cloud Platform, or Digital Ocean. However, with the foundation of CI/CD setup and Docker knowledge, it was just a little more—I only needed to learn about the cloud provider being used. Gradually, I became familiar with the cloud world.
It's almost unbelievable—in just about three months, I who had never touched paid cloud services, now understood GCP products like Compute Engine, Cloud Storage, Cloud Run, and others quite well—although still at a basic level.
The Conclusion
Reflecting on the story that has passed and looking at the present, I'm now more often given responsibility to manage backend and cloud. Although occasionally I'm also assigned to help with frontend.
With the ability to handle work end-to-end, the types of tasks I can work on have become more diverse. The lead can entrust any task considered important and crucial.
If there's time, maybe I'll tell the story of how my current tasks more often involve fixing errors that have no documentation.
Takeaways
- Having a supportive lead and ecosystem is a very valuable privilege. Being given permission and trust to handle new tasks—even without prior experience—is a very precious opportunity.
- Broadening your skill horizons in the early stages of your career is very important, from frontend, backend, mobile, cloud, devops, data, ui/ux, etc. With this breadth of skills, it increases the possibility of getting a job.
- It's very good to be a generalist in the early learning stages, then deepen one field and become a specialist while working.
- Consistent learning and exploration outside of work demands can open unexpected opportunities in the future.
Finished writing on October 18, 2024, 00:13, Banjarmasin
Finished refining on January 5, 2025, 02:26, Pelaihari


