Anyone who works with a content management system has a stack of small discoveries each week: why a plugin update changed the layout, what a staging copy is really for, how a redirect rule behaves when two of them overlap. Most of those discoveries never leave the person’s head. Writing up what you learned about your CMS, in beginner language and while the confusion is still fresh, is one of the cheapest ways to deepen your own understanding. Yet six persistent myths keep developers and marketers from doing it. Here is each one, and what actually holds up.
Myth 1: You have to be an expert before you teach anything
The reverse is closer to the truth. Experts often cannot recall what was hard, so their explanations skip the very steps a newcomer needs. A person who understood a concept last Tuesday still remembers the wrong turns, the misleading error message and the documentation page that finally helped. Those recollections are what make a tutorial worth reading. What you need is accuracy about what you did, not a decade of seniority.
Myth 2: Everything has already been written
The topic may exist; your route to understanding it probably does not. Search results for any CMS question are crowded with posts that describe the feature and say nothing about the confusion around it. A write-up that begins “I assumed X, and it turned out to be Y” gives a searching beginner precisely the reassurance they are missing. Two people explaining the same feature will choose different examples, and a reader benefits from whichever example clicks.
Myth 3: Publishing a half-understood idea makes you look foolish
Publishing something you pretend to understand is risky. Publishing what you understood, what you tested and what still puzzles you is the opposite. State the limits plainly: “Tested on a single install”, “I could not confirm how this behaves with caching”. Readers and fellow practitioners tend to respond with corrections and added detail, which is free review of your thinking. A sensible habit is to name the version or setup you used so that the note stays honest as the software changes.
Myth 4: It takes hours you do not have
A useful write-up can be short. Try this structure: the situation, what you expected, what happened, why, and what to do instead. That is five short paragraphs, achievable in half an hour, and the act of ordering your thoughts often takes less time than the debugging it describes. The effort pays you back, because next quarter you will not have to rediscover the same fix.
Myth 5: The explanation is only for readers, not for you
This is the myth that costs the most. Writing for a beginner is an audit of your own knowledge. If you reach a step and cannot say why it works, you have found a gap. I have seen colleagues realise mid-draft that they never understood how their theme loads a template, or why a page they had “fixed” kept reverting. The reader gets a tutorial; the writer gets the repair. That is also why the same exercise is worth doing when you work through planning questions such as the ones in our guide on preparing a business site before development begins. Try summarising each decision in plain language and you will quickly see which ones you took on trust.
Myth 6: Nobody will ever read it
Maybe not on day one. But beginner-oriented material has a long life, because there is always a new person arriving at the same confusion. Pages that answer a precise question tend to get found by people who typed that question into a search box. Even if the readership stays small, a colleague can link to it in onboarding, a client can understand a decision, and you gain a record of your own reasoning. Compare that with a lesson that lives only in a chat thread that scrolls away within a week.
What a good “learned this week” note contains
- A title that states the confusion, not the technology.
- The setup you used, so readers can judge relevance.
- One reproducible example.
- The wrong assumption you started with.
- A short note on what you would test next.
Structure like this also supports the site-structure thinking found in our overview of the core pages a company site tends to need, since a clear learning note is often the seed of a help article or documentation page that belongs on a business site anyway.
Where to publish if your own site is locked down
Not everyone has a spare corner of their company site for personal notes. In that case, a hosted option is practical, and one route is the MyBlogPad publishing network, where a blog can have several contributors and each blog is served from a subdomain of its own. A team could keep a shared learning log there and never touch the production CMS.
A short practice exercise
- List three things you figured out in the last week while working on a site.
- Pick the one that confused you longest.
- Write five short paragraphs following the structure above, for a reader who has never opened the admin screen.
- Mark every sentence where you hesitated. Research until you can fix each one.
- Publish it, and note the date and the version you tested.
If any of the six myths has been holding you back, test it against your own experience this week. The likely outcome is a clearer mental model for you, a time-saving reference for your team and a small lesson for the next beginner who lands on the same problem.
