A few weeks ago I agreed to explain Docker basics to a friend who is moving from support into a DevOps career. I thought it would take an hour. It took three sessions and left me with a list of things I had been faking for years. Teaching while your own confusion is still recent, or in my case freshly rediscovered, is one of the best career moves I know, and it quietly builds your reputation too. Here are nine lessons from that experience, in the order they hit me.
1. “It works on my machine” is a teaching topic, not a joke
My friend asked why anyone needs containers at all. I gave my usual quick answer and she asked a follow-up that stumped me: “but what exactly is different on the other machine?” I had never listed the differences out loud. Doing so, library versions, system settings, missing tools, made the whole point of packaging an app with its surroundings click properly for me as well.
2. Image and container are not the same word
I used the two interchangeably for years, and she noticed in the first ten minutes. An image is the recipe-plus-ingredients, frozen; a container is one running instance cooked from it. Once I said it that way, three muddles of my own cleared up at once.
3. You do not understand layers until you draw them
I could say “images are built in layers”. I could not sketch what happens when two images share the bottom layers. Drawing a stack of boxes on paper and crossing out the ones that get reused showed me why builds are quick the second time and why the order of instructions in a file matters. If you want to see the practical side of this, a piece on looking after container images properly in an engineering team goes deeper once the basic picture is in place.
4. Comparing containers with virtual machines is harder than it sounds
The standard comparison is “lighter than a virtual machine”. When I tried to say why, I realised I only half knew. Containers share the host’s kernel; virtual machines carry their own. That one sentence did more than my previous five. For a longer treatment aimed at learners, there is a friendly explanation of how containers differ from full virtual machines, and I wish I had reread it before the session rather than after.
5. Beginners ask better questions than interviewers
Interviewers want the right answer. Beginners want to know why. “Why does the container stop when the command ends?” is a genuinely deep question about what a container is for, and answering it properly taught me more than a certificate preparation week had.
6. Your mistakes are your best material
The most useful part of each session was the moment I said, “I got this wrong the first time, and here is how.” My friend relaxed visibly. Sharing the wrong turns gives learners permission to take them too, and it makes your explanation memorable. The same instinct is behind advice on the typical slip-ups newcomers make with containers: naming mistakes honestly is half of avoiding them.
7. A tiny example beats a realistic one
I started with a sample application that had a database, a cache and a queue. She was lost in four minutes. When I switched to a single static page served from a container, everything became clear. Realistic examples can come later. Tiny ones teach the idea.
8. Writing it down turns a chat into an asset
After the third session I turned my notes into a short post, partly for her and partly for me. This is the career angle people overlook: a collection of honest, clear explanations is personal branding that does not feel like branding. When a recruiter or a hiring manager reads how you taught a beginner, they learn how you think and how you treat people who know less than you. That is hard to fake in a one-page CV.
9. Publish it somewhere you own
I put mine on MyBlogPad, a blogging network that hands every blog its own subdomain and lets you sign in with Google. It also supports several contributors per blog, so a study pair could write together, and it says it costs nothing to start. Because the blog is yours rather than a company wiki’s, it stays with you when you change jobs.
A few practical tips if you want to try this
- Pick one person to teach, even a single friend. A real face keeps you honest.
- Time-box each session to forty minutes so nobody drowns.
- Write the gap list during the session, not after. You will forget half of it otherwise.
- Keep client or employer details out of anything you publish.
- Revisit the post after a month and correct what you now know was wrong.
The bigger picture
I used to think that building a career in DevOps meant collecting tools and badges. Teaching Docker basics showed me that visible understanding counts at least as much. Colleagues keep recommending the person who once untangled their confusion in plain words. Expertise is not the entry ticket here; all you need is one topic you recently learned, one listener and about an hour.
So here is my suggestion for this week: choose something you only just got your head around, say the thing you were most confused about, and explain it to somebody. Then write down what you found out. You will be surprised how much of your own understanding was resting on assumptions you had never checked.
