Engineering Newsletters and Blogs Worth Your Inbox
Most engineers subscribe to fifteen newsletters, read none, and feel vaguely behind, because a full inbox produces guilt rather than learning. A shorter list sorted by what you would actually read each one for, why company engineering blogs beat most newsletters, and the weekly routine that makes any of it stick.
Tauseef Fayyaz
Subscribing is not reading
Most engineers subscribe to fifteen newsletters, read none, and feel vaguely behind. The problem is not the newsletters. It is that a full inbox produces guilt rather than learning.
So here is a shorter list, sorted by what you would actually be reading it for, plus the routine that makes any of it stick. Pick two. Genuinely two.
For understanding the industry you work in
The Pragmatic Engineer by Gergely Orosz
The best reporting on how software companies actually operate. Compensation, layoffs, how specific teams are organised, what really happened inside a well known outage. Sourced from people inside those companies rather than speculated about.
Read it for: context on the industry that you cannot get from inside one job.
Deep, curious writing on the things everyone uses and few people understand: DNS, TCP, git internals, how debuggers work. She also draws them, and the explanations are unusually kind about what is genuinely confusing.
Read it for: the fundamentals nobody sat you down and explained.
For architecture and scale
Design Gurus by Arslan Ahmad
System design written by somebody who teaches it full time, which shows in the sequencing. Concepts arrive with the groundwork already laid, so you spend the reading working through the idea rather than looking up three terms first.
Read it for: architecture explained in an order that builds, rather than posts you have to assemble yourself. It pairs well with their structured system design material if a topic turns out to be worth more than one article.
ByteByteGo by Alex Xu
Diagram led explanations of system design concepts and how well known products are built. Consistent, visual and approachable.
Read it for: a steady drip of architecture vocabulary without committing to a course.
Long running collection of real architecture write ups. Older posts included, which is a feature: you can watch how approaches changed over fifteen years.
Read it for: depth on how a specific system was actually built.
First principles explanations of database and distributed systems internals, written by somebody who clearly enjoys the details.
Read it for: the layer below the layer you currently understand.
For AI engineering
Interviews and analysis on what people are actually shipping with AI, rather than what is being announced. Practical, and good at separating the two.
Read it for: keeping current in a field where six months is a long time.
Plainer, more beginner friendly coverage of the same territory.
Read it for: the version that assumes less.
For frontend and product work
Frontend and software design, aimed at engineers who want breadth alongside their depth.
Read it for: the design and product side that backend focused reading skips.
Company engineering blogs, which are better than most newsletters
Newsletters tell you what happened. Company engineering blogs tell you how something was actually built, with the numbers and often the mistakes.
Cloudflare is the most consistently excellent, and unusually honest in its incident write ups. Reading a few of those teaches more about operating systems under load than most architecture material.
Netflix for streaming, caching and chaos engineering at a scale you will never work at, which is exactly why it is instructive.
Uber for concrete, easy to picture problems: matching, routing, pricing, all in real time.
Slack for messaging and for the long unglamorous work of migrating systems you cannot switch off.
Spotify for how engineering organisations are structured and tooled, which is written about far less often than architecture.
The routine that makes this work
Two subscriptions maximum. Any more and you will read none of them. You can rotate later.
A fixed slot. Thirty minutes, same time each week. Not whenever an email arrives, because whenever means never.
Read for a question, not for coverage. Open the piece that touches something you are currently working on. Archive the rest without guilt. You are not falling behind by not reading an article about a system you will never build.
Keep a note file. One line per useful thing, with a link. Six months later this is the most valuable file you own, and it takes seconds per entry.
Ratio of one to three. For every hour reading, three hours building. Reading feels productive because it is easy. It is the smaller half.
If you want structure instead of a stream
Newsletters are excellent for currency and terrible for foundations. They assume vocabulary, and when you are missing it you get the feeling of learning without much of the substance.
For the foundations underneath, Design Gurus covers system design in a deliberate order, which makes the architecture newsletters above considerably more useful because you stop having to look things up mid paragraph.
Our resource library collects all of the above with the courses, books and repositories that cover the same ground, so you can decide which lane you want rather than subscribing to everything and reading nothing.
Comments (0)
Comments are closed for now.
No comments yet.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.