Here is a small experiment you can run tonight. Take something you picked up this week in DevOps, say how a Git branch differs from a copy of a folder, and explain it out loud to a friend who has never written code. Do not use the words “repository”, “commit” or “merge” unless you can say what they mean in everyday language. If you start to sweat, congratulations: you have just found the exact spot where your understanding is thinner than you thought. This explainer unpacks why that happens and how to use it.
Knowing a word versus knowing a thing
When you first meet a technical term, your brain files it under “seen before”. The next time it appears, you feel a flicker of recognition, and recognition feels remarkably like understanding. But recognition only tells you the word is familiar. Understanding means you can predict what the thing will do, say why it exists and describe it without borrowing its own jargon.
Plain language is the cleanest test of the difference. If you can explain a concept using only words your neighbour already knows, you own it. If you can only explain it by chaining other technical words together, you are passing the label along without having opened the box.
Why a beginner is the best examiner
An expert listener will nod politely and fill gaps in your explanation from their own knowledge. A beginner cannot do that. They will ask innocent questions such as “but why does it need two copies?” or “what happens if I do not do that step?” Those questions land on the weak spots because beginners ask what the experts stopped wondering about long ago.
That is why this teaching trick works best when the confusion is fresh. A few days after you learn something, you have a clear memory of what felt odd. A few months later, you have forgotten, and your explanation drifts toward the confident, compressed style that bewilders newcomers.
A worked example in plain words
Suppose you just learned what a deployment pipeline does. A first attempt might be: “It automates build, test and release.” That is accurate and almost useless to a beginner. A second attempt, after a few honest questions, might go like this: “Imagine a bakery where every loaf passes the same three checkpoints before it leaves the shop. First someone checks the ingredients, then someone bakes and tastes a slice, then someone boxes it for delivery. A pipeline is that line of checkpoints for software, so the same quality checks happen every time and nobody forgets one on a busy day.”
Notice what happened between attempt one and attempt two. You had to decide what mattered most (the repeated checks) and what could wait (the tool names). You also had to be sure of the order of the steps, which turned out to be fuzzy in your own head. The explanation improved because your understanding did.
Three habits that make plain explanations easier
- Start with the problem. People remember why something exists far better than how it works. Begin with the mess that existed before the idea, then show the idea as the fix.
- Use one picture, not five. A single everyday comparison, such as post offices, kitchens or traffic lights, beats a cloud of analogies that each break in a different place. Say where the picture stops working, too.
- Say what it is not. Half of confusion comes from mixing neighbouring ideas. A sentence like “this is not a backup, it only keeps history of changes” saves a reader from a classic mistake.
What to do with the gaps you find
Gaps are the prize, not the problem. Write each one on a separate line, then close the gap with a small experiment rather than only more reading. If you could not explain why two people editing the same file causes trouble, create two branches, change the same line in both and merge them. Watching the conflict message appear teaches more than a paragraph about it ever could. Afterwards, rewrite your explanation including what you saw.
If your longer goal is moving into DevOps from another IT role, this habit is especially handy. Many people making that move, as described in a guide to crossing over from support and system administration roles into DevOps, already have deep practical knowledge, but find it hard to put it in words a new team understands. Explaining things plainly is the bridge. Earlier on the ladder, the stages from junior engineer to senior practitioner look much less intimidating once you see that every stage includes teaching the one before it.
Where to put the finished explanation
Do not let a good explanation die in a chat thread. Give it a title, tidy it up and publish it. MyBlogPad hosts blogs on personal subdomains of its network; sign-in runs through Google, a blog can have several writers, and the site calls itself free to try. A public home for your plain-language notes means the next beginner can find them, and you can find them again too.
Common stumbling blocks
- Giving the textbook definition and stopping. Follow it with an example.
- Hiding behind acronyms. Spell them out once, then explain the idea.
- Explaining everything you know. Pick the one idea the listener needs today.
- Skipping the practice. If you have never done the thing, say so; honesty is better than confidence you have not earned.
Try it tonight
Choose one thing you learned this week. Find a patient friend, relative or even a pet. Explain it with no jargon for three minutes. Write down every question you could not answer. That list is your study plan for tomorrow, and the cleaned-up explanation is your first post. It takes about half an hour, and you will understand the topic better at the end of it than you did at the beginning.