Any post that involves "best practices" or any specific programming language should have a date attached. Programming languages change and best practices change to follow suit.
When I'm looking up a topic it sucks to get halfway through an article and realize that half of the methods it recommends have been deprecated. If the author had bothered to put a date on the post I would have known to avoid it.
See, right there, you've captured it. If I write a "Best Practices" article with a 2012 dateline on it, the first thing you the reader will do is try to track down the most recent piece that updates it.
So it's better to let them spend a bunch of time learning something that's potentially outdated?
I think it depends entirely on the material and how long it's likely to be valid for. Basic principles of human nature, for instance, are likely to not change a bunch from one day to the next (although research might reveal new views on them). How to install mod_perl on Apache in order to create actual dynamic web sites... Perhaps that's best left to the late 90ies.
I think it depends on how generally the [whatever] is written. I'm working through SICP right now and learning all kinds of concepts 100% relevant to today, because the textbook was written to convey general ideas instead of their specific implementation. And that book was written in the '80s, which is practically forever ago in the CS world.
I think that it's implicit that you're supposed to keep the articles up to date.
OK, but then why not then update the date of the article?
Every so often I find myself reading something and start to wonder if it's still current. It's frustrating to not then find that date the article was written or last updated.
Basically, I don't see a downside for including a date, but there are assorted pitfalls for the reader if omitted.
The downside addressed by the parent is that an article dated "2012" will be discounted by many potential readers, even if all of the information is still current.
For something where specific versions or dates matter, nothing about the article suggests that you not address it in the "post." If a configuration file changed in April, 2013 then you should write about how it changed and how to deal with the different versions. And if you're writing about something specific to Python 3, you should be specific about that restriction. But I don't see how dating the article as "August 17th, 2013" is going to effectively communicate either of those nuances.
The article date is at best an imperfect proxy for whether the information is current. And the OP and parent are claiming that prominently displaying the date (and other "blogging artifacts") cause potential readers to discount the information more than they should. I don't know whether the argument is universally true, but it's plausible.
> See, right there, you've captured it. If I write a "Best Practices" article with a 2012 dateline on it, the first thing you the reader will do is try to track down the most recent piece that updates it.
Whereas if you right one with no date, I'll just distrust it and look for one with a verifiable date. If I know how outdated it might be, that gives me some confidence -- I can look at it and use other sources to determine if there are relevant changes to the related platform that need to be taken into account.
If I don't, I can't. In general, my assessment of technical information online is Current > Old > Uncertain.
I know you (and many others) believe that to be your preference, but I don't think your revealed preferences match it.
One way to put it is: if I put a date on my writing, I accept a finite but certain discount on its value. If I don't, I risk an unbounded but uncertain discount, depending on how valuable the content itself proves to be.
If I'm writing a piece on how to do TDD with rspec, that unbounded discount is nearly certain to occur, because the subject itself is fixed in time. But I'm writing a piece on using advanced statistics to optimize ad placement, or on why people shouldn't use narrow-block deterministic disk encryption algorithms to encrypt individual files, the subject isn't anchored to any particular time, and the discount I take for adding "uncertainty" by losing the dateline is unlikely to materialize. Whereas no matter what I do, if I write that ad placement post as a blog post, it's dinged as a blog post.
> I know you (and many others) believe that to be your preference, but I don't think your revealed preferences match it.
And I know you're wrong, as to me (can't speak for "many others".)
> One way to put it is: if I put a date on my writing, I accept a finite but certain discount on its value. If I don't, I risk an unbounded but uncertain discount, depending on how valuable the content itself proves to be.
Both are uncertain, really.
> If I'm writing a piece on how to do TDD with rspec, that unbounded discount is nearly certain to occur, because the subject itself is fixed in time. But I'm writing a piece on using advanced statistics to optimize ad placement, or on why people shouldn't use narrow-block deterministic disk encryption algorithms to encrypt individual files, the subject isn't anchored to any particular time, and the discount I take for adding "uncertainty" by losing the dateline is unlikely to materialize.
Especially in the former case, its not entirely obvious that the subject matter is inherently not fixed in time (while the statistics may not be, the application seems to be very time sensitive. A reader can, of course, evaluate whether there are relevant changes, but not without information about the context -- and particularly the time -- for which the piece was written.)
> Whereas no matter what I do, if I write that ad placement post as a blog post, it's dinged as a blog post.
Aside from "official" sources (projects own documentation sites, etc.) pretty much the most useful sources I find on technical subjects are blog posts.
OTOH, there's certainly probably many cases where utility for the poster of advertisement-disguised-as-technical-information differs signficantly from the utility to the reader of actual technical information. And I don't doubt that often, at least in terms of drawing certain types of business, concealing the date of information is useful for doing that -- there's a reason why ads, even when posted in places where they will be exposed for a very long time, rarely have dates on information, and when they need to, its often in microscopic print in disclaimers.
This is a sleight of hand. The crypto challenges, for instance, have a business function (albeit not one we originally intended), but are not in fact literally ads, no matter how quickly you wave your hands; what they are in fact is a sequence of 56 3-paragraph descriptions of cryptographic flaws and how to demonstrate them.
Similarly, a downloadable e-book does not transmogrify from "useful technical information" to "disguised advertisement" simply by living in an undated PDF document behind a paywall.
> Similarly, a downloadable e-book does not transmogrify from "useful technical information" to "disguised advertisement" simply by living in an undated PDF document behind a paywall.
Well, if its a behind a paywall, its probably not a very good advertisement. But I was discussing, at any rate, the difference between factors impacting the utility of a particular piece of writing as useful technical information for the reader vs. those affecting its utility as a advertising for the creator/publisher -- those two roles can coexist in the same piece of writing at the same time (they don't require anything to "transmogrify" from one thing to another to change between them), they are utilities related to different interests that different parties have with regard to the material, not to inherent differences in what the material is.
Concealing the date can simultaneously make the piece of writing more useful to you as an ad, while making it less useful to the reader as technical information.
I read that paragraph 3 times and I think all it says is "readers have interests that are not (necessarily) identical to those of authors". In which case: I agree.
Meanwhile, you continue to refer to technical writing that lacks a dateline as an "ad", which is self-evidently false; technical writing does not become an advertisement merely by dint of lacking a dateline.
> I read that paragraph 3 times and I think all it says is "readers have interests that are not (necessarily) identical to those of authors".
Well, specifically, its that "readers interest in gathering technical information is distinct and often at odds with the promotional purpose that publishing information serves for authors/publishers" -- there are other (also potentially conflicting, in some cases) interests each might have, but I was specifically focussing on one interest of readers and one interest of authors/publishers.
> Meanwhile, you continue to refer to technical writing that lacks a dateline as an "ad"
No, I don't. I refer to advertising for the author as a role which technical writing may have for which omitting the date may be useful even when it is counterproductive to the utility of the piece in its role as a source of technical information for the reader.
> technical writing does not become an advertisement merely by dint of lacking a dateline.
Nor have I, even once, said that it did. So I'm not sure why you feel the need to keep denying this claim that was never advanced.
If most readers' assessment were instead, Current > Uncertain > Old, then perhaps it would be best for date to be left out of the URL and templates only to include it conditionally? Would it be dishonest to tell you that today's post was written today, but not say when a post from three years ago was written?
> If most readers' assessment were instead, Current > Uncertain > Old, then perhaps it would be best for date to be left out of the URL and templates only to include it conditionally?
Well, sure, it would be "best" in terms of maximizing the initially perceived value of the information you are providing by negating inputs to the reader's initial assessment when they would work against you.
Of course, if the reason people's filters work that way is experience-based rather than some innate feature of psychology, the utility of that practice will wane over time and as experience alters the assessment.
> Would it be dishonest to tell you that today's post was written today, but not say when a post from three years ago was written?
To an extent, yes, it would be dishonest, especially if the whole point is to withhold information about currency only when it would weigh against the reader's assessment of value. Practices of that type (highlighting the newness of new content but avoiding discussing the datedness of other content) are pretty common, though.
When I'm looking up a topic it sucks to get halfway through an article and realize that half of the methods it recommends have been deprecated. If the author had bothered to put a date on the post I would have known to avoid it.