what i'm reading: August 30

Latest batch of reading tipped me over the threshold of having to look up the etymology of “footgun”, which seems to be everywhere in programming language discussions. As jargon I think this term is memorable but ineffective—before looking it up I assumed the meaning was “pointless extra feature that sounds cool but is impossible to use properly”, vs the intended meaning of “feature that will lead users into trouble”.

Books

• Started the audiobook of Gut: The Inside Story of Our Body’s Most Underrated Organ and have been excitedly inserting anecdotes about digestion into every conversation with my very patient loved ones.

Papers

• Have had Leslie Lamport’s 1978 paper Time, Clocks, and the Ordering of Events in a Distributed System open in a tab for weeks, and finally found the mental energy to read it. I quite enjoy reading older papers about distributed systems and seeing where some of the field’s current best practices come from! Someday I’m going to have to learn more mathematical symbols in order to understand more of the proofs though.

Articles

Effective leadership and managing people

• David Daly’s post about returning to an IC role after being a manager for a few years was interesting to me mostly for the example of self-reflecting to identify what specific parts of your job make you happy.

• I liked how practical Sally Lait’s tips about how to scale yourself as an engineering manager were!

• Even though I don’t know if this will ever be directly applicable to me, I enjoyed Claire Lew’s practical advice on how to help new managers level up quickly.

• Adrienne Lowe has a bunch of good, specific advice for managing senior engineers

• This LeadDev article from Katie Womersley is about effective vs counterproductive ways to “manage up”, but I think it identifies patterns and anti-patterns for forming good collaborative relationships with anyone you work with.

• The reality of being a Principal Engineer by Silvia Botros mostly contained validation of things I already believe, but I liked the emphasis on influencing other people and being a role model, intentional or not.

Difficult problems in software development that are only a little about managing people

• I really enjoyed Rain’s post on the problems with software dependencies, which covers a lot of the history of dependency management, the current tradeoffs which need to be made in every language/project, and a focus on the choices being made by Rust’s package manager Cargo.

• Captivated by Carmen Andoh’s twitter thread about how modern collaboration tooling like GitHub increases burnout among maintainers of large OSS projects, and how some modern projects are building collaboration tooling to deal with this problem, even as Linux is trying to modernize its workflows in the other direction. An interesting tradeoff I was not aware of before!

• Paul Börding and Steve Upton’s post on managing feature toggles covers the nitty-gritty details I’ve always been curious about how to implement like: what process can you implement to make sure teams remember to remove the toggle after it’s no longer needed?

• Jacques Mattheij states almost exactly why I avoid installing software updates, even though I am aware of the security risks that causes.

• Selected an article in Increment’s new API edition almost at random, and found Darius Kazemi’s delicious dive into the history of HTTP status codes as an example of how API decisions can have an outsized effect on the future of technology.

Building inclusive teams

• Erica Stanley’s LeadDev article So you want to build antiracist teams includes a number of specific actions companies can take to build an inclusive culture, as well as resources for Black technologists to combat isolation if their current company is not very diverse.

• Not hype about linking to LinkedIn posts, but Andrew Hedges' post about what early-career developers need to succeed contains some good guidelines on how to design a good learning experience for new developers.

• Kat Fukui’s account of receiving targeted harassment through her employer’s platform (CW: screencaps and descriptions of racist, sexist, transphobic, abusive language and actions) contains a coda about what tech leaders need to think about in creating a safe working environment for employees.

Programming language wonkery

• Steve Klabnik wrote a post that is mostly about a debate in the Rust community around a macro called CXX, which is above my pay grade, but I found it valuable for the explanation of what the unsafe keyword in Rust means and how to use it.

• Andreas Rossberg’s explanation of the design decisions behind his new programming language, Motoko, was an interesting read, since it included approachable overviews of Wasm and the actor model in programming languages. The overall project seems a little buzzwordy, but I liked reading about why specific choices were made for a language, and now have the original Wasm research in my reading queue.

WIP learning resources

• One of the projects I’m working on is a tiny web app using React. As soon as I needed to persist data between components I have been leaning heavily on the React-Redux basic tutorial and Dan Abramov’s Persisting the State to the Local Storage in order to solve my specific use-cases without needing to stop coding entirely in order to learn a new subject.

• Also for this project, A Complete Guide to Flexbox has been invaluable to get even the roughest positioning using modern CSS techniques.

Learning in public

• Vishnu Bharathi wrote a cool investigation of practical uses of Levenshtein distance using examples of several command-line parsers, including descriptions of how he analysed the code to learn and practice dynamic programming.

• Christina Austin wrote an in-depth explanation of making two divs toggle using only CSS with no Javascript, including a lot of browser wonkery I’d never heard of before.

Security

• Bas Alberts posted the first in a series about finding C vulnerabilities in interpreted languages like PHP and Perl, and I am already eagerly awaiting the next installment!

• Maddie Stone has a great post on the Project Zero blog about how limitations in how 0-day vulnerabilities are detected mean we can’t draw many conclusions from the data, including some hypotheses on why so few 0-day exploits are detected.