Last Updated: 2026-04-21
An incomplete and evolving collection of texts and presentations that influenced my views on programming and software engineering. I recommend all of them.
Conway's Law
https://www.melconway.com/Home/Conways_Law.html
Designing Data-Intensive Applications by Martin Kleppmann
https://dataintensive.net/
Martin Kleppmann's Distributed Systems Lecture Series
https://www.youtube.com/watch?v=UEAMfLPZZhE&list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB
The Grug Brained Developer - A layman's guide to thinking like the self-aware smol brained
https://grugbrain.dev/
John Carmack on Functional Programming in C++
http://sevangelatos.com/john-carmack-on/
Mike Acton on Data-Oriented Design and C++
https://www.youtube.com/watch?v=rX0ItVEVjHc
A Philosophy of Software Design by John Osterhout
https://www.amazon.de/-/en/John-Ousterhout/dp/1732102201
Hillel Wayne: Are We Really Engineers?
https://www.hillelwayne.com/post/are-we-really-engineers/
Dan Luu: Computer Latency 1977-2017
https://danluu.com/input-lag/
A common falsehood that people believe is that computers only ever get faster. This is mostly true with regard to throughput - modern computers can crunch more numbers per second using less energy than ever before. In other important aspects, however, computers stagnated or even got worse.
Rachel Kroll: Some items from my "reliability list"
https://rachelbythebay.com/w/2019/07/21/reliability/
Condensed wisdom from a very experienced sysadmin.
Zero To Production In Rust by Luca Palmiere
https://www.zero2prod.com
The best practical guide for creating production-grade back-end services in Rust.
Luca Palmieri: Error Handling in Rust - A Deep Dive
https://www.lpalmieri.com/posts/error-handling-rust/
Basically chapter 8 of zero2prod in the form of a presentation. This one is especially important because the advice on error handling applies far more universally than just to Rust or back-end development.
Modern Software Engineering by Dave Farley
https://www.davefarley.net/?p=352
D. L. Parnas: On the criteria to be used in decomposing systems into modules
https://dl.acm.org/doi/10.1145/361598.361623
A classic paper on why and how to do decomposition. When writing a complicated program, we often intuitively decompose temporally, i.e. if the program does A first, then B, then C, we tend to create modules A, B, and C. Parnas shows that this naive decomposition strategy is often wrong. A, B, and C might, for example, share a common data structure. Whenever you change something in module A which affects the common data structure, you now need to change modules B and C, too. A better strategy is "information hiding": modules should be designed in such a way that they hide design decisions from the other modules.
The problem I have with Parnas' is that, at the point in time when you decompose the system, you probably don't really know what kind of design changes will need to be made to the system. You cannot predict the future. I think it follows that we should usually decompose "just in time", i.e. keep the system in one module at first and only when you are about to make a set of changes, decompose the system in a way that makes it as easy as possible to perform the set of changes. A change may also be organizational: if you want to split your team into two, split the artifact that your team is working on into two _first_, while you are still one team.