Homebrew Computer Club newsletter by Hugo Pardo Kuklinski
Homebrew Computer Club by Hugo Pardo Kuklinski (CC-BY 2.0)
The great thing about software development is that there is always something new to learn! The terrible thing about software development is that there is always something new to learn! Luckily, there are tons of wonderful people sharing their knowledge every week in helpful and entertaining newsletters … and unfortunately, it can be really easy to get buried under an avalanche of developer-focused articles and end up never learning anything as you flit from open tab to open tab.

When you consider how much content is shared on social media, it may seem old-school to recommend subscribing to newsletters, but for developers who are short on time and long on curiosity, newsletters are a powerful tool. Edited and curated newsletters provide a powerful filter function, can be received and read when you have bandwidth to deal with them (rather than when the algorithms think you need to see them), and have way more relevant ads. Why spend your time trawling Twitter, Medium, and HN if you can have a trained professional do it for you?

In this post, we’ll talk about how to put together a newsletter strategy (you can make any plan seem more important by calling it a ‘strategy’) that will help you learn more and more useful content, and feel more in control! This isn’t a one-size-fits-all process; in order to come up with something that works for you, we have to answer the classic questions: Who, What, When, Where, and How.

Who are you? What do you want to learn?



Before you can come up with a newsletter strategy, you first have to know what you want to learn (or keep up-to-date on)! Are you excited about microservices, or APIs, or general webdev coolness? DevOps, monitoring, or managing other engineers? If you can think of it, there’s a newsletter (or two, or three, or five) about it.

A good first step is to pick two or three newsletters that focus on your current area, such as the language you spend most of your time in, or your favorite framework or platform. Then choose one or two newsletters about other areas that interest you (but that aren’t about what you spend most of your time on day-to-day). If you go overboard and subscribe to five or six newsletters in a new area, you will quickly become overwhelmed (and there will be a LOT of link duplication, especially if it’s a new technology).

Once you know what you want to learn, it’s time to find your newsletters! There are plenty of ways to track down newsletters that are a good fit for you. There are several awesome-* lists on Github just for newsletters, and the awesome-* lists for the technologies you’re interested in will also usually have a “Newsletters” section (e.g. Go, Kubernetes). Cooper Press and O’Reilly both have lists of newsletters on a wide variety of tech topics, and of course IBM has quite a few newsletters, too. Most newsletters will have archives you can check out before entrusting them with your email address.

If you follow developer advocates, open-source technical communities, or just cool developers on Twitter, keep an eye out for newsletter links they share. Often people you follow may not have an official ‘newsletter’ but will send intermittent emails linking to their blog posts. If you subscribe to their updates, you won’t have to fight the Twitter algorithm to make sure you’ve seen their latest work.

Most SAAS providers also have newsletters, but they probably ask you to subscribe to them every time you log in to your account, so you are likely already aware of them. 🙂

How (and When, and Where) to Read a Newsletter



If you don’t put a plan in place to deal with all the exciting new newsletters in your inbox, you’ll end up unsubscribing, deleting unread, or (worse-case) filing those newsletters into a Folder of Dread that you’ll never open again.

If you get a lot of email, do set up filters for your newsletters, and have a regular weekly time where you review them. If it’s a topic you’re already familiar with, scan the newsletter for articles of interest and open those links. (When I’m brand-new to a topic, I might open EVERY link for a week or two until I get an idea of what subtopics interest me the most.)

Once your browser tabs are at max capacity, read through the first two paragraphs of each article, and decide whether you want to spend more time with it or not. Maybe the title was misleading, or the author’s style isn’t compelling, or it’s a thinly-veiled vendor promo … close the tab! If the topic is worthwhile, there will be a better or more interesting article next week.

If you’re still interested after a quick look, save the article to a bookmarking/read later service (such as Pinboard, Evernote, or Pocket). If you read about a lot of different topics, add tags so that you can read several articles in a row about the same topic and spend less time context-switching.

When and Where Pt 2: It’s All About the Follow-Up



Once you’ve selected the articles you think are worth reading, the most important thing is to SET a time to read them and stick to it! Block time off on your calendar for learning every week, and to pick a time when you know you will be fairly alert and awake and aren’t likely to be interrupted. If you’re not a morning person (or if you have small children who demand attention before you’ve had coffee) don’t plan to wake up early and concentrate on reading technical articles! Likewise, don’t set aside time late Monday afternoons if you know that’s when your team is usually pushing to close out a sprint.

If you mainly read on your commute (and can’t code on public transit), set aside another block of time to try how-tos and tutorials. If you find something that’s relevant to a current project, tag it with a project name (sometimes I attach it to a calendar entry for time set aside for a particular project). This will keep you from digging through a list of articles muttering “I know I saw something about attaching volumes to a Docker container SOMEwhere …”. If you find yourself with a few minutes of downtime between meetings (or while waiting for your CI …) there’s a service called ReadRuler that you can connect to your Pocket account that will sort your to-read list by reading time.

The last task in your newsletter strategy is to set aside time to delete unread articles from your to-read list. If you’re even mildly curious about new technology and interested in learning (and you are, or you wouldn’t be reading this) you will probably save more articles than you can read. Pick a time limit (no more than three months) and delete (or archive if you must) any unread articles older than that limit. A too-long to-read list is demotivating and will eventually keep you from opening it, and reading outdated articles is worse than reading no articles at all! And if you go a few weeks without saving (or even opening) any links from a particular newsletter, unsubscribe, and free that slot up for something else!

Newsletters can be a fantastic way to keep up-to-date, learn new skills, and explore new technologies, and are easy to manage, timebox, and control in general. Happy reading!

Join The Discussion

Your email address will not be published. Required fields are marked *