Fabrefact

a blog by Sara Farquharson

what i'm reading: until May-ish

Posting my last reading list sent me on a reading kick, and I finally found the motivation to dig through circa 4 months of newsletters full of links. If I’m going to keep at this pace I need to post reading lists more often, or they will all be 100 links long.

In fact this list is mostly from April; I have yet to sync my reading list for May from phone to computer.

Books

  • Tore through the O’Reilly previews for both Maude Lemaire’s Refactoring at Scale and Tarandach & Coles' Threat Modeling and was left wanting more of each. Can’t wait until these are published!

  • Also skimmed a few chapters each of recently published O’Reilly books instead of finishing Data-Intensive Applications

    • Architecting for Scale, 2nd Edition, Lee Atchison — is this the manager’s version of the SRE book?
    • Building Secure and Reliable Systems, Ana Oprea et al — can’t remember what I thought of this one, and can’t load it
    • Distributed Tracing in Practice, Austin Parker et al — could be interesting later, but not what I’m working on right now
    • Fundamentals of Software Architecture, Mark Richards & Neal Ford

  • Re-read Anne McCaffrey’s The City Who Fought, which I remember liking when I was young, and it extremely does not hold up. It may be time to let go of a lot of problematic stuff, even if I liked it as a teen.

  • Also re-read Anne Leckie’s Ancillary trilogy. Seeing quite a few parallels between Breq and Murderbot. Wonder what it says about me that I love this character archetype so much?

Leadership

  • I keep reading articles about how engineers moving into leadership need to learn to let go of maker mode because I still need to work on that, and Pat Kua’s recent article was a good reminder.

  • Matt Schellhas writes a defense of crabby engineers which I am of two minds on. He makes a good point that senior engineer who seem to be assholes might just be missing key communication skills, but in terms of how a manager should approach that just says “do your job” which…isn’t helpful.

  • I liked what Dawn Parzych had to say in “The Fallacy of Move Fast and Break Things”, since the popular saying is missing the part that you have to be able to recover from failure quickly for this strategy to succeed.

  • Begriff’s massive post on concurrent programming was a lot of fun, mostly because I felt like a wizard for keeping up with it at all. Having read Systems Performance definitely planted some seeds for understanding this.

  • I hoped for more based on the title How to Get Your Team to Challenge Your Ideas, which it turns out is about how to stop being an insufferable dillhole if you’re too assertive, and less about how to coach your team to give feedback. Still, good reminder to check if you’re being insufferable.

  • Ravi Rajan shares some good leadership tips in how to be a rockstar developer.

  • A former Spotify engineer rags on how the Spotify model never really existed. I later read at least one rebuttal to this article, but overall it’s a good reminder that all processes and models are aspirational, and you shouldn’t adopt them blindly.

Remote collaboration

  • Claudia Beresford has a helpfully-timed How to pair-program remotely and not lose the will to live but despite her arguments I’m not sure I want to learn Vim.

  • Beth Andres-Beck has advice for moderating discussions over video which I hope will come in handy next week.

  • I used Google Wave for a hot five minutes before forgetting it existed, but it was fascinating to read this history of Wave and why it failed

  • GitHub is posting a blog series of tips for remote working; the latest at the time I read was this one on effective collaboration. I try to read this a little skeptically, because the tone is very much “we’ve solved this for you and our culture is perfect” when I know it’s not that simple. Some good tips though.

Introductory topics

  • I’m a sucker for intro Rust content, and amos’s half-hour to learn Rust is a good quick overview including stuff I hadn’t seen before, but the nuances for sure did not stick with me. Think I need to play with if let syntax myself before expecting it to make sense.

  • These top 5 best practices for Python security are pretty basic, but make me wonder if I covered dependency management in my recent secure coding lecture…I liked that they shared Python security tools at the bottom, because I’m trying to get more of those in the pipeline for all languages.

  • New Relic’s State of Java was a worthwhile to me since I have to use Java more at work and I don’t really have a feel for the ecosystem. Most boring numbers but I was surprised to find that Java 8 or older is still used by 88% of production environments.

Security

  • I’m thinking of picking up VSCode as an alternate editor, so I was curious when tl;dr sec newsletter linked to a code execution vulnerability in the editor. (Turns out it was actually in a Python extension)

Technical writing

Technical deep dives

  • I don’t remember what linked me to this old post about how a container out of memory can hang proc calls forever but it linked me to a rabbit hole of reading Rachel’s blog. Considering the original post is from 2014, I wonder if cgroups still act the same way?

  • This dev blog talks about advanced Go concurrency when I would certainly not call myself “advanced” in Go, but all the same it was surprisingly readable. Paired well with the other concurrency article (both via the O’Reilly programming newsletter)

  • On the one hand, Philipp Oppermann’s deep dive into Rust async/await programming is well written and provides a lot of context for people new to these concepts. On the other hand, combinator functions and pinning seem like…an unintuitive nightmare? Maybe I shouldn’t have tried to read it at 2am.

  • Yoshua Wuyts may have sold me on how state machines are useful in software