Process to Processes: The Preface
What? Who? How?
Hello! You’re reading Ben’s Guide to Software Development, the weekly bulletin where I post excerpts from drafts of my upcoming book, Process to Processes.
The initial chapters of the book are coming together, after a couple weeks of fiddling. Below is my current draft of the preface. As always, I welcome your feedback, which you can send in reply to this email or in the comments section on substack.com.
My goal for the preface is to get readers excited about the book, to acknowledge what they bring to the table, and to set reasonable expectations. If I’m not doing those things, I hope you’ll let me know.
What This Book Is About
This book is for software developers who want to make better things in better ways.
It covers all aspects of software development, from tiny details of code all the way up to team structure, project management, and user experience design.
If you are interested in making software that is kinder, sturdier, more deeply felt, and better fit to your hand, eye, and mind, this book is for you.
If you just want to feel less stressed at work, I think you’ll also find something of value here.
This book will give you:
Better views: more realistic, useful, and humane ways of seeing the systems we inhabit.
Better techniques: ways of working that provide ease, efficiency, and control.
Generative principles that help you invent new techniques to fit your situation.
...all in service of providing mutually beneficial goods to you, your clients, your teammates, and the users of your software:
Software that does what you meant it to do,
that is satisfying to work on
and can be improved at a steady, predictable pace,
profitably,
forever.
Why “Process to Processes?”
The title of this book refers to the two kinds of process that bookend software development. On one end, we have the development process that people go through as they learn about the system, make changes, and observe the results. On the other end, we have the computational processes that run on computers—the things that are listed by the ps command on Unix systems.
This book will give you a complete picture of what happens during software development. It maps paths that lead all the way from one “process” to the other—and back again.
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.
Who Should Read This Book
Process to Processes is addressed to professional software developers with at least a year or two of experience in application development. Managers and UX designers might find parts of it interesting as well.
The code examples are mostly in JavaScript and TypeScript. However, the programming ideas in the book apply across languages. Specifically, they apply to the extent that your language supports:
An interpreter or fast, incremental compiler
Higher-order first-class functions
Mutability — e.g. variables that can be reassigned
A convenient, performant implementation of immutable data structures
Algebraic types
A sane package manager for installing dependencies
Coroutines or generator functions
Exceptions
Your language doesn’t need to have all of these features, but they all help. I have successfully applied the techniques in this book in Ruby, Java, JavaScript, TypeScript, Go, Scala, and C++. My friends tell me that Swift, Rust, Kotlin, and Elixir also work.
If you work in a language very different from any of these, proceed with caution.
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.
This preface is making me so excited to read this book. I'm a designer who dabbles in code for side projects or when submitting a PR to clean up something that's just too hard to articulate to my team in Figma (i.e. animations, design system variables, etc). I'm looking forward to improving a lot of the mental models I use to write code and I think this book might just be the one that helps "it" click.