by John Ousterhout
tl;dr;
Even for the more seasoned engineer, this book is a good reminder of design practices that needs some refreshing every once in a while. At a low cost (< $20 for a technical book), and easy to read, will provide you a pleasant read for 1-2 weeks.
For the ones beginning their careers, is a good introduction to Software Design principles that won't require deep computer science knowledge, with guidelines that will improve your output.
Overall: 7.5/10.
If you wanna buy the book, click here :)
Introduction
The book already starts defining what it wants to tackle: software complexity. The author defines complexity as "anything related to the structure of a software system that makes it hard to understand and modify the system.". From this point on, the author will go through the "complexity symptoms" and what practices software designers can apply to minimize the problem.
One of the first things I've appreciated is that the author won't take the position from the software writer; instead, it will look through the software reader's eyes. These two are different personas, separated by time, context, and knowledge. The latter requires context that is potentially implicit in the written code.
What I've liked
After setting the tone, the author will start describing his design philosophy based on his experience teaching at Stanford. These design principles are good practices, sometimes already detailed by other authors, but written in an easy-to-digest manner, even if you're a beginner in software development.
In addition to his principles, the author will describe "red flags" that you can use to identify potential problems in your approach. John was also careful enough to create a summary at the end of the book with the red flags and which pages you can find more about them. He did the same for the Design Principles he distills in the book.
Within his design philosophy, the author will also challenge the status quo defined by classic authors, especially R. Martin. This book will discuss a few things from Martin's "Clean Code" - how to write functions, modules, comments, etc. -. When I compare both, John's seems closer to our reality and more pragmatic.
What I didn't like as much
And what about what I didn't like as much? One thing that I'm not so sure whether I liked or not is that the author comes back to the same example too many times. Why don't I know if I liked it or not? When I saw it was the same example again, I would get annoyed. However, I will most likely remember the piece of code for the rest of my life.
Another thing that stuck with me was: that the author states that you shouldn't expose your internal data structures to the API consumers. I don't think we would disagree with that. However, later on, he mentions that you should not use implementations that are a mismatch from your variable interfaces. I found this piece a bit conflicting with the first statement. I can agree that you can do that for internal variables in your module. Yet, for exposed variables, I'm not so sure about it. This is what enables me to be free to do internal changes in my module without introducing breaking changes to my customers.
Simple takeaways
The author goes through many things that I find valuable for any developer. Of course, they might impact you in different ways depending on at which point you're in your career. Among those, I will list a few (summarized, of course) that I find valuable to be reminded of even if you already know:
- Complexity will always be present. It's a constant exercise to simplify code throughout a software lifecycle.
- Write deep modules with simple APIs, and design them as much as possible for common cases. Omit unimportant details.
- Do not fall under the temporal decomposition trap. Your code needs to reflect the knowledge required to perform tasks, not the execution order.
- Define errors out of existence, and make interfaces simple.
- Centralize error handling for simplicity.
- If pieces of code are related, think about whether you should bring them together
- Consistency is key for good readability. Don't start changing existing conventions without taking the effort to understand why they exist, and what value your new convention brings. Also, don't introduce yet another convention if you won't be able to remove the old one entirely.
Conclusion
In summary, this book is worth the time. Easy to understand, objective, and with small chapters that make it easy to assimilate things. For the more experienced engineer, many things could be a repetition of what you saw in other classics and already put into practice in your daily work. For you, the first chapters is where you will find the most valuable discussions.
However, there are still valuable things that you most likely can take from it. For the ones who joined this journey more recently, I would definitely recommend it. Most likely it will improve your deliverables if you pay attention to the recommendations on your daily job.
If you wanna buy the book, click here :)
