How to make good programming decisions?

Recently I read a great book - "Software Mistakes and Tradeoffs: How to make good programming decisions" by Tomasz Lelek and Jon Skeet. 

I like the idea, the structure, and all the suggestions the authors shared with us. 

The book describes various problems we may face during daily work, how to tackle them, and how to decide which solution brings us the most benefits.

From small to enormous challenges

The book is a journey through various challenges. We start with code-related issues. We look at them to learn their impact on the current implementation and future maintenance. We get to know the harm they bring to the code. 

Then we move to the higher level of abstraction, to face difficulties with APIs and libraries, with the boundaries of our components. And this is still not the end. 

We continue our journey to learn about the challenges that come with distributed systems, consistency, versioning, and more.

Each challenge is described carefully to give a good understanding of the subject so we know why the presented implementation is a problem. The authors advise possible solutions to make the issue less damaging. They go through the pros and cons of each choice and explain the tradeoffs that come with them. 

It makes us aware the journey comes with a price. There is always a decision to make, and unfortunately, rarely the best option exists.

For everyone

Topics in the book are about the code and the component's design, the readability, and the high-level integration, changes on the method level, and changes to the system. The number of covered topics makes this book relevant for developers and architects, for those who start their careers, and for those with experience.

Regardless of the topic, the book demonstrates what the decision-making process should look like. We learn what should be taken into consideration and what level of detail is relevant in the given context. I think this is one of the most priceless lessons.

Examples

Whatever the subject and level of abstraction are, authors share a lot of practical examples we can explore. We can examine them and see what changes when the just-explained option gets implemented. We can compare choices and their tradeoffs, and decide which one we can or cannot accept. 

Explaining the topic without well-written examples left us with the theory only. Nothing is as precise for an engineer as the code you can look at. And this level of clarity is what authors serve us.

Testing

Years ago, I wrote that the main method should not be your test strategy - we should use tests to prove the problem exists or to validate the solution. I believe authors have similar opinions because you can find dozens of tests in the book - most of the issues and solutions are covered by test suites. 

I think everyone who shares the knowledge should use this approach to prove the behavior of the code/component/service is as expected. 

Due to that practice, even though the book focuses on various issues and tradeoffs you need to accept, it also teaches how to develop the software. We can learn to do changes in a way that increases the quality of the code and makes future refactorings and modifications safer and easier. 

This is an amazing additional lesson we get.

Conclusion

I recommend the book regardless of your seniority or role. Why? It teaches one key thing: "With each decision comes tradeoffs". 

In every chapter, we learn the cost is always there, and we must consider that when making the decision. We learn to accept these consequences, weigh the pros and cons, make the judgment, and move forward.

I enjoyed the journey and wish you the same experience with the book.

To make it easier, I've got a special discount code for you: LTAJ45
It's for 45% off Software Mistakes and Tradeoffs in all formats and is valid through Feb 13, 2024.