If you’re a developer who wants evergreen guidance instead of the flavor‑of‑the‑month framework book, start here.

“The best way to predict the future is to create it.”
— Abraham Lincoln.

I believe most skills are acquired through hard work and discipline. And that successful people have a track record of applying these.
To become a better version of yourself, you must find room to grow and fill it. By learning, by trying, by deciding to no longer tolerate your limitations.

One guaranteed way to learn and grow is by studying the great books from a certain domain. I’ve compiled a top list of Software Development books, books that were simply transformational. When it comes to learning, I prefer a proven track, so I mostly focus on timeless classics instead of following trends and the most recent publications. These are mostly books that offer depth, explaining ideas, concepts, paradigms, techniques, patterns. Most of them are platform and language agnostic, so they are applicable to Software development in general.

Disclaimer: I recommend studying these books, and learning from them, not just reading. This means reading more than once, taking notes, trying out the concepts in real life, trying to link the new knowledge to the one you already have (to make learning effective).

Format: I tried summarizing the book in one paragraph, define the book’s impact on me and listing my main takeaways.

Dependency Injection in .NET by Mark Seeman

This book offers a thorough explanation of how to decouple software components by injecting their dependencies at runtime, enabling more flexible, testable, and maintainable code in applications.

For me, it has transformed the way I design and code apps, deeply understanding layering and dependencies, modularizing (based on the requirements), but also having a proven mechanism (Composition Root) to compose modules into different apps or flavors of the same app.

Takeaways:

• Manual DI: Constructor, Property or Method Injection.
• Constructor Injection is the safest option in compiler-based languages, as the compiler won’t allow constructing an object unless its dependencies are provided.
• Service Locator anti-pattern - widely used pattern which leads to high-coupling and can generate runtime errors when dependencies are missing.
• Choosing between Manual DI vs DI containers (the later should not be used in all app layers, but rather in the Composition Root only).
• Modularity and how to compose an app using modules and a Composition Root.
• Composition Root pattern = the lowest level and most concrete component, the app entry point.
• How to implement Cross-Cutting concerns with the Decorator pattern.

Working Effectively with Legacy Code by Michael Feathers

If you’re a developer, you work with legacy code. This book highlights the high value of existing, functioning code and shows how to make small adjustments to make it testable and unlock refactoring.

This book transformed the way I look at code, especially legacy code. From running away from legacy code and being intimidated by such challenges, it flipped the narrative and allowed me to see all the opportunities to improve that already functioning code, following these battle-proven techniques and patterns. Having these skills makes me stand out as an engineer.

Takeaways:

• Legacy code = code without tests or with an unclear structure, regardless of age.
• Use the recipes in the book to make small safe changes that enable testability.
• Seam = place where you can alter behavior without modifying existing code directly - essential for introducing tests and making controlled changes.
• Write Characterization Tests for legacy code which enable safe refactorings.
• Sprout Method / Class - instead of modifying an existing method or class, you “sprout” a new one that safely holds new functionality.
• Wrap Method / Class: Wrapper around existing entity to intercept or adjust behavior without changing the original one.
• Breaking Dependencies - see techniques for dealing with problematic dependencies (like singletons, static methods, or global variables) so that you can isolate and test the units in question. Often involves introducing interfaces or employing DI.
• Extract and Override Call: Move direct dependency call (e.g., to a difficult API) into separate method that you can override in a subclass, avoiding the real dependency in tests.
• Extract Interface: Split an existing class into an interface and an implementation; the interface can then be mocked or substituted as needed.
• Parameterize Constructor or Method: Let the constructor / method accept external dependencies (instead of hard-coding them).
• Pull Up / Push Down Feature: Move a field or method from derived classes into a base class when it is shared logic; move the other way to isolate specialized behavior.
• Extract Method: Pull out piece of logic from a larger method into a separate one.

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

This book emphasizes structuring and implementing software around a deep understanding of the business domain, using a Ubiquitous Language and well-defined boundaries to create models that reflect real-world complexity effectively.

This book is incredibly deep, with very subtle but powerful concepts and examples. It made me push for a unified language between all the stakeholders involved in Software Development. And it enhanced the awareness I keep on the domain model and its separation from other layers.

Takeaways:

• Focus on the Core Domain: Invest time and resources in the core domain (business strategic advantage) and model it with precision and clarity.
• Iterative Model Refinement: Continuously refine the model as new insights emerge, using ongoing collaboration and domain exploration to keep it aligned with real-world needs.
• Align Design and Implementation: Ensure that code structure reflects the domain model and that the model is kept in sync with the code - refactor the code to keep up.
• Ubiquitous Language
  • A shared language between domain experts and developers.
  • Ensures everyone speaks consistently about the model, preventing misunderstandings.
• Bounded Context
  • A boundary within which a particular domain model applies.
  • Helps avoid confusion due to overlapping or duplicated concepts across different parts of the system.
• Associations
• Entities, Value Objects, Aggregates, Services
• Repositories, Factories, Domain Events
• Anti-Corruption Layer
• CQS at domain model level

Refactoring: Improving the Design of Existing Code by Martin Fowler

Refactoring is not rewriting; it’s a methodical process of cleaning up code with recipe-like steps. Think of this as the classic “recipe book” for refactoring.

I use it regularly, especially given the IDE I mostly use (Xcode) has very limited automated refactoring capabilities. The most transformative concept for me was deeply understand what refactoring is and trying to refactor as much as possible ever since - of course, by preserving the code behavior.

As Kent Beck explained it, a developer can wear multiple hats, only one at a time. Changing functionality is done under a different hat than refactoring. Making this separation I believe to be making your output so much clearer.

Takeaways:

• Incremental Improvements: effective refactoring happens in small, safe steps:
  • make one change at a time
  • run tests
  • and proceed only if the system remains stable.
• Code Smells indicate where to refactor - e.g. Long Method, Large Class, Primitive Obsession, Switch Statements, Divergent Change, Shotgun Surgery.
• Automated Testing Is Essential: Having robust unit and integration tests enables you to refactor with confidence.
• Refactoring Preserves Behavior: The goal is to change the structure, not the functionality; if system behavior changes, that’s not a pure refactoring.
• Refactoring Improves Maintainability: Well-structured code is easier to understand, modify, and extend, ultimately saving time and effort in the long run.
• Composition Over Inheritance: Wherever appropriate, prefer using composition to extend functionality rather than complex class hierarchies; this often reduces coupling.
• Encapsulate What Varies: Identify aspects of the code that might change or expand over time and encapsulate them (e.g., through design patterns like Strategy or Decorator).
• Replace Conditionals with Polymorphism: Frequent if / else or switch statements can often be replaced with polymorphic classes or methods to simplify control flow and make code more extensible.
• Naming Matters: Consistent and meaningful names for variables, methods, and classes help communicate intent and maintain clarity.
• Continuous Refactoring Culture: Treat refactoring as an ongoing, integral part of development rather than a one-time event—this keeps code healthy over its entire lifespan.

Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin

Clean Code emphasizes writing readable, maintainable, and elegant code by following core principles, best practices, and disciplined craftsmanship that leads to higher-quality software.

Reading Clean Code and Clean Coder was the point in time where I stopped being a “hacker” (in the sense of hacking things together so they work) and moved towards being a professional developer, that follows standards, metrics, rules, that takes pride of their work. In my case, it was an identity transformation.

Takeaways:

• SOLID principles: applying all the 5 principles is fundamental to writing maintainable, readable, testable code.
• Readability Is Key: Code should be optimized for human comprehension first, ensuring that anyone can easily understand and modify it in the future.
• Small, Focused Functions and Classes: Methods and classes should do exactly one thing and do it well, which keeps the codebase modular, testable, and easier to maintain.
• Meaningful Names: Clear, descriptive naming for variables, functions, and classes significantly reduces confusion and improves overall readability.
• Continuous Refactoring: Regularly improving existing code keeps it clean and up to date, preventing “code rot” and complexity from creeping in over time.
• Emphasis on Testing: Testing (often through TDD) helps catch issues early and ensures the code’s design stays simple, robust, and reliable.
• Error Handling: Handle errors gracefully and clearly. Use exceptions for exceptional conditions and provide context in error messages.
• Code comments: Favor self-explanatory code over excessive comments. Use comments sparingly to clarify complex logic rather than to explain poorly written code.
• Comments show our inability to express ourselves through code.
• Formatting and Consistency: Follow consistent formatting rules to help others (and your future self) navigate the code easily.
• Boy Scout Rule: Leave the camp cleaner than you found it.

The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin

The Clean Coder emphasizes the ethics, mindset, and practices that distinguish professional programmers, focusing on responsibility, discipline, and clear communication to produce high-quality software.

Takeaways:

• Professionalism as a programmer, Standards and Accountability
• Clear communication and Boundaries
• Discipline in Coding Practices: TDD, Refactoring, CI
• Handling timelines, pressure, estimations
• Continuous Learning and Improvement

Clean Architecture: A Craftsman’s Guide to Software Structure and Design by Robert C. Martin

Clean Architecture describes principles and design practices for creating software systems that are resilient to changing requirements, easily testable, and maintainable over their entire lifecycle.

Takeaways:

• Separation of concerns
• SOLID Principles in detail, at the method, class and module levels.
• Entities
• Business rules
• Usecases
• Frameworks and drivers
• Layers and Boundaries
• Plug-in Architecture

iOS Unit Testing by Example: XCTest Tips and Techniques Using Swift by Jon Reid

This is a practical guide to writing maintainable and robust iOS applications through effective unit testing and test-driven development (TDD) principles, focusing on both Swift and Objective-C codebases.

Automated testing is such a complex domain and it requires so many other skills to be put to practice. More so TDD. It’s one thing to write some unit tests and another to choose between numerous types of tests, write clean concise tests, that exercise the behavior of the code and not its structure so that one can later refactor that code without breaking the tests. With the help of this book and the iOS Lead Essentials program by Caio and Mike, I was able to take my testing skills to the next level. I became proficient with testing, capable of thinking strategically about testing strategies and their implementation using various types of tests.

Takeaways:

• TDD encourages Clean Code
• Clear test structure improves readability: use patterns like Arrange-Act-Assert (AAA) and give tests descriptive names
• Using test doubles are essential skills: mocks, stubs, fakes
• Continuous testing boosts confidence: run these locally, while you develop, after every change. Also run them as part of the CI pipelines
• Well-written, high-coverage tests serve as a safety net for refactoring, encouraging developers to improve design without fear of breaking existing functionality.

The Pragmatic Programmer: Your Journey To Mastery by Andrew Hunt and David Thomas

The Pragmatic Programmer provides practical guidance and a mindset for software developers to continually refine their craft, create robust solutions, and take ownership of all aspects of their code.

This book may seem trivial in some ways, but it has a subtle intelligence to it. It highlights an art of being balanced, pragmatic, of choosing wisely between quick and dirty and clean elaborate solutions. It highlights the need to be focused so you can choose from all the tools at your disposal. And it does a great job at showcasing many of these tools that were here many years ago when it was first published.

Takeaways:

• Embrace continuous learning.
• Adopt a pragmatic mindset over dogmatic rules.
• Focus on clean design and DRY: minimize duplication, promote reusable components, and favor simplicity to reduce complexity.
• Take ownership and responsibility: Take pride in your work, own the quality of your code, and be proactive in identifying and fixing potential problems or misunderstandings.
• Refactor early and often.
• Orthogonality and decoupling: Strive for independent components whose functionality does not overlap, making your system more adaptable, maintainable, and testable.
• Tracer Bullets: Implement thin, end-to-end solutions to test architecture and feasibility early, guiding further development through continuous feedback.
• Prototyping: Build quick, disposable implementations to explore ideas, verify assumptions, or confirm feasibility without committing to production-quality code right away.
• Design by Contract: Define clear, enforceable contracts for functions, modules, or services (preconditions, postconditions, and invariants) to ensure correct behavior.
• Automation: Invest in tools that automate repetitive or error-prone tasks (testing, builds, deployment) so you can focus on high-value work.
• Coding Conventions and Standards: Maintain consistent naming, formatting, and architectural decisions to improve team collaboration and readability.
• Collaboration and Communication: Write clear documentation, engage in effective code reviews, and communicate openly with team members to address issues early and improve collective knowledge.

Extreme Programming Explained: Embrace Change by Kent Beck

Consider this the field manual on Extreme Programming (XP) and Test Driven Development (TDD). XP is a lightweight, people-centric methodology that emphasizes rapid feedback, short development cycles, close collaboration, and continuous improvement to deliver high-quality software in the face of changing requirements.

Takeaways:

• Core XP Values: Communication, Simplicity, Feedback, Courage, Respect.
• TDD: Writing automated tests before coding to guide design and validate functionality. Uses a Red - Green - Refactor cycle.
• Pair Programming: Two or more developers share one workstation, continuously reviewing and improving each other’s work. Produces quality design, less defects, reduces need to use the classical code review workflow.
• Continuous Integration: Frequent merging of code changes to identify integration problems early.
• Refactoring: Systematic improvement of code structure without altering functionality.
• Simple Design: Always aim for the simplest system that works, deferring complexity until necessary.
• On-Site Customer: Having a real customer or representative available for immediate feedback and clarification.
• Collective Code Ownership: Any team member can modify any part of the code at any time.
• Whole Team: All roles (developers, testers, domain experts) collaborate continuously.
• Sustainable Pace: Avoid burnout by maintaining a healthy, consistent work pace.

Feedback

What are the books that have changed the way you work, the way you think? What’s your favorite learning from them?

What book from this list are you planning to read next? Why?

Let me know in the comments section. I’d be happy do discuss and learn from you too.

Tags: books

---

💬 Comments

Post comment using GitHub

Loading...