Restarting Blogging 3rd Time , What's New This Time

Three in five of the posts I wrote between 2016 and 2020 were about Xamarin.Forms. That framework has been discontinued. If I stopped there, the lesson would be that I backed the wrong horse, and that lesson is worthless, because everyone backs the wrong horse eventually. Frameworks decay. .NET ships an LTS, then an STS, then another LTS. Blazor's hosting model got rewritten. Nobody writes about tooling that stands still.

So framework decay isn't the complaint. It's the premise.

The part that actually indicts my old writing is harder to dodge. My most-read post ever is a Blazor how-to from 2020. Blazor is alive and I'm still using it: this site is a Blazor Server application, and the blog engine rendering this post is one I built on it. Same framework, still healthy, still my daily driver. That post is stale anyway, because the component and hosting models moved underneath it.

It didn't need the framework to die. It just needed the next version.

That's the real shelf life of a how-to. Not "until the framework is discontinued" but "until the version it was written against stops being the version people run." Which is about a year.

Instructions versus reasoning

What I wrote was instructions. Configure this. Wire that up. Here are the eleven steps. Instructions are coupled to the tool the way a screenshot is coupled to a UI. Change the thing and the artifact isn't dated, it's wrong.

What I mostly didn't write was reasoning. Why this architecture and not the other one. What I expected, what actually happened, what it cost me to find out. That kind of writing tracks the problem rather than the tool, and problems have much longer half-lives. Offline sync, state management, verifying code you didn't write, the cost of a token. None of those got solved by a version bump. All of them are still open.

The archive did fine on attention. High six-figure view counts across a decade. What it didn't do was compound. There's no position in it, nothing anyone could disagree with, nothing that makes a case for how I think.

Why it stopped

The database those posts lived on is gone. That isn't the interesting part, since the writing survives elsewhere and I'll link it at the bottom. The interesting part is that I stopped in 2020, years before anything was lost. The archive isn't why I went quiet, so I don't get to use it as the excuse.

I stopped because the writing was a second job stacked on the first one, and I wasn't enjoying it. I tried other formats afterwards and dropped those for the same reason.

I've stopped reading that as a discipline problem. Writing tutorials about a tool is homework. It's work that exists only because you decided to publish, and when the week gets tight it's the first thing to go, correctly. No amount of willpower changes that arithmetic.

Then the format stopped mattering

Think about what a how-to post was actually for. You had a problem, you searched, you found someone who'd hit it before, you adapted their answer to your situation. Every step of that is now worse than asking a model. The model answers the version you're running rather than the version I was running in 2020. It answers against your code rather than my sample project. It doesn't make you skip four paragraphs of preamble.

That's the same staleness problem from a different angle. My posts aged because they were pinned to a version.

So the genre is commoditised, and I don't think that's a loss worth mourning. What it does mean is that publishing now requires having something a model can't produce. A model can tell you how the API works. It can't tell you what broke when I ran my own framework on a different harness, or what a decision cost me three weeks later, or which approach I tried first and abandoned. That's first-hand, and it's most of what's left.

What this is instead

I'm not going to promise a cadence. I've made that promise before and I don't have evidence I can keep it. This is an experiment, and I'd rather you judge it on what shows up than on what I said I'd do.

What I can describe is the kind of thing that shows up. Every post here is the writeup of something I actually built. Not a topic picked for an audience, but the work itself, documented after the fact:

• Something I built, with the design decision and the alternatives I rejected.
• Something that broke, with the diagnosis and the mistake left in.
• Something it cost, with real token and time figures from real runs, reported as ratios.

Two reasons for that shape. It's the part a model can't write, since it depends on having actually done the thing. And it makes the writing a by-product of work I'm doing anyway rather than a second job, which is the only version of this I have any reason to think I can sustain. If I haven't built anything worth writing up, there's no post, and that's a truthful signal rather than a gap to paper over.

What's already in the queue

I know what the next post is, because it already happened. I've spent a good part of this year building an agentic development framework. When I ran it under a different agent harness, it broke, badly enough that calling it a framework was premature. The writeup is what was coupled to what, and how I missed it.

There's a symmetry there I'd rather not have spotted. The archive was coupled to a tool. The framework was coupled to a harness. Twenty years apart, same mistake. The only improvement is that I caught the second one before publishing the claim instead of after.

The old posts are still up on C# Corner and I'm not republishing them here: c-sharpcorner.com/members/s.ravi-kumar. Roughly three in five are for a discontinued framework. They were useful once. They aren't the argument I'm making now.