I read a lot of technical books that improve a specific skill and then sit on the shelf as reference. Every so often one rearranges the furniture in your head instead, and you find yourself using it on things that have nothing to do with the book's nominal subject. For me, lately, that book is Donella Meadows' Thinking in Systems. It's not about software. It's about feedback loops, stocks and flows, and why systems do the surprising things they do. I have not stopped seeing it everywhere since.
stocks, flows, and why dashboards lie
The idea that's stuck hardest is the distinction between a stock and a flow. A stock is the amount of something at a moment: the number of items in a queue, the disk space used, the open connections. A flow is the rate it changes. We instrument flows obsessively, requests per second, errors per second, and then act surprised when a slowly filling stock tips over. The queue length creeping up is a stock problem. The disk slowly filling is a stock problem. The flow looked fine right up until the stock hit the ceiling.
the loops you didn't draw
The other thing that's lodged itself is reinforcing versus balancing loops. A retry storm is a reinforcing loop: failures cause retries, retries cause load, load causes more failures. Left alone it runs away from you. A circuit breaker is a balancing loop deliberately bolted on to stop the runaway. Once you start labelling the loops in an incident, the post-mortem writes itself. You stop asking "what broke" and start asking "which loop wasn't there, or fired in the wrong direction".
Meadows also has this lovely, humbling point about leverage points: the places you push on a system to change its behaviour. The ones people reach for first, tweaking a number, a timeout, a threshold, are usually the weakest. The strong ones are further up: the structure of the feedback, the goals of the system, the rules. It explains why so much firefighting feels like effort without progress. We're shoving on the low-leverage end of the lever.
I'm wary of books that promise a new lens on everything, because most of them are selling something. This one isn't, and it's better for it. It hasn't made me write different code this week. It's made me ask different questions about the code, which turns out to matter more. If you spend your days watching systems do unexpected things, and most of us do, it's a quiet, short, genuinely brilliant read. Mine now has coffee rings on it, which is the highest compliment I have to give a book.