{"slug": "what-67-dev-to-posts-in-three-months-taught-me-about-writing-for-developers", "title": "What 67 Dev.to Posts in Three Months Taught Me About Writing for Developers", "summary": "A developer who published 67 posts on Dev.to in three months found that practical how-to guides, such as a local Ollama setup, consistently outperformed deep security content by a factor of five in views. The developer learned to bridge popular topics with niche expertise, using the popular topic as a delivery vehicle for deeper insights. Ending posts with a specific question rather than an open-ended prompt also increased meaningful reader engagement.", "body_md": "Since the middle of April 2026 I have published 67 posts on dev.to. My best one has 576 views. That is not a humble brag, it is the honest ceiling of a security developer who decided to write in public and hit publish every day for three months. I want to lay out what actually happened, with the real numbers I have, because most \"how to blog\" advice comes from people who skip the unglamorous middle.\n\nMy top performer is a practical Ollama guide. A how-to. Run this model locally, here is the command, here is the gotcha on WSL2. 576 views.\n\nMeanwhile the posts I was proudest of, the deep smart contract security pieces where I actually know things most people do not, consistently pulled roughly a fifth of the traffic. Not once. As a pattern. The local-AI how-tos beat the deep security content something like five to one on views, over and over.\n\nThat stung a little, and then it taught me something. My expertise is not what most readers came for. They came for a Tuesday problem: \"I want to run a model on my machine without paying for tokens and it is not working.\" I happen to be able to answer that clearly. The fact that I would rather talk about reentrancy is my preference, not the reader's need.\n\nThe security posts assume you already care about smart contract security. That is a small room. The Ollama post assumes you have a laptop and a mild frustration, which is basically everyone in the building.\n\nI did not stop writing security content. I write it because it is who I am and it is the work I want. But I stopped expecting it to travel. Content that solves a concrete, common, right-now problem travels. Content that requires you to already be in the niche does not, no matter how good it is.\n\nHere is the move that started to work. Instead of choosing between \"the thing people search for\" and \"the thing I know deeply,\" I bridge them. A post like \"running a local model to triage code smells\" sits on top of the popular Ollama topic but carries my security angle inside it. The Ollama part is the door. The security part is the room I actually wanted to show you.\n\nThat reframes the whole strategy. The popular topic is not a distraction from my expertise, it is the delivery vehicle for it. Nobody clicks \"advanced oracle manipulation patterns.\" Plenty click \"cheap local AI setup,\" and if I can teach one security idea while they are there, that is a win that would never have happened in a pure security post.\n\nFor a long stretch I got near-zero comments. Views, sometimes reactions, but silence. I assumed that was just how it goes for technical writing.\n\nThen I started ending every post with one genuine question. Not \"let me know what you think,\" which is noise. A specific question tied to the post: what is your default when a stranger sends you a repo, do you write invariants before you read code, that kind of thing. Comments started showing up. Not a flood, but real ones, from people with opinions.\n\nThe lesson is dumb in hindsight. A blog post is a monologue unless you explicitly hand the reader the mic. People will engage if you give them a small, concrete, low-effort opening. A big open-ended \"thoughts?\" is too much work to answer. A pointed question is easy to answer, so people do.\n\nI publish daily, and I do not rely on feeling like it. I have a queue of drafts and a cron script that publishes the next one. The decision \"should I post today\" is where most blogging dies, so I deleted the decision.\n\nThe setup is not fancy. Drafts live in a folder, a script picks the next one and pushes it via the dev.to API, and cron runs it on a schedule. Roughly:\n\n``` bash\n#!/usr/bin/env bash\nset -euo pipefail\n\nPOSTS_DIR=\"$HOME/projects/pavelEspitia.github.io/posts\"\nNEXT=$(find \"$POSTS_DIR\" -name '*.md' -not -name '.*' | sort | head -n1)\n\n[ -z \"$NEXT\" ] && { echo \"queue empty\"; exit 0; }\n\n# publish $NEXT via the dev.to API, then move it out of the queue\npublish_to_devto \"$NEXT\" && mv \"$NEXT\" \"$POSTS_DIR/published/\"\necho \"published: $NEXT\"\n# one post a day at 9am, pulled from the queue\n0 9 * * * /home/pavel/projects/pavelEspitia.github.io/publish-next.sh\n```\n\nThe point is not the code. The point is that motivation is a terrible scheduler. A queue plus automation means I write in batches when I have energy, and publishing happens whether or not today-me feels inspired. Three months of daily posts did not come from discipline. They came from removing the daily choice.\n\nI spent real time polishing early posts. Rewriting sentences, agonizing over structure. Those are not my top posts. My top posts are the ones on topics people actually search for, published consistently, cross-posted to more than one platform. The polish barely moved the numbers. The topic and the consistency moved the numbers.\n\nThat does not mean write badly. It means the marginal hour is better spent on \"is this a thing people are looking for\" and \"did I actually ship it to where they are\" than on the fourth pass of a sentence nobody will notice. Clear and published beats perfect and queued.\n\nWrite for the problem someone has on a normal Tuesday. Use the popular topic as the door to the room where your real expertise lives. End with a real question so the thing becomes a conversation. Put publishing on a script so your mood is not in charge. And accept that your favorite posts and your most-read posts will often be different posts, and that is fine.\n\nSixty-seven posts in, the compounding is subtle but real. Not viral, not a huge following, but a body of work that exists, a habit that runs on rails, and a much clearer sense of what readers actually want from me versus what I assumed they wanted.\n\nIf you write technical posts: what topic of yours quietly outperforms the stuff you are proudest of, and have you leaned into it or fought it?", "url": "https://wpnews.pro/news/what-67-dev-to-posts-in-three-months-taught-me-about-writing-for-developers", "canonical_source": "https://dev.to/pavelespitia/what-67-devto-posts-in-three-months-taught-me-about-writing-for-developers-2j62", "published_at": "2026-07-23 15:58:59+00:00", "updated_at": "2026-07-23 16:34:11.182413+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "large-language-models"], "entities": ["Dev.to", "Ollama", "WSL2"], "alternates": {"html": "https://wpnews.pro/news/what-67-dev-to-posts-in-three-months-taught-me-about-writing-for-developers", "markdown": "https://wpnews.pro/news/what-67-dev-to-posts-in-three-months-taught-me-about-writing-for-developers.md", "text": "https://wpnews.pro/news/what-67-dev-to-posts-in-three-months-taught-me-about-writing-for-developers.txt", "jsonld": "https://wpnews.pro/news/what-67-dev-to-posts-in-three-months-taught-me-about-writing-for-developers.jsonld"}}