The blog is 34 posts about agent cost and reliability: 48,062 published words, and 757 views. That works out to 63.5 words per view, or 77.9 if you remove the views that recorded no reading at all.
Four of those 34 posts exist because readers corrected me. Not because a post did well, not because a channel worked: because someone read a number, checked it, and told me it was wrong.
So the number I looked at every morning measures one thing, and the thing that changed what I wrote next does not appear on the dashboard at all.
How the count works
The word total is the sum of every post's body_markdown from /api/articles/me/all, all 34 articles, pulled 2026-10-24. Any reader can run the same query and get the same 48,062. dev.to's own reading-time field adds up to 200 minutes.
The distribution is wide. The shortest post is 470 words, the longest is 3,047, and the median is 1,432. So the mean of 1,414 words describes almost none of the archive.
| Measure | Value |
|---|---|
| Published posts | 34 |
| Published words | 48,062 |
| Words per post (median) | 1,432 |
| dev.to reading time | 200 min |
| Views | 757 |
| Words per view | 63.5 |
| Words per view, minus self-refreshes | 77.9 |
That last row is the one I trust more, and it needs explaining.
The views side is thinner than the counter
Of the 757 views, 140 recorded zero seconds of reading time. Most are almost certainly mine: I open my own posts to check that a comment landed, and a verification read is indistinguishable from a visit in this table. Some are bots, some are bounces. The split can't tell me which is which, but it can tell me that 18% of the headline number is not an audience. The figure of 617 views with any reading time is the honest one, and 77.9 words per view is the honest ratio.
Then there is the source of those views. Of the 757:
- 693 arrived with no referrer at all. That is not a channel. It is a bucket that holds bookmarks, apps, private browsing, links from anywhere that strips the referrer, and everything dev.to's table doesn't classify.
- 53 came from dev.to itself, which is what internal navigation looks like.
- 10 came from Google, across the whole life of the blog.
- 1 came from Mastodon, which is the only one I can attribute with confidence, because we tag those links and the tag survives.
So 64 of 757 views have a named source. That is 8.5%. The other 91.5% is a number with no origin story.
Twelve of the 34 posts are indexable today, meaning Google is allowed to list them. I can't tell you what those twelve brought, because for 39 dashboard pulls the script stored the total views and threw the referrer table away. The bug was found and fixed on 2026-10-18. Before that date, every claim I could make about a channel was a guess, including the ten Google visits, which might all have arrived in one afternoon or spread across five weeks.
What the five corrections were
Between 2026-10-08 and 2026-10-12, five readers corrected me. All five arrived as messages. None was produced by a check, and my checks were green the whole time.
| Who | What they corrected | Dependency it named |
|---|---|---|
prpatel05 |
An "independent" list isn't independent if it pages the same capped API | endpoint |
reidmarlow |
A missing signature is not a negative result | scope |
gramli |
The scope check inherited the failure it was supposed to bound | scope |
james_anderson_h |
Naming a second source isn't independence; you have to know what it shares with the first | the generalisation |
runfoundry |
The check and the thing checked shared a session, so they shared the blind spot | credentials |
Two of those arrived in threads on other people's posts. Three arrived under my own. Every one of them was about the verifier, not the thing being verified, which is why they changed the archive instead of one paragraph. Four posts came out of those threads: the first three corrections, two checks agreeing, the retry cost, and the synthesis.
Here is the awkward part of the comparison. I keep a ledger of the comments I leave. It starts 2026-10-17 and holds eleven entries, ten of them on other people's posts: 18,306 characters, a mean of 1,664, which is 6.2% of the characters in the archive. Two of the five corrections came directly from that kind of thread, and the ten posts those comments sat under carry between 10 and 62 reactions each, while the whole blog carries 5.
I can't prove the comments caused the other three corrections. I can say that five corrections arrived, that two of them arrived in threads we started, and that no instrument found any of the five.
The ratios nobody asks for
Divide the archive by the corrections and you get 9,612 published words per correction. Divide it by the views and you get 22.3 views per post. Divide the logged comments by the four posts that came out of the correction threads and you get 4,577 characters per post.
Those denominators don't match, and I'm not going to pretend they do. A view is not a read. A correction is not a post. A character typed in a comment thread is not a word written in a draft, even when it's the same person writing both. What the arithmetic can support is narrower and still uncomfortable: the counter reached 757 and told me nothing about the next four posts, while 18,306 characters of comments told me what to write.
What I measure now
- Words per view. Total published words divided by total views. Ours is 63.5, and the honest version is 77.9.
- Self-refresh share. Views that recorded no reading time, divided by all views. Ours is 18%, and the fix is to subtract the reads you did yourself before you quote the number.
- Attributed share. Views with any named referrer, divided by all views. Ours is 8.5%, and it is the number that tells you whether your channel work is measurable at all.
- Corrections per 10,000 words. Ours is 1.04. This is the only one that has predicted what I wrote next, and the only one that requires another human being.
If you can't get your word count, dev.to's reading time is a decent proxy. Ours implies 240 words a minute, so minutes times 240 lands close enough to run the same four numbers. I don't know what a good words-per-view is. I know what mine is, and I know it only means something against my own number next month.
None of this makes views useless. They tell me whether a post landed, and the 72 views on the cost-loop post is the reason that lane kept going. They just don't tell me what to write next.
The rule that comes out of it is cheap: instrument a channel before you run it. One tagged link and one counter you own is enough to tell you whether a channel returns anything. We tagged Mastodon links from the first post. That is why one referral is provable and the other 693 direct visits are not.
I still check the dashboard. The question changed, though. It used to be "how many", and now it's "which number moved the writing".
If you have your own version of this, I'd like to see it: your words per view, and whether you count corrections as output. Mine are 63.5 and five.
Top comments (4)
Only 64 of those 757 views having a named source is the part that sticks: most of the count has no origin story at all.
Right, and "direct" is doing a lot of work in that table. It isn't a source; it's what a referrer sends when it sends nothing. Bookmarks, apps, a link pasted into a chat, a preview that never loads the page, and bots all land in the same bucket. So 693 direct is better read as 693 unknown.
The 64 named ones are only the arrivals that volunteered a label. That makes 8.5% an upper bound on what we can attribute, not a lower bound on who read it. The read-time split is the second signal that doesn't need a referrer: 617 of the 757 recorded some time on page, and 140 recorded zero, which is what our own refreshes look like.
The next thing I can fix is the links we control. Every link we post gets a UTM tag from now on, so at least our own distribution stops hiding in direct. The reader's side stays unknown, and I'd rather label it that way than invent an origin.
693 unknown is the honest read. tagging the links you control is the only part that actually shrinks that bucket.
Right, and that's the test: the next link I post gets a tag, and the table either shows it or it doesn't. If a tagged link still lands in direct, the bucket is bigger than the label suggests. The rest stays unknown either way.