Show HN: We wrote a book about Software Mistakes and Tradeoffs

The idea of the book is to provide a list of mistakes, tradeoffs and decisions that every software engineer needs to make in their day-to-day job.

There are 13 chapters - each chapter focuses on real-world problems you may encounter in your production systems. It tries to analyze every situation in a variety of contexts and consider all its tradeoffs. It also presents some non-obvious mistakes that may significantly impact your systems from various perspectives (not only correctness).

I wrote this book together with Jon Skeet.

We have been involved in and observed many software decisions and learned what tradeoffs they impose throughout our professional careers.

Along the way, I’ve started writing a personal decision log of the circumstances where a specific decision was made. What was the context of it? What were the alternatives? How did we evaluate a particular solution, and finally, how it ends up.

Did we anticipate all possible tradeoffs of a specific solution? Or were we surprised by something? It turns out that this personal list of lesson-learned is quite generic because those problems and decisions need to be tackled by many engineers out there.

At this point, I decided that this is an excellent time to share that knowledge with the world. This is how the idea for this book was born.

If you have any input or feedback for us, it would be highly appreciated!

Book has interesting parts, but seems to be trying to cover too broad a field, offering little of the tradeoffs promised in the title.

Is is often very opinionated about a highly technical area where the answer is always 'it depends', offering little balance of opinion before rapidly moving on to the next unrelated topic.

e.g. Somewhere in a section on API versioning is the statement - "Modern services should generally be designed with no downtime required when updating the servers to a new version."

As a grizzled developer in 2021 I would disagree with that, 24/7 365 up-time is hard and expensive, if the service doesn't require it then don't do it. There is a tradeoff between developer effort supporting multiple live versions and synchronization between teams to just stop the service and update everything.

In the authors context it may be true, but the book is titled tradeoffs and all too often only offers the architecture astronauts uncosted ideal world opinion.

I've read this book, and I liked the approach a lot.

The flow of each chapter is self-contained and contains at least a couple of lessons learned. There are some low-level concepts (like chapter 3 about exceptions) but also high-level (chapter 8 about data locality).

For my context, chapters: 2,4,5,8, and 11 provided the most value.