To write better code and build better products, we must understand why engineering and design often fail. Why is it so difficult to write bug-free code? Why do people fail to use products? And why do engineering projects so often go sideways?
The answer to these questions lies in the shortcomings of human cognition and the nature of complexity. This book explores these topics and presents a human-centric approach to software engineering. An approach that considers and compensates for our cognitive biases, cognitive weaknesses, and the chaotic nature of the universe. An approach that teaches how to balance concerns, defend against entropy, take precautions, reduce complexity, and deal with our cognitive shortcomings.
The ideas presented will help you write better code, design better products, and be a more effective engineer.
This book is the first part of a two-book series. This book focuses on theory and contains almost no code, while Book II is more technical and uses code examples and case studies to demonstrate how to apply the theory.
As a software engineer I put significant time and effort to make the code friendly to human readers (future me included). Eliminating branches has worked wonders for me. Here the author has backed up such simplifying tips (or choosing good names) with human limitations like limited working memory (chunking in memory), cognitive biases. That's refreshing. The sharp contrast between how a machine sees code and how humans must see code to understand and reason helps make the point "Code is for humans". The overall philosophy of being a mensch is good as well.
While the book reads well in the beginning and in the end, it might use some organization and connecting thread in the middle to make it more seamless.
Jackson's (author's) law states that bad design and engineering cause more harm than you expect even when Jackson's law is accounted for. One way to put the law in action would be to always multiply estimated cost of taking shortcuts in design and engineering by say 1.5. It would have been better if at various points when Jackson's law is referenced, to show how expectation + Jackson's law failed to measure the actual cost and how one would go about estimating more effectively in the light of Jackson's law.
I look forward to reading the second volume when it's out.
This is a really small book. But full of good ideas and thoughts. The author starts with a simple idea: how engineer's decisions affect others, not just other engineers but also users and potentially much more. Why it's crucial to invest in good things and design. Design interfaces and how things are working carefully, thinking about second-order events and really adding value. Why it's important to write code and build things for users and not just because you are smart or it's fun. And, in the end, why investing in the right things is a must. I fully agree with most of the ideas and find them provoking and, hmmm, common sense. I also see how badly some things are designed. And this reminds me of another book: Design of everyday things. But in this case, it's more about engineering and how it affects everything else. Recommend to read. Waiting for second book
I had hopes for this book. I love human centered design. I thought it would be a beautiful fusion of UX and the art of writing code.
But. This book is simply bad. Poorly written. Hard to read. Terribly condescending. If you’ve ever read Uncle Bob or Kent Beck — these dinosaurs of programming sound humble, open-minded, curious. Meanwhile, this book is saying: “you are all blind dummies, but lucky you — here’s My Book full of great revelations”. Died from cringe. Not recommended.
Upd: increasing the rating to 2* just for the mentions of some good principles (yagni, 80/20 etc) here and there.
Self-published pile of mumbling about design of urinals(?), being a “mensh”, cost graphs without any data backing them up (source: trust me, bro). The beginning about managing complexity was promising, but after that it went downhill.