A few articles from Pointer this week, an amazing post titled “System Design for Advanced Beginners,” and some blogging advice.

The golden rule of software quality by Gabriel Gonzalez says “prefer to push fixes upstream instead of working around problems downstream.” The idea is that by improving third party dependencies, you can improve both your own software quality and that of others’.

This isn’t a mandate, but a suggestion, they write; sometimes this isn’t possible, and that’s okay. I personally struggle to see how my company would allow us to take hours to contribute back to pandas or numpy, though I certainly wish we did.


Different versions of your site can be running at the same time by Jake Archibald opens with the quote “it’s pretty easy for a user to be running an old version of your site.” If they open your site, you deploy an update, and they open a link in a new tab, they now have a different version of the site in each tab.

This is especially likely if you deploy often, have client-side navigation, or have offline-first patterns (what?). The article goes through different scenarios: a lazy-loaded script was updated between when a page loads and when a user requested it; or the script was deleted; or the API response changes; or any number of other things that I’d never thought about.

Web development sounds crazy.


Systems design for advanced beginners by Robert Heaton is an amazing walk through system design for people who know enough about programming, but not enough about designing and building software systems.

It starts with the basics of how web apps interact with browsers, and how a smartphone app might send requests to the same place as a browser. Then one might build a user-facing API and a client library so that power users can interact with your platform. Webhooks are requests that the server sends to a user when something happens, so it’s on the user to listen for them.

There’s so much more that I can’t summarize, but I read the entire thing and learned a lot. I’ll be sure to refer to this in the future.


A blogging style guide, vol. 2 is also by Robert Heaton. It begins with advice about writing style (choosing good words, not using intensifiers like “incredibly” or “very” (working on this!), or being clear about where your piece is going). Heaton also includes tips for technical writing (avoiding contrived examples, making clear which parts are meaningful and which arbitrary, and explaining or excluding new concepts).

He also gives advice for the writing process. He lets post ideas simmer in his head for a few days, then dumps them into notes. He organizes the notes, starts “with the section that seems like it will be the most fun” (I love this!), and edits several times.

More grab-bag advice:

  • save your leftover phrases and snippets
  • “keep a list of writing by other people that you wish you had written”
  • “when someone asks you a question, that’s a good excuse for a blog post”
  • ask people what they liked about a post, so you can do more of it

His volume 1 advice] and how to come up with blog post ideas are also excellent.