How to Use This Book

Real talk: there's only so much you can learn by reading a book.

Much of what I know of technique is muscle memory—habit built through repetition. It takes time and practice to learn that, and reading a book is not going to make it happen.

Likewise, the mental models of software I've built from various views are unserializable, untransmittable. I can't dump them out of my brain and load them into yours.

What I can do is offer you a navigational toolkit: a map and a compass to help you find your way. I can give you the basic instructions for techniques. I can tell you where to stand to see a particular view of your system.

But you have to do the work of learning. You have to practice. You have to write code (lots of it). You have to reflect on what you write. You have to seek feedback from other people. And you have to read other people's code, make sense of it, and evaluate what's good and bad about it.

Ultimately, you have to assess whether the views and techniques in this book are applicable to you and your situation or not.

Refer to this book as you would to a map. A map can't tell you everything about the terrain you're going to travel through, nor can it prepare you for everything you might encounter on the journey. But it can help you orient yourself—that is, figure out where you are and where you might go next.

As you travel through the landscape of software development, I hope this book inspires "aha!" moments of sudden recognition. So that's what Ben was talking about. When you have a moment like that, you'll know you really get it. You've grokked it.

The insights behind these "aha" moments are something you'll gain throughout your career whether or not you read this book. But the book will help you recognize them for what they are and make the most of them.