One of the secrets of writing that I’ve come to appreciate over the years is knowing what to leave out. This starts with deciding what topics are in-scope versus out-of-scope, and then for the selected scope, knowing what’s important to say and what can go unstated. The best (and most entertaining) discussion of this topic I’ve come across is John McPhee’s Draft No. 4: On the Writing Process, a book that helped me appreciate how much of my job as a CS Professor was spent practicing (as a researcher) and teaching (as an advisor) Creative Nonfiction.
Great post, as always.
I believe that deciding what to leave out from a system design is also what enables innovation. For example, many orchestration systems (e.g. Kubernetes) do not manage the storage and networking directly. They rather define abstraction interfaces (e.g. CNI for networking) and they provide the opportunity to other projects to innovate. Omission here naturally led to the system to be open to extensions.
When I design or code, I always recall this simple quote from Antoine de Saint-Exupery:
"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away"
Great writeup. In my periodic forays into tech writing, I often find a dearth of or a complete absence of diagrams. They enhance concept understanding and decomplexify topics for new and returning readers. My complements on the frequent use of diagrams in your Edge Cloud Operations book. It makes for a more enjoyable and productive read.