DEV Community

Cover image for Frontend To DevOPs: 5 Months In
Laura
Laura

Posted on • Originally published at lalidev.hashnode.dev

Frontend To DevOPs: 5 Months In

Table of Contents

  1. Introduction

  2. Summing Up the Journey

  3. Expectations vs. Reality

  4. The Tech Stack: What I Had to Learn

  5. Surprise! Some Frontend Skills Actually Helped

  6. Advice for Frontend Developers Considering the Switch

  7. What's Next for Me

Introduction

Some time ago I decided to switch from Frontend Development to DevOps engineering. I started sharing my experience through a series of blog posts so anyone else on the same journey doesn't feel alone, and anyone thinking about making the same move has the courage to do it.

Summing Up the Journey

A couple of years ago I was working for a startup. We were a small technical team and I started as a Frontend Developer, that was my main strength. But if you've worked for a startup, you know there's a point where you end up doing whatever it takes to ship fast, so I ended up learning a bit of backend, even Google Analytics (which I hated 😂), and working on the infrastructure with AWS. Luckily, I felt very interested in infrastructure and somehow felt this world was fascinating. I started attending some AWS Girls UG group meetups where I got the opportunity to meet cool people and attend talks about different topics, and started to have mentorship sessions with @Mariano González , a Senior DevOps engineer.

As I was getting more interested in the infrastructure side of things, I got AWS Cloud Practitioner Certified, and that gave me a broad understanding of AWS in general.

I did a couple of side projects related to DevOps (including a Terraform one), studied in a DevOps Bootcamp that Roxs launched, and I wrote a series of blog posts talking about that. And finally, I worked very hard on solving The Cloud Resume Challenge. My mentor, @Mariano González , found it and recommended I do it, so I did and I learned A LOT.

Finally, I applied for a Software Developer position at Streaver, an AI-driven solutions company based in Uruguay. They saw I'd done a couple of projects on infrastructure and invited me to do a DevOps challenge, which I did, and here I am, working as a DevOps engineer for 5 months already🎉. So I'm gonna share my experience.

Expectations vs. Reality

When I was preparing to transition into DevOps, I'll be honest, I didn’t have much experience in infrastructure, so it was hard to picture what a day as a DevOps engineer would actually look like. I watched a couple of "A day as a DevOps engineer" YouTube videos and asked my mentor @Mariano González , a Senior DevOps Engineer, questions about what the day-to-day looked like. While I got some kind of idea from all this research, it still wasn't much to go on. One thing I knew for sure though: I wouldn't get bored.

I had this mental image of what the role would be like. I thought I'd be spending most of my time writing infrastructure as code, automating deployments, and maybe dealing with the occasional production issue. It seemed like a natural progression from frontend development, just working on a different layer of the stack, right?

Well, not exactly.

What I Expected: I imagined DevOps would be mostly about building CI/CD pipelines and writing Terraform configurations. I thought once you set things up correctly, everything would just run smoothly. I also assumed that since I had some AWS experience from my startup days, I'd have a decent head start.

What Actually Happened: The scope turned out to be much broader than I anticipated. Yes, there's infrastructure as code and CI/CD pipelines, but there's also monitoring, security, cost optimization, incident response, documentation, and a lot of collaborative work with different teams.

The biggest surprise? How much time I spend on problem-solving and troubleshooting. Things break, often in unexpected ways, and you need to diagnose issues quickly, sometimes under pressure. Unlike frontend development where you can usually reproduce bugs locally, infrastructure issues can be elusive and involve multiple services interacting in complex ways.

Another reality check: the learning never stops. New tools, new best practices, new security vulnerabilities, the landscape evolves constantly.

But here's what actually surprised me: the impact of the work. As a DevOps you're helping the entire engineering team ship faster and with more confidence. That feeling is incredibly rewarding.

And was I right about not getting bored? Absolutely. Every day brings something different, and there's always a new challenge to tackle.

This new job involves a lot of thinking outside the box and finding creative solutions to complex problems. The impostor syndrome is real, especially when you're troubleshooting issues you've never encountered before, but pushing through those moments is part of the growth.

The Tech Stack: What I Had to Learn

Coming from a frontend background where I spent my days with JavaScript, React, and CSS, the DevOps tech stack felt like stepping into a completely different universe.

AWS CDK (Cloud Development Kit) was completely new territory for me. It’s a way to write infrastructure as code using actual programming languages. I had never worked with it before this job, and I must say, it's an amazing tool. Being able to define infrastructure using familiar programming concepts like classes, loops, and conditionals felt way more intuitive than I expected. It bridged the gap between my developer mindset and infrastructure work in a way that made the transition smoother.

Python My experience was mostly in JavaScript, so picking up Python was quite new to me. At first, the syntax differences threw me off, no curly braces, indentation actually matters. But honestly? Python and I became friends fast. It's clean, readable, and the ecosystem for DevOps tooling is incredible.

AWS (The Deep Dive) I had some AWS experience from my startup days, but this job took it to a whole different level. Cloud Practitioner certification gave me breadth, but actually working as a DevOps engineer is giving me real hands-on experience. I'm talking about IAM policies, ECS, RDS, CloudWatch, Security Groups, everything. Understanding how all these services interact has been a continuous learning process.

The learning curve is steep, but here's the thing: having a programming background actually helped more than I expected.

Surprise! Some Frontend Skills Actually Helped

When I made the switch to DevOps, I kind of assumed most of my frontend skills would become irrelevant. Turns out, I was wrong.

Troubleshooting and Problem-Solving: As a frontend developer, I spent countless hours debugging why a component wasn't rendering correctly, why an API call was failing, or why the layout broke on a specific browser. That investigative mindset, breaking down a problem, checking logs, isolating variables, testing, translates directly to infrastructure work.

When a deployment fails or a service goes down, the approach is similar: read the error messages carefully, check the logs, trace back through recent changes, and systematically eliminate possibilities until you find the root cause. The context is different, but the problem-solving process? Pretty much the same.

Working with Code Infrastructure as code is still code. Learning Python or writing CDK constructs felt less intimidating because I already understood functions, loops, conditionals, etc.

So while the tech stack was completely different, the core skills I'd developed as a developer, problem-solving, debugging, and thinking in code, turned out to be more transferable than I expected.

Advice for Frontend Developers Considering the Switch

If you're a frontend developer thinking about making the jump to DevOps, here's my advice:

Keep an Open Mind DevOps is going to challenge a lot of your assumptions about how software works. You'll encounter tools, concepts, and workflows that feel completely foreign at first. Stay curious and open to new ways of thinking. The solutions that work in infrastructure aren't always the same ones you'd use in frontend development, and that's okay.

Think Outside the Box Infrastructure problems rarely have a single "right" answer. You'll need to get comfortable with ambiguity and find creative solutions to complex challenges. Sometimes the best fix isn't the obvious one, and that's where the problem-solving gets interesting.

Embrace the "Always Learning" Mindset This field evolves constantly, there's always something to learn. Try to learn something new every day, even if it's small. The learning never stops, and that's actually part of what makes it exciting.

Don't Let Impostor Syndrome Take Over This is big. You're going to feel like you don't know what you're doing sometimes. You'll see senior engineers troubleshoot issues in minutes that would take you hours. You'll read documentation and feel lost. That's completely normal. Everyone starts somewhere, and feeling uncomfortable means you're growing. The impostor syndrome is real, but don't let it convince you that you don't belong.

Some Days Won't Be Good And That's Okay You'll have days where nothing clicks, where you spend hours on a problem and make zero progress, where you feel like you're moving backwards instead of forwards. That's part of the process of learning something new. Those frustrating days are teaching you something, even if it doesn't feel like it in the moment.

Get Comfortable Being Uncomfortable Here's the truth: you're going to be out of your comfort zone. A lot. And that's exactly where you need to be. Growth happens in discomfort. The goal isn't to eliminate that feeling but to get comfortable with it, to recognize that being challenged and uncertain means you're learning and evolving.

What's Next for Me

The journey doesn't stop here. If anything, these first 5 months have shown me just how much there is to learn and explore in this field.

As I get more comfortable with the context and knowledge, I'll continue doing what I've been doing: learning every day, staying curious, and pushing myself outside my comfort zone. There are so many areas I want to dive deeper into, container security, AWS architectures, and more.

I'll keep sharing my experiences through these blog posts because if my journey can help even one person feel less alone in their transition or give someone the push they need to make the switch, then it's worth it.

The adventure continues, and I'm excited to see where it takes me next.

Top comments (0)