Ask HN: What do you want or not want to see in developer newsletters?

That means:

- No articles that with analogies that don't say anything of value.

- No articles full of some random person's journey.

- No marketingspeak. If marketers don't understand the tech in the first place, they shouldn't be trying to write about it, let alone trying to pad something out to a word limit.

- No hopes and dreams. Marketers want to promise anything and everything. Real progress is made incrementally, when it's done. Markets should instead write about interesting anecdotes we find along the way.

- No standard issue times. Value is sometimes spread out, and sometimes clustered together. Issues should match real value, not an interval. Otherwise you end up saying nothing when there is nothing to say, and miss out when there is something worth saying.

If you want to show something to marketers, show them some videos of Sabine Hossenfelder ripping apart yet another bullshit marketing press release or argument about a popular topic. (Personally I'd recommend her video on fusion) You don't need to know the science before hand, because she'll explain what the science actually is, and why the press release and other marketing is wrong. Make a list of every kind of trope those press releases fall into and turn them into a checklist of what to avoid for your own releases.

Even with an example written for an article, if it's non-trivial then there will have been trade-off design decisions. In some ways, understanding the reasoning behind tradeoff decisions to make when using an SDK is more important than an example that shows me what arguments to use when calling a specific function.

For example, you have an article about Python and your checking the size of the array. Don't just tell me it's len(my_array), explain the decision to do that.

As an aside in case your interested, as I understand it the reasoning is to implement length via a strategy pattern: any object which has a concept of length can implement a __len__ method, and len() will then use that method to get the length, which allows a lot more flexibility without having multiple ways to do length.