what i'm reading: July 12

Starting to feel a little more on top of life—I restarted my bullet journal and exercise routine this week! Too early to see if it’ll stick, but feels nice for now.

Despite that, I don’t feel particularly on top of my reading list. Have yet to solve the work laptop problem and have the nagging feeling that I’m losing links from…my iPad maybe? I also have a bunch of actual blog posts half-written that…someday I will get to. Someday.

A friend of mine started doing charitable donations every Sunday, so I’m taking it as motivation to set up more recurring monthly donations. Last week I added WISH Drop-In Centre, and this week will be The Human Utility. What ways are you finding to do good in the world?

Papers

• Distributed consent and its impact on privacy and observability in social networks by Juniper Lovato, Antoine Allard, Randall Harp, Laurent Hébert-Dufresne proposes additional privacy settings for social networks that could limit this ability of third parties to build profiles of non-consenting individuals entirely from their social connections. The authors emphasise that this is only one piece of a multi-faceted approach to rethinking privacy on the internet. I liked this because it contained easy-to-explain descriptions of the current issues with how consent is managed online.

Articles

• Bookmarking Read Rust for later reference. Guess I need a blogroll?

Programming language details

• I don’t remember where I found this link about escaping strings using Cow in Rust but now I know a little more about using strings and Rust’s Cow 🐄 enum.

• Jon Bodner posits that Go is a boring language, and that’s a good thing. I like reading about philosophical choices behind programming language design, because it helps in using that language’s strengths.

• Matthias Endler reviews how programming changed in the 2010s, which captures some of the seismic shifts that made it disorienting to try to re-enter the tech world after a decade absence!

• This Live Code Stream collection of tips for writing more “pythonic” code contains some bits I’d never encountered before, since I don’t spend a lot of time in Python. The more languages I dabble in, the more I appreciate resources that explicitly tell you how to write idiomatic code!

How to do a technical thing

• Julia Evans explains the entr command-line tool, which allows you to run commands every time your files change, even if your build tools don’t natively support that—without having to dig into the bowels of inotify!

• Travis Downs' article on Concurrency Costs was a fascinating look at optimising concurrency strategies, though it assumes an understanding of concurrency primitives and more fluency in C++ than I possess. Bookmarking to review in the future after absorbing more content on this topic.

• I’m rewriting a lost work project in Go partly because I don’t know how to write an API client in Go and want to learn, so I ran across Carl M. Johnson’s Writing Go CLIs With Just Enough Architecture at exactly the right time.

• Erin Shepherd posted a tweet thread about a fascinating distributed debugging challenge that illustrates how hard it can be to reason about distributed systems.

Being human in tech

• Bruce Hughes offers a non-binary person’s perspective on how to be an ally to non-binary people in tech.

• Sailor Ghoul’s account of being gaslit out of a job as a Black women software engineer struck a chord with many Black women I follow on Twitter, so it’s worth thinking about how these hostile engineering cultures get perpetuated.

• Chelsea Troy’s post on anti-racist pedagogy digs into things she learned from Chris Emden’s book For White Folks Who Teach in the Hood.

• Cindy Sridharan extolls the benefits of post-commit code reviews, and I admit it’s a compelling argument if you have a resilient CI/CD pipeline and culture.

Performance tracking

• Charity majors answers a question about whether you can measure individual developer productivity (tl;dr: NO), then links to Martin Fowler saying the same thing

• No real surprises in Ranjan Sakalley’s post about goal-based performance and progress tracking, but its emphasis on regular progress evaluations of KPIs makes me think I should probably look at and tweak my official objectives in Workday.

Systems design

• Sonja Blignaut discusses the difference between complex systems and complicated systems. I’m left feeling that software alone is usually merely complicated, but add human behaviour and motivation and it quickly becomes complex.

• Simon Brown outlines some weaknesses of using general-purpose diagramming tools for software architecture diagrams, which is how I stumbled onto his 5-part series about architecture diagrams as text. Mostly a selling-point of the Structurizr DSL, but it’s open source so worth looking in to!

Documentation

• Google style guide has some interesting tips about writing inclusive documentation

• Malte Ubl writes about design docs at Google with a lot of transferable advice about design docs in general.