I've been working professionally for about a year and a half, and I've designed and implemented one project largely on my own. Looking back, I can already see places where the design could have been smoother, which has made me want to learn more about building solutions that fit well into existing systems.
I'm especially interested in managing complexity, keeping responsibilities clear, reducing unnecessary coupling, and deciding when abstractions or customization are actually worthwhile. I'm less interested in books focused on a particular programming language and more interested in general system and software design.
I've seen Designing Data-Intensive Applications recommended, but I'm concerned that it may focus on large-scale distributed systems and encourage me to overengineer problems I don't yet encounter. What would be a good starting point for someone at my experience level?
3 Answers
Focus on principles before memorizing architectures or patterns. Learn about cohesion, coupling, separation of concerns, dependency inversion, composition versus inheritance, and keeping responsibilities clear. Then apply those ideas to code you've already written.
A Philosophy of Software Design, The Pragmatic Programmer, and Refactoring would be a strong reading list. Also, don't assume that good design means making everything highly customizable and decoupled. Abstractions have a cost, and a simpler solution can be better when the requirements don't justify another layer.
Structure and Interpretation of Computer Programs is a worthwhile classic if you want to strengthen your general programming and problem-solving foundations. It is more theoretical than the other recommendations, so I would treat it as an optional longer-term read rather than the most direct guide to working in an existing production system.
I'd start with A Philosophy of Software Design by John Ousterhout. It focuses on managing complexity, designing clear boundaries, and making practical tradeoffs rather than teaching a specific architecture. Working Effectively with Legacy Code by Michael Feathers is also excellent for making changes safely in systems you didn't design, while Refactoring by Martin Fowler works well as a reference when you recognize problems in an existing codebase. Tidy First? by Kent Beck is another short, practical option for deciding when to clean up before making a change.
Your instinct about Designing Data-Intensive Applications is reasonable. It's valuable, but it covers a different scale of problems and probably doesn't need to be your first design book.
That makes sense. I especially like the idea of comparing the principles against my own project instead of trying to apply patterns automatically. Thanks for the detailed suggestions.