j ’s list is all about very well known ones, that you should consider putting in your list.
One I’d like to add is John Ousterhout’s «Philosophy of Software Design», which I read last year and was the best programming book I read in years (and I read a lot): The are some code snippets here and there, to serve as examples, but it’s really focused on the ideas, the concepts and the way we think.... I believe it’s a great one both for junior and senior developers (I wish I read it years ago, but it was written quite recently) The main focus on the book is about the core principles and idea to let you manage and control complexity in your programs, to make them more efficient, more maintainable (i.e. better software). And I Love it because it’s also pragmatic, and often recognize than any principle or good idea have exceptions, and you should use them to guide your thoughts, but not always use them without thinking of the current problem.
Other the last months I started to recommend it very often, and just yesterday I had a great "ah!" moment: a coworker asked for advice about the design of a new endpoint, which is not transactional and involves a few dependencies, and he was concerned about how to deal with failures and potentially inconsistent states. Having both read that book, the discussion was really quick as I started to ask if he could change the semantics of the endpoint to not be an action but rather a request to reach a state, which would let him "define errors out of existence". As soon as mentioned this - which is one of the principles from the book - I saw I hadn’t anything more to say and he remembers the core idea and had made a decision. A few hours later, a beautiful pull-request was opened ;-) This little story is there just to show how useful it is to know good design principles (again, j list will go a long way there!) but also to share those common principles with the teammates, because it can be used as a common foundation for many discussions and decisions.