How I decide what to write about
# How I decide what to write about
There is a text file on this machine with about sixty entries in it. One line each, usually a symptom and a date and something a customer actually typed. I have written nine of them.
That backlog is why I can publish across fifteen brands without spending Thursday evenings at a blank document.
The drafting end of this I have written up before, along with the pipeline that carries a finished file out to a channel and the separate headache of fifteen brands reading like one publication with fifteen names. All of it sits downstream of a question that sounds like the easy part. What is this one about.
Deciding on the day is the whole problem
Publish once a fortnight and choosing a subject is a creative act. You wait until something feels worth saying, and the waiting filters out the bad ideas for free.
That survives as long as your cadence lets it. Once a slot needs filling most days of the week, the waiting has nowhere to happen, and you are choosing under pressure with the worst source available: your own head, which by then wants to be finished.
The three sources that refill
The best one is something that broke, plus the explanation nobody had written down.
A modem on one of my servers reported itself perfectly healthy for two days while every request through it failed. When I went looking for somebody else's writeup of that disagreement, what I found was the fix, several times over, on several forums. Nobody had written down the symptom.
That is the gap almost every time. The fix is already public. The mapping from what you are staring at to what is actually wrong is the part nobody records, because by the time you understand it well enough to write down, it has stopped feeling like a discovery. The person searching lacks the vocabulary that would find the fix. They have the symptom, in the words they had before they understood it, and those are the words they type.
Second source: a question somebody asked twice.
Once is a person having a bad afternoon. Twice is a hole in your documentation. Somebody asked me how many accounts one line will carry, I wrote out a real answer, and three weeks later a different person asked something close enough that I typed most of it again from memory, worse the second time.
Two things make this source cheap. The draft already exists, because you typed it once as a reply. And the wording is handed to you. Nobody types carrier grade nat into a search bar; they type why does my ip keep changing.
Third, and weakest, is a widely repeated claim that is wrong in a specific checkable way. The requirement is narrow: you have to go and check it, with a result you can put in the piece. Take the idea that a proxy's advertised location is where the traffic genuinely leaves from. Ten minutes against two geolocation databases will show you they disagree about the same address, which means at least one is wrong, and that is the piece.
The failure mode here is contrarianism. Much of the everybody is wrong genre is somebody who found a corner case and inflated it into a rule. If the correction needs the reader to accept your framing before it lands, you have written an opinion piece in a lab coat.
Why keyword tools are a naming step
A keyword tool tells you what has been searched. Searched means written. A phrase with real volume behind it already has twenty pieces competing for it, most from people with more time than you.
Worse, the tool has no idea whether you know anything about the subject. It hands you a phrase you have no standing on with a confident number beside it, which reads like permission.
I still open one. Afterwards. The topic exists first, and then I go and find out what people call the thing, because the word I use internally and the word a reader types differ more often than they match. That is naming. Treating it as sourcing is how a site fills with competent articles about subjects the author has never touched.
The other dead end is what should I post about, as a way of thinking. If you can ask that question and use the answer directly, everybody else who asked got a list that overlaps yours along most of its length. The test takes ten seconds: cover the brand name at the top and see whether a single sentence changes.
You can only write what you know
This is the constraint everything above collides with, and saying it out loud is unpopular.
A topic you had to look up is a topic your reader can look up too. Whatever you added by going first is twenty minutes of their afternoon, and they feel the thinness even if they cannot point at the sentence.
It rules out fewer subjects than you would think, because half knowing something counts as long as you say which half. The shape is boring and it works: I run this part daily, I have never run that part, here is what the documentation claims and I have not verified any of it. One sentence, and it is the difference between a piece that survives a reader who knows more than you and one that quietly loses them at the third paragraph.
I get this wrong in one direction, consistently. When a piece goes out under a brand that sells something, I over claim, never by lying, just by trimming the hedge because the hedge reads soft. I read the confident sentences twice on those brands now.
The list
One file per brand. Append when something happens. Nothing gets deleted, only moved to the bottom once written.
The rule that makes it work is that the evidence goes in at the same moment as the entry. The log line. The exact sentence the customer sent. In six weeks I will remember the topic and none of the detail, and the detail was the piece.
An entry is a symptom, a date, and something somebody actually said. It is never a title. Titles come later.
At fifty deep, picking takes two minutes, and the choice was effectively made weeks earlier by a version of me who had just been annoyed by something real. That version is a better editor than the one filling a slot at nine on a Thursday.
Not publishing the same piece twice
Past a few hundred pieces this gets difficult, and it fails the same way for everyone. You do not remember the pieces. You remember writing them. Those are two different sets and the gap widens every month.
Title matching will not save you, because a near duplicate almost never reuses the title. If it did you would have caught it while typing. It arrives wearing a different name, which is precisely why it gets through.
So before drafting, every slug for that brand goes into one file and I read the column top to bottom. Then I search the first paragraph of everything for the two or three nouns the new piece is about, because that is where a piece declares its subject, and searching whole articles just tells you that you mention proxies a lot.
I still miss some. I caught two this year, published eleven months apart under different titles, and neither said anything the other did not.
Update or rewrite
The test is one question. What changed.
Either the world changed, meaning a provider changed behaviour or a version shipped, or I changed, meaning I know something now that I did not when I wrote the first one. If neither happened, it is a rewrite with fresh paint, and calling it an update is how I talk myself into it.
There is a second test I trust more. Does the new draft disagree with the old piece anywhere at all. A genuinely new angle nearly always contradicts the earlier version somewhere, because that is what learning looks like from outside. If it nods along from top to bottom, it is the old piece.
Rewriting is sometimes right. Then replace the old one. Publishing both leaves two pieces splitting one job and a reader landing on whichever version a search engine preferred that week.
The generator I had to retire
I built a topic generator. It read every slug on a brand, looked for gaps in the coverage, and handed back a hundred subjects. All hundred looked reasonable.
I wrote seven of them, and all seven read like they came from somebody who had read about the subject rather than done it. Which is what had happened, because I researched every one from scratch. The generator was working from what was absent, and it had no way of knowing that some of it was absent for a reason.
A coverage gap is not a topic. Sometimes nobody has covered a thing because nobody standing where you are standing has anything useful to say about it.
The generator kept one job. It reads the list and tells me which entries have sat there longest, a scheduling question it happens to be good at. The smaller and more embarrassing mistake is that I ran the list in my head for a year first, and lost topics constantly. A text file beat my memory immediately.
When the list goes quiet
When the backlog runs dry, the instinct is to think harder about topics. That is the wrong move every time.
The list is a byproduct. It refills when things break, when customers get confused, when I try something and it does not work. Two quiet months means two months in which I learned nothing, and no keyword tool converts an empty month into a piece worth anybody's time. So when I catch myself hunting for a subject, the honest reading is that the operation went idle, and the repair is upstream of writing entirely.
Get new guides and videos first — join the Telegram channel.