I've been thinking about the third and last book lately, much more than I wanted to. I find that as ideas gestate, once the appropriate pieces are in place and "baked in" to my other experiences? They gotta be born, whether I want them to or not.
Just to catch you up, all of the books are about managing conversations around complex technical topics. Book 1 was about "Building the Right Thing", conversations you have with others to make sure you're headed the right way as you start and continue coding. Book 2 was about "Building Things Right", conversations you have with the technology itself as you actually work on the product. Book 3 is going to be about "Building Things That Build", conversations you have with yourself, or learning at scale. It's about how to build architectures and infrastructures that learn, whether it's AI or a multinational organization.
All three books use the same underlying metaphysical model, building on each other as we go along. Things you learn in Book 1 will be useful for Book 3, and vice-versa. It's the same stuff, only applied in different contexts. We've got coding, we've got computer languages, we've got analysis, we've got Agile, we've got scaling startups. The model drives all of it.
A key concept introduced in the first book is that of the "Three Buckets". There are three, and only three buckets of things you talk about when trying to build the right thing: behavior, structure, and supplementals. Behavior what you want people or the system to do. Structure is how pieces of things relate to one another. Supplementals are the rules that always apply no matter what your structure or behavior is.
Behavior might be a iOS app. Structure might be the code you used to build it. Supplementals could be your coding standards and standards of the Apple App Store. Or, behavior might be your daily standup and other rituals, structure could be your team and org chart, supplementals could be your team working agreement. There are billions of things you can plug into the model, but in the end they all come down to the same three buckets. It's impossible to step outside the buckets, and we can pull a tremendous amount of value out of understanding them and how they relate to one another. For instance, Structure Should Always Be Derivative. That is, whatever you desire a system to do (or it is currently doing), combined with the supplementals in place, force the structure to exist. Every piece of code you type is the result of behavior and supplementals forcing out structure, even if all of that only happens in your head. (It becomes much more interesting when it gets outside of your head, however).
Building the right thing, the topic of book 1, turns out to be a lot about structure. What's this thing going to be, anyway? Whether it's a domain model, UX chart, or database design, a big part of building the right thing is figuring out what structure is going to work and what isn't. Building things right, the topic of book 2, turns out to be a lot about behavior. How do I interact with the code I'm writing? Do I write tests first? What sorts of structure and supplementals support the code/technology/etc I'm building? Whereas book 1 is about the structure your target system is forced to have, book 2 is about the behaviors you're forced to implement to get there. You could say book 1 is people, book 2 is tech.
Which leads us to book 3, "Learning at Scale". Out of our three buckets, we're obviously left with supplementals, the rules that validate chains of behavior and structure. Creating rules that always apply given the correct context is the basis of all learning, whether it's a plant reaching for the sun or a recommendation AI following a series of observations with a best-guess at what you should do next. Book 3, at its heart, I think will be about chains, whether Markov-like chains inside an AI somewhere or best-practices for large program development, like building a new missile system. Chains are how we think about learning and chains are how we learn, whether we realize we're doing it or not.
This book series to me has been like writing an especially good computer program: you start with some good ideas and kick them around, finding a really cool place you want to go. Then, over time, you develop these ideas into tech making sure there are no ambiguities (that you can see), and that you've got the edge cases covered. Finally, as you cross-over the complexity curve, the final solution "comes into focus", most of the time in a way you had never anticipated when you began. At some point, if you're doing a good job, the solution pulls you along with it, becoming a thing of its own. You've spent the appropriate amount of time in the kitchen, coming all the proper ingredients. Then you waited, put some heat on everything. The cookies are ready.
When you're done, you may not have anything of value to others, or anything that's going to stand the test of time, but gol-dang it, you've got some new thing, this creation that exists on its own. It helped you, and now it can go forward to perhaps find other people to help. That's pretty cool.
It saddens me that there are so many developers who have not experienced both the frustration and joy of that journey, who are stuck in boring, soul-sucking jobs that over time destroy their humanity and hope. We can do better than that. We have to do better than that. Our friends deserve it. The future deserves it.