API by Design. This book is focused on REST APIs and introduces ways to measure complexity and some techniques to tame complexity. If you’ve ever worked on a REST API adversely impacted your WTFs/minute, this is a good book to consider.
What I liked: introducing new ways to communicate complexity, like Reference Entanglement (APIs with excessive references or arbitrary counts of nested resources). I also liked the section that quantified complexity based on optional parameters.
What I didn’t like: I wanted more examples! The book set the table for taming complexity in greenfield designs: I would have enjoyed more examples.
(Note: I know the author, Stephen Mizell, and my review is based on early access content.)
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. I feel like Accelerate was an OK book. I picked this book up after seeing it recommended from Charity’s blog. I was hopeful for some mind blowing content, but it mostly provided confirmation of some truths I’ve encountered in industry a decade ago.
What I liked: Research-backed conclusions about engineering methodologies. The book provides a reader some vocabulary, techniques, research, and links to business outcomes. If delivering software feels Sisyphean for you or your team, this book can better equip you to try and ameliorate that situation.
What I didn’t like: All of the exhaustive research methodology details. Yes, this matters, especially when making new claims. I did not feel like this fit into the book’s subtitle of “building and scaling high performing technology organizations”.
Overall: There are valid criticisms of the actual research methodologies of the DORA report, which powers a fair amount of the book. Your mileage may vary!
Software Engineering at Google: Lessons Learned from Programming Over Time. I feel like this book gets less fanfare than the Google SRE books but it’s just as valuable. Like Google’s SRE books, this book has a mixture of useful information, wonderful explanations, and Google-flavored navel gazing.
What I liked: the first 16 chapters or so had me really engaged. I especially enjoyed the author’s clear definition of software engineering vs. programming/coding. Chapter 7 was very insightful about how a data driven process to measure engineering productivity.
What I didn’t like: the usual kool-aid you get from publications written by very large companies. While the authors admit that Google’s methods aren’t applicable everywhere (and not universally applied within Google), a lot of it felt particularly impractical especially in contrast to the earlier parts of the book.
Some days I feel that I’ve returned to my old DBA role, well… sort of. A lot of my day to day work revolves around a vast amount of data and applications for data storage and retrieval. I haven’t been a DBA by trade since 2011, nearly an eternity in the tech industry.
To me, Designing Data-Intensive Applications was a wonderful survey of “What’s changed?” as well as “What’s still useful?” regarding all things data. I found Designing had practical, implementable material, especially around newer document databases.
This book is a good balance of theory and practice. I particularly enjoyed the breakdown of concurrency related problems and adding concrete names to classes of issues I’ve seen in practice (e.g., phantom reads, dirty reads, etc).
The section about distributed systems theory was well done but it was a definite lull in the rest of the book’s flow.
The book’s last section and last chapter were both strong. I would recommend this book to all of my colleagues.