I’ve been a web developer for more than three years. I can build features, fix bugs, and ship code. But somewhere along the way, I realized: writing code is only a part of the job.
Here’s why I decided to stop guessing and start learning DevOps.
The tipping point
It wasn’t about complex algorithms or bad legacy code. It was inconsistency.
In large projects, multiple developers contribute at the same time. But without strong ownership or review practices, things got messy fast:
- Different developers installed or updated packages without coordination.
- Some team members didn’t pull the latest code before starting work.
- Merge conflicts became a daily ritual, not an exception.
And then came the cross‑platform hell. I work on Windows. Others use Linux or macOS. Our production server runs Linux. The result?
- Environment‑specific bugs.
- Configuration mismatches.
- File path and permission issues.
- Features that worked beautifully on my machine but broke on another OS.
I realized my shallow understanding of the Linux file system (especially while developing on Windows) was a root cause. I was running commands from Google and AI, hoping they’d work. Sometimes they did. Sometimes they didn’t. That’s not engineering — that’s gambling.
The wake-up call
That moment came when I joined a corporate environment with no dedicated DevOps team.
Suddenly, I wasn’t just writing code. I was doing everything:
- Fullstack development
- Merging and committing
- Deploying to the server
- Debugging production issues at 2 AM
But my Linux knowledge was shallow. I was operating blindly on live servers. There were tasks I actively avoided because I was afraid I’d crash the whole thing.
One recurring nightmare: instability. We had multiple domains and apps on the same server. An app would work fine in the afternoon, and by next morning it was down. I’d manually restart processes (Docker, PM2) like a firefighter with no gear.
Deployment was another time‑sink. Every build meant SSH‑ing into the Linux server manually. Five or six times a day. Across multiple apps. It was frustrating, repetitive, and wasteful.
That’s when I understood: deployment automation isn’t optional — it’s survival.
The visibility gap that scared me
Take performance issues. We ran a self‑hosted Strapi CMS with multiple users. The server would become slow or unresponsive. But I had zero visibility into:
- Which process was eating CPU or RAM
- When spikes happened
- Which app was the culprit
I was reacting to problems, not controlling the system. Without monitoring, logging, or process management, I was flying blind.
What a “good day” looks like to me now
I don’t want excitement. I want boring.
A good day, once I truly know DevOps, is:
- Morning coffee + checking a dashboard instead of digging through logs on a broken server.
- Seeing CPU, memory, and traffic at a glance.
- Getting an alert before users notice something wrong.
From the dev side: git push → everything automated. CI/CD runs tests, builds, deploys. No more manual SSH marathons. Docker ensures my app runs the same on my laptop, my coworker’s Mac, and the production server.
Deployments become predictable and safe. If something breaks, I roll back instantly — no panic.
And scaling? Auto‑scaling handles traffic spikes. More users → more instances. Less traffic → fewer resources. I don’t guess capacity or pay for idle servers.
Most importantly: I’m not blind anymore. Logs, metrics, observability tools tell me the root cause. No more running random commands and praying.
Also, AI is changing the game. Anyone can now “vibe‑code” an app with ChatGPT. But those apps are rarely production‑ready. Without DevOps knowledge, deploying them is risky. Learning to secure, deploy, and monitor properly is becoming a must‑have, not a nice‑to‑have.
As I move toward senior roles, people will expect me to think beyond code. They’ll expect me to understand system behaviour under load, safe deployment strategies, and operational risk.
If I avoid DevOps, I’ll stay comfortable for a while — but the industry will move forward without me.
So here I am
I’m not learning DevOps just to add Docker and Kubernetes to my resume.
I’m learning it to become the engineer who can take a product from development to production — confidently, safely, and without panic.
This blog series is me learning in public. Every day, I’ll pick one topic, practice it, and write about it.
Top comments (0)