Where I started
When I began my career in cloud and DevOps, I had no clear roadmap. I read documentation, watched tutorials, took courses. I understood the concepts — in theory. But every time I sat down to actually build something, I hit a wall. The gap between knowing what Kubernetes does and knowing how to debug a pod that won't schedule is enormous. And no amount of theory closes it.
What finally moved the needle was building real things and breaking them. Not in a sandbox with a perfectly scoped tutorial, but in environments where the failure had consequences — where I had to figure out why the Jenkins pipeline was failing at 11pm, why Terraform was destroying resources I didn't expect, why the EKS cluster was running out of nodes under load.
Why hands-on always beats theory
DevOps is fundamentally operational. The knowledge that matters most — how systems fail, what the errors actually mean, how to recover quickly — only comes from operating systems. You can read the Kubernetes documentation from start to finish and still be completely unprepared for your first CrashLoopBackOff at 2am.
Theory gives you vocabulary. Hands-on gives you intuition. You need both, but the order matters. Learn enough theory to have context, then build something real. When it breaks — and it will — go back to the documentation with a specific question. That's when the documentation actually sticks.
The tools that changed how I think
Jenkins — understanding pipeline complexity
Building Jenkins pipelines from scratch taught me more about CI/CD than any course. Not the happy path — the failures. A shared library that worked in one pipeline and silently failed in another. A Groovy syntax error that only surfaced at runtime. Workspace collisions between concurrent builds. These are the things you only learn by running pipelines in anger.
Kubernetes — operational thinking
Kubernetes forced me to think about systems differently. It's not just about deploying containers — it's about designing for failure. What happens when a node dies? What happens when a pod can't pull its image? What happens when resource requests are wrong and the scheduler can't find a home for your workload? Running EKS in production answers all of these questions very quickly.
Terraform — infrastructure as a discipline
Terraform taught me that infrastructure decisions are long-lived in ways that code decisions aren't. A bad module structure that you can refactor in a day of coding might take weeks to safely refactor in Terraform without risking state corruption. Every infrastructure decision carries more weight when you understand that changing it later has real operational cost.
How to build the right things
The mistake I see most often from engineers learning DevOps: building toy projects. A "CI/CD pipeline for a hello world app" teaches you syntax. It doesn't teach you the operational reality of managing a pipeline for a system that 20 engineers are committing to simultaneously.
Build things that are close to production reality:
- Set up a multi-environment Terraform configuration — dev, staging, prod — and practice promoting changes safely between them
- Run a Kubernetes cluster and deliberately kill nodes, drain pods, simulate OOM conditions — then recover from each
- Build a monitoring stack and configure alerts for conditions you'd actually care about in production
- Automate something you currently do manually — the more annoying, the better
The questions worth asking
The most valuable learning tool I've found isn't documentation or courses — it's asking the right question when something breaks. Not "why isn't this working" but "what is this system actually doing right now, and why is that different from what I expect?"
That reframe — from frustration to curiosity — is what separates engineers who grow quickly from those who stay stuck. Every failure is a system telling you something true about how it works. The job is to listen.
What I focus on now
After 8 years in IT and 6+ years in DevOps and cloud, the areas I'm still deliberately investing time in are the fundamentals that don't change: how networks actually work, how storage systems behave under load, how operating systems manage resources. The tools change. AWS releases new services every month. Kubernetes adds features every release. But the underlying systems knowledge that lets you reason about why something is slow or broken — that compounds.
If you're starting out: don't chase every new tool. Get deep on one thing — Kubernetes, Terraform, a specific cloud provider — until you really understand it. Then the next thing is easier, because the patterns transfer.
What's the most challenging aspect of DevOps you've faced? The problems worth talking about aren't the ones with clean solutions — they're the ones that changed how you think.