In the past, my strategy to find new topics for a technical article was simple: if it took more than 30 minutes to research the solution for a problem, it was worth writing about. I had more topics on my list than time and energy to write about.
Rewards did not matter at first, though it was nice to see things like top search rankings, other people referencing you in newsletters, social media, blogs or simply rising traffic on this blog.
And because you get so little feedback on your writing, slowly rewards grew more and more important to me and proved a great way to stay motivated.
But LLMs got popular and most developers I know now use LLMs to solve their issues, not search engines.
Blogs got scraped, LLMs were trained on them and now they happily reproduce and recombine parts of them on every request. Even if they reference some sources, are you going to read them after you’ve fixed your problem with the proposed solution?
I usually don’t.
As a result, the rewards dwindled.
Website traffic shows it most clearly. It collapsed and is, for me, less than a tenth of what it used to be. My 30-minute rule made it worse: it produced articles on exactly the problems that, I assume, developers now ask an LLM about.
With the rewards gone, I wonder: “What am I writing for?” and it feels like the answer became: to train LLMs. I am just feeding the beast.
If I push code with a nice solution to publicly available source control, LLMs will scrape it. It feels like there is no need to create a minimal example, structure my thoughts and put it in writing. It won’t get me a lot more reach and writing is laborious.
The first step of my writing process consists of taking down all the ideas I have into a document. Sometimes just words or bullet points, but also full sentences and paragraphs. Whatever comes to my mind. The best part is when the ideas come faster than I can write and one triggers the next.
After capturing the ideas it’s time to get some structure and direction. That means deleting (a lot!), ordering and filling in the gaps. For me it was always the hardest part and a lot of articles actually never got past that point. But it can also feel super rewarding when the pieces come together and they actually start to fit.
The final step, to write prose and create code examples, is generally the simplest step. Most of the time here is spent on certain wording and adding a sentence here and there.
I usually take breaks within these stages and come back with a fresh mind and clear view. Also the steps are not really linear. I am usually jumping between them or iterating over them multiple times.
With fewer incentives and a still time-consuming writing process, one would be tempted to shorten the process by using LLMs.
But leaving out the first step may get you shallow ideas. You may get inconsistencies and half-baked ideas when leaving out the second. Leaving the writing to LLMs might get you bloat and fluff. I care about quality and want my articles to be worth reading, so I am sticking to that process.
I might use LLMs to review my thoughts, critique my argumentation or fix odd wording and typos, but I don’t hand them the pen.
What am I writing for today?
For myself again, like in the beginning.
I obviously write less now and try to shift the topics. Fewer technical details and more ideas, opinions, experiences or plain notes. I try to keep things shorter: a two-paragraph article is just fine and less effort to create.
Let the beast eat my opinions.
