5 ms·

Any post that involves "best practices" or any specific programming language should have a date attached. Programming languages change and best practices chang

by jobu 12y ago

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.

tptacek 12y ago
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.
- davidw 12y ago
  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.
  - grayclhn 12y ago
    I think that it's implicit that you're supposed to keep the articles up to date.
    - jamesbritt 12y ago
      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.
      - grayclhn 12y ago
        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.
  - rthomas6 12y ago
    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.
- dragonwriter 12y ago
  > 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.
  - tptacek 12y ago
    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.
    - dragonwriter 12y ago
      > 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.
tjr 12y ago
Would not referring to specific software versions work approximately the same as including a date in such situations? E.g., writing about recommendations for Python programming, and stating that you were running Python 2.7.5 at the time, or whatever.

by jobu 12y ago

tptacek 12y ago

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.

davidw 12y ago
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.
- grayclhn 12y ago
  I think that it's implicit that you're supposed to keep the articles up to date.
  - jamesbritt 12y ago
    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.
    - grayclhn 12y ago
      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.
- rthomas6 12y ago
  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.
dragonwriter 12y ago
> 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.
- tptacek 12y ago
  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.
  - dragonwriter 12y ago
    > 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.

tjr 12y ago

Would not referring to specific software versions work approximately the same as including a date in such situations? E.g., writing about recommendations for Python programming, and stating that you were running Python 2.7.5 at the time, or whatever.