Jan 04, 2017

Blog Flux

Contrary to popular belief, blogs do not need perfect continuity, consistency, or accuracy. Those are nice things to strive for, but not something to constrain oneself to. I’m taking a tip from Khatz and doing the same for my blog.

A post isn’t just text; it’s a message more than anything. The text can change to better convey it, but the message should stay relatively consistent with it’s original intent, which is admittedly subjective and only known by the author. If the overall message of a post changes in a dramatic way, that’s worth a new post for the sake of juxtaposition. But what is the point of leaving ALL past posts untouched when clearly there are ways to make them read better, be more compelling, and possibly more accurate? Posterity? Hah!

There’s value in documenting history, but history is to be stated in retrospect. It’s more efficient. Can you imagine a programmer leaving changed bits of code behind wrapped in comments? No. That’s silly. Delete that stale compiler food and version that sucker. You leave the book-keeping to the commit history of your VCS. Annotate your code with meaningful comments on the changes if you must, but only if it’s useful for the reader.

In the case of a blog, it does not have that implicit commit history, but frankly it does not need one. Programmers use commit history to track bugs, figure out when new issues are introduced, and otherwise is for educational purposes. For a blog, this is only useful information if you want to see how an author/editor does their job. I guess blog edit history might be a nice feature, but meh. If information should be added again, it will become apparent, just as a bug would. There’s a loss of efficiency there if it happens too frequently, but I doubt it will. If that does become the case, well, I reserved the right to be wrong and that’s where I change my process.

Then. Not before that. :)