What This Book Is Not

Receiving advice — especially advice about how to do our jobs, i.e. the work that sustains our existence — can feel like a threat. I know it does to me. Whenever I encounter a new expert opinion on software development, the hairs on my neck bristle as I brace myself to read it. Are they going to say I'm doing it wrong?

Therefore, I want to start by saying:

If you are shipping working code, you are not doing it wrong.

• Something you're doing is working.
• Your feelings about your work are valid.
• The things you'd like to improve about your work are worth improving, and maybe this book can help you with that.
• What I really want is for you to feel confident and satisfied writing great software. If something in this book doesn't help you do that, don't do it.

This book presents many ideas that are somewhat hyped-up and controversial: FunctionalProgramming, ObjectOrientedProgramming, TestDrivenDevelopment, and AlgebraicTypes, to name a few. However, I am not going to argue strenuously for any particular practice. Instead, I hope to show you how all these seemingly disparate pieces fit together into a kaleidoscopic yet coherent whole.

This unification seems to me to be long overdue. The more I read and listen to software development experts of the last 60-ish years, the more I am impressed by the deep similarities between their superficially different approaches. My goal with this book is not to present yet another theory of software development, but to show you how the good ideas already out there might, ultimately, just be different facets of what we knew all along.