Starting out in DevOps can feel overwhelming. The list of skills expected from a modern DevOps practitioner can seem daunting - Linux, networking, Docker, Kubernetes, AWS, Scripting etc. And the list keeps growing. It’s hard to tell what to learn first, and even harder to know if you’re doing it right.

This post lays out a simple framework to approach learning DevOps and the mistakes to avoid.

The Roots: Linux, Networking

Almost every tool you come across is built on top of Linux. For example, both Docker and Kubernetes are built on top of fundamental Linux concepts such as Namespaces and cgroups. Most tools assume familiarity with the Linux command line.

Everything is distributed over a network which means that when something breaks, you rely on your knowledge of networks to troubleshoot.

The importance of these concepts cannot be overstated, but this is also where most learners get stuck. They assume that an exhaustive mastery of Linux/Networking is required. This is both impractical and unnecessary

You simply need to know enough to move forward…

The Trunks and Branches: Core Tooling

These are the tools that you will use day-to-day on the job to achieve specific goals - Continuous Delivery, Continuous Deployment, Automation etc.

  • AWS Services

  • Docker

  • Kubernetes

  • Scripting - Bash, Python etc

This is where learners spend most of their time.

A typical strategy is to create a checklist of tools and learn them one by one.
This feels productive — but it’s a trap.

Each tool is vast and mastering them requires months (if not years). Also, there are so many alternatives to each tool that it is impossible to learn them all. For example, you can spend months learning AWS services but the next gig may require your to know GCP instead.

The trick is to stop obsessing over tools and start understanding what they actually deliver.

Learning the right way: Chase the fruits

The fruits are tangible outcomes achieved by combing conceptual knowledge and tools. This is where learners should focus.

For example, “containerizing a web server and have it serve pages on your browser' will involve learning:

  • Just enough Python or Go to write up your first ‘hello-world’ web server

  • Just enough Docker to build the image and run a container

  • A little bit of networking - ports and URLs.

  • How to debug when the page is not served.

On the job, this is exactly what you are paid to do - deliver outcomes.

The Leaves: Where Real Learning Happens

This is the part most learners ignore - Troubleshooting:

  • Why isn’t the container starting?

  • Why can’t I access the service?

  • How do I check startup logs?

These moments are frustrating. It feels like you are wasting time, but this is also where real learning happens. This is where you separate yourself from the herd:

  • You build an intuition about the tools and where they tend to break

  • develop tacit knowledge and familiarity with failure modes

  • start connecting concepts together and thinking of the system as a whole

This is tested on the job quite often. As a DevOps engineer, you are constantly paged by other teams when things are broken and it is important that you know how to fix them.

Conclusion:

So if you have a learning checklist, like most learners, I would advise you to abandon it and focus on the outcomes instead:

  • setting up version control for the server and associated code

  • creating automated test suites and linters to make changes safe

  • packaging and releasing versions with proper documentation and release notes

  • testing and debugging when things go wrong

  • deploying the server to a local Kubernetes stack

  • … and more

Let the outcomes drive the learning - not the other way around. This is what helps you grow into a well-rounded engineer.

Keep Reading