I read Good Code, Bad Code.
This book shows the difference between good and bad code in concrete terms, through abstraction, modularity, error handling, and testing. It turns code quality, which we often wave away as "seems fine," into criteria you can actually judge against.
The guidance especially stands out: make contracts explicit, prepare for unexpected input, and stay aware of how easily code invites reuse or misuse. You can apply this guidance directly in daily reviews.
It backs up the sense I picked up over the years with words and principles, and it works well as a shared vocabulary when I explain things to junior engineers.
