Journey from Frontend to Backend and Cloud Engineer: A Career Story

Journey from Frontend to Backend and Cloud Engineer: A Career Story

M. Zakyuddin Munziri

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

More Articles

I Stopped Digging Through Logs

I Stopped Digging Through Logs

Debugging changed when I stopped reading logs manually and started using AI agents to correlate errors across observability data - faster root cause, fewer dead ends.

Speed Was Never the Hard Part in CI CD

Speed Was Never the Hard Part in CI CD

Fast pipelines don't eliminate shipping fear. Confidence comes from safe rollbacks, feature flags, and systems that behave predictably when things go wrong.