61 Books Like Function and Reactive Domain Modeling

My journey in the world of software development has been arduous and challenging.

One of the common struggles we all face is the overwhelming number of solutions available, making it impossible to fully grasp everything at a deep level.

Just when I thought I had mastered an approach and felt competent in it, a new shiny approach would emerge, demanding my immediate attention. It often felt like a never-ending race to keep up with the ever-evolving field.

This constant pursuit of staying relevant as a software engineer can be frustrating, as it feels like we are always lagging behind the rapidly advancing world. I discovered that knowledge of specific technologies, frameworks, or libraries does not easily transfer across different technology stacks. They are too specific and lack universality. It was then that I turned my focus to more general principles of software engineering.

I realized that there are fundamental engineering… show more.

It was a wonderful time when I first embarked on my programming journey.

I felt an immense sense of power over computers and had countless ideas on how programming could improve my life and the lives of others. Everything seemed within reach, and I approached the world of programming with great enthusiasm in the early 2000s.

However, reality hit me like a cold shower when I started delving into actual software development. I quickly realized that it was far more challenging than just writing code.

Each programming language and technology had its hidden complexities and treacherous pitfalls. Every domain was rife with intricate nuances that had to be understood before attempting to develop software within it. I soon discovered that there was no such thing as a "perfect solution" that could be universally applied.

As I ventured into working with real-world domains, I confronted the daunting task of addressing the… show more.

Many functional programming books concentrate on the detail of functional techniques (things like recursion or higher-order functions), often leaving open the gap between these techniques and their concrete application to solve everyday programming tasks.

This was one of the reasons I wrote my book, and one source of inspiration for me was the work of F# evangelist Scott Wlashin.

For many years, Scott has been showing how he applies functional thinking in his daily practice centered around e-commerce, through blog posts on his popular site and his talks at programming conferences. At popular request, he's organized these ideas into his book Domain Modelling Made Functional.

The examples are practical enough that every business application programmer will be able to relate to them, and his explanation of functional programming techniques and ideas is clear and rigorous. Although Scott encourages the adoption of F# (the functional-first language of the .NET family), these… show more.

This book is different from the others I recommended, because its focus is not really on creating algorithms, but rather on how to improve code with a systematic process, keeping functionality but enhancing quality.

The author shows several practical techniques that he applies to real-world problems and empower you to elevate your code's quality and adapt it seamlessly to changing needs. It's not just about writing code; it's about becoming a more effective and confident developer.

I consider this book a companion on the journey to mastering the craft of coding. With it, you’ll always be able to achieve higher-quality code, no matter the original version of the code.

This tour de force probably couldn't get written today. Kernighan and Plauger take snippets of Fortran and PL/I code from real, published textbooks and find things to fix about them. Now, many of their specific concerns are relics of the "structured programming" wars of the 1960s (overuse of arithmetic IF and GOTO) or quirks of the programming languages in question (undeclared variables silently getting the wrong type); but this is educational in itself. If you wonder what's so bad about GOTO, or why we need to declare functions and variables before use, this book may enlighten you. And despite its age, almost every example finds some present-day analog. For example, Kernighan and Plauger's advice to avoid manually counted Hollerith strings in Fortran applies equally to manually counted array bounds in C++: don't write "int a[5]" when you can write "int a[]". The authors boil every couple of pages down to… show more.

Scott Meyers' Effective C++ series was insanely influential around the turn of the millennium. Then C++11 obsoleted almost the whole series by changing the language out from under it. This book—Scott Meyers' last, as of 2024—is the only one that remains relevant to today's C++. It assumes the reader is reasonably familiar with C++98, and then explains smart pointers, move semantics, perfect forwarding, std::initializer_list, decltype and auto, and many other "modern C++" features, in Meyers' trademark item-oriented format, which is easily digestible and quotable.

The past decade of C++ standardization has added plenty of things that this book doesn't mention; but the subjects it does talk about, by and large, have not yet become obsolete. And there's still nobody who writes about C++ quite like Scott Meyers.

This book greatly influenced my philosophy around style. Norman's ostensible subject is the design of physical objects, like emergency exits, shower faucets, and refrigerators, but most of what he says is directly applicable to software design and API design, too.

For example: Whatever you expose or document about your interface, the user will take that and form a mental model of the implementation—and he'll program against that mental model, not against your documentation. So you'd better make sure that your interface—by exposing certain details and deemphasizing others, appropriate naming, and so on—suggests a mental model that will be useful to the user (even if it is not correct in every particular).

For example, a horizontal rod mounted on a door affords pushing (a bit of jargon that's entered my technical vocabulary), while a vertical rod affords pulling. If you use the design language of a horizontal rod, people will… show more.

Head First books are always fun. They know how to engage your brain and have cartoons/puzzles.

I recommend this book whether you are first learning git or have used it for some time. Understanding git is a big deal so you can work efficiently. Without having to keep deleting the repository and starting over!

This book (an update to Software Tools by the same authors) codifies and instructs the principles by which the Unix / Linux toolset was designed. It emphasizes clear, robust code, and the building of tools, reusable, general purpose software components that can be hooked together to solve many kinds of programming and data management tasks. The lessons it teaches are timeless, and the current generation of programmers would be well served to try and learn them.

The original Software Tools was perhaps the single most influential software book that I ever read. It taught me how to think with the Unix mindset, how to make the best use of what the Unix system (and now Linux) offers, and how to focus on readability and maintainability in my own software.

Robert Glass is one of the foundational leaders of the discipline of software engineering. He’s done it all and seen it all. This book includes 55 facts and 10 fallacies about many aspects of software engineering, grouped into the major categories of management, the life cycle, and quality. Based on my own experience, I can vouch for the validity of all the points Glass makes.

These timeless truths can help you avoid going down an ineffective path, wasting time only to rediscover the same facts on your own. There’s no need to retrace the missteps from the past. Books like this can keep your energies focused where they will provide the most value to your customers.