Books or other good content on software design?

Sampling of the popular books we have floating around the office are:

• The Pragmatic Programmer - you might hear you don't need it today because it explains blatantly obvious concepts that would make eyes roll, but when it's a case of "you don't know what you don't know" the book can help shore up any gaps. It's also an easy read, more like a self-help book for programmers than a clinical CS course in software architecture.
• Designing Data-Intensive Applications - I'd consider this a must have read even for ops/sysadmins if you want to know how a system properly scales beyond a few servers. Making more stateless frontends is easy (and even automated with things like Kubernetes), but the data is often the bottleneck and how you handle that data is a huge part of how scalable and reliable the entire system can become.

For quick reads I've learned and referenced a lot of concepts from Martin Fowler's blog.

I have three suggestions off the top of my head:

• Patterns of Enterprise Application Architecture
• Design Patterns: Elements of Re-usable Object Oriented Software
• Working Effectively with Legacy Code

While the last one is really about testing, it can give a good insight into how you can bootstrap your project with good testing practices (by teaching you how to shoehorn testing Harnesses into legacy code). The first two are classic compsci books that I read later in my career because I didn't go to school for Computer Science and they really helped explain a lot of the architecture and patterns I have seen around throughout my years.

As a bonus, there is also Domain Driven Design. This one focuses a lot on thinking about the business problem you are trying to solve.

I also recommend Design Patterns. It's pretty old now, though. Some of the design patterns might be outdated or inapplicable in newer languages. Game Programming Patterns might be interesting if you want to know what people use in games.

When people read about design patterns, they tend to overuse them at first to try them out, but after a while you get a better sense of when they're necessary and a simpler solution won't do.

A caveat: just because it seems effortless doesn't mean it is. Often, when people write up what they did, they don't share anything about their mistakes and the blind alleys they went down. Other times, if it seems easy, it because they're implementing a variation on a design they've used before, or at least read about before.

If you want something that is more process oriented, Better Embedded System Software is a good one. Even if you are not writing embedded software, most of the process lessons should still apply.