Now that I've been programming for a nontrivial number of years, it's happened enough that I no longer trust future me to understand anything clever that I do, so I spend much more time structuring code to require minimal context. Failing that, ample documentation, because future me will appreciate having an essay to read much more than current me wants to write it.
Seriously.
I'm now more obsessed with documentation and the kind of code structuring you mention and have come to hate, viscerally, projects that lack documentation.
As a potential aside, I once took a course in ASP. We had a bit of time before the class started and the tutor had a chat with a couple of us. Some huge government projects were in the news for having failed and gone well over budget. He told me he'd worked for the company behind them and that they used to obfuscate the code just by stripping out all the comments so the government had to keep going back to them for work.
I think of that any time I hear "but the code is the documentation"…
You need to communicate clearly with a number of coworkers, the most important of whom is future-nerdponx. Sometimes future-nerdponx is smarter than you, and sometimes future-nerdponx is dumber than you, but either way they know where you live, and their misery is your misery.
It's so helpful when I do it that I probably ought to do it more, and if there weren't so much overhead I'd probably do it everywhere.
1. That gives the appearance of a user who hasn't read the article
2. Even if the user did read the article I'm not sure what their comment adds to discussion of the article. For comparison, imagine participating in a conversation with a few friends in real life, friend X says "It's a good idea to write tests for your code," then friend Y replies "It's a good idea to write tests for your code." Usually the way people discuss things is to reply or offer addendums to the original idea. It's not a rule, it's just good conversation.
The article in question is usually not the topic of conversation on HN. It is better to consider it to be the launching point for the conversation. Some will discuss the article, certainly, but you can expect the conversation to branch out very quickly to related items (especially if those items are mentioned in the article). While it's probably not a good idea to discuss the plight of African elephants in these threads, drawing attention to a minor, but specific point in the article is perfectly cromulent.
In this case, the post has value. It does two things. First, it draws attention to a subtopic that was only an aside in the article. (One I happened to miss the first read-through.) Second, the phrasing in the article is somewhat general and vague about this, and the post is relatively more specific and direct.
And in the case where people don't read the article and just read the headline, many comments have nothing to do with the article, and end up discussing a less interesting misconception of the submitted article's title/headline.
It's great to be generous with our interpretations of comments here on HN. But I would like to push for a higher standard of discussion, which has always been the draw of this community, particularly for technical articles (and this is actually a high quality technical article!). So I don't think I'll ever be happy being generous to a low value comment that re-states an opinion from the submitted article without adding anything or even without adding much.
Deprecated means “still supported but its use is discouraged.” It does not mean “no longer supported.”
C++/Wikipedia uses the definition of the original poster, while Java's @Deprecated annotation literally has a `forRemoval` boolean value attached. Personally, I am used to how it is used in semantic versioning where it is just a helpful hint for what the next release's breaking changes may be while introducing the migration behavior if possible in this release. This allows for clients to incrementally migrate instead of making it all or nothing.