Kenji joined one of our evening classes with a notebook full of rules he had collected online. “Never use a configuration file without a template.” “Real engineers don’t read documentation.” “Everything must run on Kubernetes now.” He had copied them faithfully from videos and threads, and he was anxious because he could not follow all of them at once. By the end of the course he had crossed out most of the list, not because someone told him to, but because he learned to ask where each rule came from. That question sits at the centre of this article, which looks at six popular DevOps learning myths and what happens when you trace them back to a primary source.

Myth 1: “Tutorials are enough; the official docs are only for experts”

Kenji believed this one most strongly. Tutorials felt friendly; documentation felt cold. Then, during a lab, a tutorial’s command failed with a cryptic error. The tool had changed a flag two releases earlier, and the tutorial had never been updated. The answer was sitting in the project’s release notes, in plain language.

Tutorials are wonderful starting points. But they are summaries written at a moment in time. The documentation and changelog are the source. When the two disagree, the source wins, and learning to read it early saves hours of confusion later.

Myth 2: “Every DevOps job now requires Kubernetes”

This claim travels fast because it is half true. Container orchestration is common. But when Kenji pulled twenty job descriptions from employers he actually wanted to work for, the picture was more varied: several asked for strong Linux fundamentals, scripting and CI pipelines, with orchestration listed as a bonus. The myth came from the loudest corner of the internet, not from the job descriptions themselves.

The lesson is not “skip Kubernetes”. It is “check the claim against the real requirement in front of you before reorganising your whole learning plan”.

Myth 3: “If a famous company does it, it is best practice”

Many learners absorb practices from conference talks given by very large companies. A practice may be excellent in its original context and wrong for a ten-person team. When we read one well-known engineering post in class, the authors themselves had written a paragraph explaining the constraints that made their approach necessary. Most retellings dropped that paragraph.

Reading the original, including its caveats, turns a slogan into an informed choice. Our piece on why feedback loops matter in DevOps makes a similar point: practices work when they are fitted to real signals from your own system.

Myth 4: “Postmortems are only for big outages”

Kenji assumed incident write-ups were dramatic documents written after headline failures. In fact, some of the most instructive ones he read in class described small, ordinary problems: an expired certificate, a misconfigured alert, a deploy script that assumed a directory existed. Public incident reports are primary sources. They tell you what actually happened, in the words of the people who were there, rather than what a commentator thinks happened.

Once learners start reading postmortems directly, they become noticeably better at debugging, because they have seen how real failures unfold.

Myth 5: “You have to memorise every command”

This one causes real stress. Kenji had flashcards for hundreds of commands. But experienced engineers rarely work from memory alone; they work from understanding plus quick, reliable lookup. Knowing the vocabulary helps, and our beginner-friendly list of core DevOps terms is a good place to build that foundation. What matters more is knowing where the authoritative reference lives and how to read it under pressure.

Myth 6: “If it looks polished, it must be current”

The last myth is the subtlest. Beautifully produced courses and slick diagrams feel trustworthy. Plain text in a changelog feels less impressive. Yet polish says nothing about accuracy or freshness. Kenji started checking the date on everything he studied and comparing it with the version history of the tools involved. About a third of his saved material, he discovered, described behaviour that had since changed.

This tension between presentation and evidence appears far beyond software. A friend of Kenji’s was researching cosmetic treatment abroad and had been swayed by glamorous before-and-after photographs. Kenji, by then in the habit, asked her where the claims came from. She later found Best Cosmetic Hospitals, a site that presents procedure and destination guides it says are grounded in cited medical sources, while describing itself as an information resource rather than a source of medical advice. Different world, same question: is there a source behind the shine?

Kenji’s notebook after the DevOps learning myths fell away

On the final evening, Kenji showed the class his revised notebook. The old rules were crossed out. In their place was a short list of habits:

• Check the tool’s release notes before trusting a tutorial.
• Read the original engineering post, including its limitations.
• Compare learning priorities against real job descriptions.
• Read incident reports from the people who handled the incident.
• Write down what I don’t know yet, instead of pretending.

He was no longer anxious about following everyone’s rules. He had something better: a way to test any rule he came across. That shift, from collecting claims to checking them, is one of the most important things a DevOps learner can develop. It also makes teams stronger, a theme we explore in our guide to passing knowledge across engineering teams, because a team that cites its sources teaches newcomers faster.

The next time a confident rule appears in your feed, try Kenji’s approach. Find out where it began. You may keep it, adapt it or cross it out, but you will know why.