Most (if not all) dev tool companies have developer newsletters for marketing content, and I'm tired of having my inbox filled with a bunch of emails that I almost never read and almost always have to unsubscribe.<p>But as someone who works closely with marketing teams, I also want to find the right feedback to share with them about how to effectively make their developer newsletters more interesting and impactful.<p>So what are your thoughts?
- What do you want to see in newsletters?
- What do you never want to see in newsletters?
I DO NOT want to see any articles that have no tech in them.<p>That means:<p>- No articles that with analogies that don't say anything of value.<p>- No articles full of some random person's journey.<p>- 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.<p>- 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.<p>- 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.<p>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.
I would like to see not just code, but also a discussion of the tradeoff decisions made when creating that code, and a discussion of what could be done or looked at next.<p>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.<p>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.<p>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.