Learning DevOps in Public: Why I'm Finally Doing This Too

I spent three years as a full-stack developer in Islamabad before I realized I was doing DevOps without a safety net. I'd deploy to production using SSH, manage databases through hastily written scripts, and pray that my server configuration would survive the next restart. When something broke at 2 AM, I'd be the one scrambling because nobody else on the team understood what I'd done.

That's when it hit me: I was actually doing DevOps work, but treating it like an afterthought. I had no documentation, no reproducibility, and absolutely zero confidence in my infrastructure decisions. Reading about someone deliberately learning DevOps in public made me realize something important—I needed to stop pretending this wasn't a critical skill and start treating it like the legitimate craft it actually is.

The Honest Gap in Full-Stack Development

Here's what nobody tells you: full-stack development without DevOps knowledge is like driving with one eye closed. You can do it, but you're genuinely dangerous to yourself and your team.

Most developers I know can spin up a Node.js or Django app locally. We know Git, we understand databases, we write decent code. But the moment we need to put something in production reliably, many of us freeze. We containerize haphazardly, we copy-paste docker commands we don't understand, and we deploy using whatever method seemed to work last time.

The original article's author is doing something that should be more common: acknowledging that DevOps is a distinct skill set that requires intentional learning. It's not something that magically happens when you get good enough at your primary language.

Why Learning This Matters for Your Career

I'll be direct: in 2024, DevOps literacy is not optional for developers who want actual career mobility. You don't need to become a SRE, but you absolutely need to understand containerization, basic infrastructure, and deployment pipelines.

Learning DevOps in public—documenting your journey as you go—is actually smart. I've started doing this in my own blog, and the difference is measurable. When you write down what you're learning, you retain it. When you force yourself to explain Docker concepts in English (or any language), you find the gaps in your understanding immediately.

The roadmap mentioned in the original article is solid: Linux fundamentals, containers, CI/CD, Kubernetes, and Infrastructure as Code. This is the actual progression that makes sense because each step builds on the previous one.

The Real Advantage of Public Learning

I was skeptical about this at first. Doesn't learning in public mean exposing your ignorance? Yes, exactly. And that's the point.

When I wrote my first post about Docker, someone corrected my understanding of image layers. I was slightly embarrassed, then incredibly grateful. Now I write better Dockerfiles. When I struggled with GitHub Actions workflows, commenting about it publicly led to conversations with other developers who had solved the same problems.

There's something psychologically powerful about commitment. If you write publicly about learning Kubernetes, you're more likely to actually learn Kubernetes. If you just read documentation privately, it's easier to give up when it gets hard.

Here's What I'd Add to This Journey

The roadmap is good, but I'd add two things based on my experience:

First: Learn the operations perspective. Don't just learn Docker syntax—understand why containers exist and what problems they solve. This context makes the tools click.

Second: Build something concrete immediately. Don't just follow tutorials about Terraform. Deploy an actual side project infrastructure and maintain it. Real-world problems teach you things no course ever will.

Here's a simple Docker setup I wish I'd understood years earlier:

# Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

This isn't just about syntax. It's about understanding that Alpine images are smaller, that we separate dependency installation from code copying for better caching, and that this matters in production when you're pulling images thousands of times.

The Uncomfortable Truth

DevOps knowledge separates developers who can deploy from developers who can deploy reliably. It's not glamorous, but it's valuable. If you're comfortable writing code but uncomfortable shipping it, you're limiting yourself.

Your Turn

Are you like me—someone who's been doing DevOps accidentally without claiming the knowledge? What's one DevOps skill that's been haunting you that you've kept putting off learning?

I'm planning to dive deeper into Kubernetes this quarter, and I'm documenting it here. If you're on a similar path, I'd genuinely like to hear about it.

Source: This post was inspired by "Why I'm Learning DevOps in Public" by Dev.to. Read the original article