At the start of 2026, one of my goals is to read roughly one technical book per month. Continuous learning is one of the most effective ways to grow as a developer. Even if the rate of growth is only 1% per day, this consistency compounds over time.

I decided to start my reading list with the classic, The Pragmatic Programmer by David Thomas and Andrew Hunt.

The Pragmatic Programmer is one of those rare technical books that feels timeless and influences the way that you approach all software development, regardless of the language, framework, or environment you are working in.

One of the core ideas of the book is that good design is easier to change than bad design. That at the heart of all good design, the underlying goal is to make your code Easier to Change (ETC).

I’ve reflected on this idea a lot while reading through the remainder of the book. I’m taking this principle to all of my current projects and finding it incredibly effective at improving my design decisions.

As I think through what constitutes good design in software, another principle has been forming in my mind. And that principle is:

In addition to being easier to change, well-designed software should be easier to understand.

One of the tests of a well-designed application or library is how easy it is to understand later, after you’ve moved on and haven’t looked at it for weeks or even months. Even more critically, when someone else has inherited your code and needs to make sense of it quickly.

If you must spend a painful amount of time just remembering why you made the decisions you did, where to find core modules, and how to make basic changes without breaking existing functionality, I would argue that the software is not well-designed.

I think it’s worth mentioning that there are varying degrees of complexity across projects, and some software will naturally be more complex and difficult to understand. So this is a general and relative guideline.

I think it’s also worth noting that while comments are helpful at explaining design decisions, the goal should be self-documenting code. Use comments to explain why you made the choices that you made, but when it comes to what a method or function does, make sure that the code can speak for itself.

Overuse of comments and Markdown files can quickly violate another principle of The Pragmatic Programmer, which is Don’t Repeat Yourself (DRY). If your project is riddled with too much documentation, you risk needing to update a lot just to make a simple change. And things can quickly become outdated.

Ultimately, I think that Easier to Change and Easier to Understand are principles that go hand in hand. Code that is easier to change is naturally easier to understand. And code that is easier to understand will naturally be easier to change.