We firmly believe that the magazine’s success or failure will be based on the strength of its content. As such, we approach authors that we have seen and shared their work and follow the spirit of our publication.

Before we start, we’d like to define the heart and soul of Human Readable Magazine. The following is what we consider our maxims.

1. The content is designed to be read on-the-go, 2. There needs to be a technical angle, 3. It is educational in nature.

By “designed to be read on-the-go” we mean that the articles should not require “audience participation” to get value out of them. For example, in tutorials, one must follow the instructions to get the most out of the article, otherwise, there is no point to the article. The articles we’d like to publish are not like this. While they might include a heavy amount of source code, it should be primarily to demonstrate the points of the article. The reasoning behind this restriction is that readers are expected to read our magazine during their leisure hours (during work commute, breakfast, and even on the toilet).

Another very important element of every article is the technical angle. We do not wish to include articles talking about soft skills, management, etc. We want every single article to be about something technical.

And finally, we want our readers to learn. No matter their experience level. Each article should teach something interesting or new to our readers.

Writing Style

We want your voice. We have no strict rules on how to write. Generally we prefer a more laid-back and casual writing style (with or without cringe humor) than a dry technical one, but it really is up to you.


Not click-baity, but also not simple and dry. Something in between would be ideal.


  • Oh, the Many Ways to Make Triangular Breadcrumb Ribbons!
  • Fastest Math East of the Mississippi
  • React: Fantastic Hooks and How to Use Them
  • Playing with model trains and calling it graph theory
  • Letting neural networks be weird — When algorithms surprise us
  • The Phantom Menace in Unit Testing
  • A song of AIs and fire

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


  • 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.


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


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:

  • Novel approaches (Exploring the Peano Axioms With Algebraic Data Types)
  • Investigative deep dives (Apollo program, Kalman Filter and go-filter)
  • How stuff works (Demystifying Containers - Part I: Kernel Space)
  • Intros to more complex topics (Introduction to Paging or basically anything from Writing an OS in Rust)
  • Interesting and not well known Data Structures (Wavelet Trees - an Introduction)
  • Interesting and not well known Algorithms (Kadane’s Algorithm — (Dynamic Programming) — How and Why does it Work?)
  • Concepts (Fluent Polymorphism with Visible Type Applications)
  • Weird/cool features, hidden language gems, gotchas (Why do we require requires requires?)

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

  • Security
  • Performance

Topics we are not interested in are:

  • Release/PR statements
  • Management/lifecycle/agile/soft skills
  • Listicles/Top 10s/etc
  • Best/Worst tools, comparisons, etc
  • Best practices