Content Guidelines

Below we include further information about the type of content we’d like to see in our magazine. Separately we have a page with a significant number of examples that would help authors understand better what we are looking for.

Each issue will have the following type of content:

First Page

  • From the Editor

  • Op Ed

  • Letters to the Editor

  • Causerie

Main Content

  • Programming News

  • Cover Story

  • Columns

  • Articles

Closing

  • Movie/Book Reviews

  • Upcoming Events

  • Corrections

Programming News

Being a monthly magazine, we don’t expect to be punctual when it comes to news. However, being monthly also allows us more time to analyze and digest the news. We don’t expect many news items in each issue, but we’d like whatever ones we include to be thoroughly researched and also written from the perspective of an engineer wanting to know the technical details.

In other words, not “X happened”, but “This is why X happened”.

Cover Story

Each issue will contain one long-form engineering story. These are “war stories” that authors have experienced and would like to share with the world what they have learned.

Columns

While columns are still technical in nature, this is where authors can have more of an opinionated piece.

Articles

We are looking for educational articles that the reader would say "Huh, that was interesting to know"; articles that you wouldn't necessarily search online unless you were curious about a very specific topic.

They are strictly technical, sometimes long deep dives. The author can assume that the reader has the knowledge necessary to read the article. We are targeting developers of all fields and experience levels and we will make sure that each issue has a diverse set of topics so that beginners and experts will have something to read.

These are not tutorials. If it starts with “How to”, chances are it doesn't fit the magazine. We’re looking for articles more in the “How and/or why X works”. We'd also like to avoid opinionated pieces like "X considered harmful", or "Never use X feature", "Why X is bad, and you should feel bad", etc, etc.

We typically prefer articles that focus on the programming language itself, rather than libraries and frameworks. We make exceptions for libraries and frameworks that are almost as popular as the language itself (ex. Ruby of Rails) or have taken a “life of their own” (ex. React, Vue, etc.)

If the article has no source code, it probably isn’t a good fit.

For inspiration, please refer to the articles section of the examples page which has a plethora of articles we have previously shared in our newsletter Morning Cup of Coding. Hopefully the examples paint a good picture. Here is a short version of that list:

While we accept these topics as well, these are lower in our priority list:

  • Security

  • Performance

Topics we will not interested in are:

  • Release/PR statements

  • Management/lifecycle/agile/soft skills

  • Listicles/Top 10s/etc

  • Best/Worst tools, comparisons, etc

  • Best practices