62 Books Like Facts and Fallacies of Software Engineering

Many of the most significant principles of effective software development are timeless. They’re independent of the development life cycle or model, programming language, application type, and so forth. Although this book is quite a few years old now, nearly all of its contents are still valid. The 201 principles cover the full spectrum of software engineering: general principles, requirements engineering, design, coding, testing, management, product assurance, and evolution. The descriptions of each principle are concise, whereas my 60 lessons in Software Development Pearls go into a great deal more detail and offer many practical techniques.

There’s an unfortunate tendency among young software people to disregard knowledge from the past as irrelevant to them. That’s not correct. This book can help close significant gaps in any practicing software developer’s knowledge.

A thoroughly fascinating (and fascinatingly thorough) look at engineering practices at Google.

It’s an encyclopedia written by a bunch of authors, so some of the chapters are a little dry, but for those of us who aren’t on teams with 25,000 engineers it’s spell-binding to see what programming at that sort of scale looks like. Some of the chapters prompted us to think really hard about the way we do things at Sucker Punch.

Most books about lessons learned and good practices tell you what you ought to be doing. AntiPatterns warns you about things you should not be doing. It points out a wide range of software project approaches that the authors believe are not advisable. The antipatterns have whimsical titles such as Poltergeists, Golden Hammer, Spaghetti Code, Stovepipe System, and Design by Committee. Each pattern describes the symptoms, causes, and consequences of that particular behavior, as well as offering a restructured approach that’s likely to yield better results. As with other lessons-learned books, this book lets you learn from the pain suffered by others to avoid stepping into the same traps on your own projects.

One way to craft lessons learned is in the form of recommended best practices (or, as I prefer, “good practices”). Best practices represent collected and distilled wisdom from many observers, many projects, and many years of experience. Rapid Development includes 27 best practices for software development, with one chapter devoted to each. Although the book was published more than 25 years ago, most of these are still relevant. Indeed, several of them have been incorporated into routine contemporary practices: evolutionary delivery, designing for change, timebox development, and requirements scrubbing. Techniques such as inspections, miniature milestones, principled negotiation, and reuse are perennially pertinent.

I was lucky enough to read an early draft of this book and it’s simply the best analysis of the open-source software ecosystem around today.

The writing style is friendly and not formal despite the academic-level research that went into this book. It made me think differently about the open-source projects I maintain and how I interact and chose those I use.

When people think about software engineering they mostly think about programming, but that’s not where a project starts. It starts with requirements.

(Really it sometimes starts with company politics, bickering, excuses, and backstabbing, but requirements gathering is often the official start.)

A good set of requirements keeps developers pulling in the same direction; a bad one can make the team inefficient, cause endless arguments, set developers against each other, and make the project feel like Lord of the Flies. I’ve seen projects scrapped and restarted from scratch or even canceled due to poor documentation.

Every software developer should know at least a little about writing so they can produce clear requirements and documentation.

This book isn’t specifically about writing documentation (which is something of an art in itself), but it can help you learn how to make your business writing more effective. This book won’t turn you into Shakespeare,… show more.

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.

I'm a devoted advocate of functional programming and a passionate Haskell enthusiast.

Ironically, there was a time in my life when I was a student and held the belief that functional programming was merely an impractical academic pursuit.

However, I soon had a revelation that the techniques I employed in C++ to mitigate the inherent unsafety of the language actually aligned with the core principles of functional programming: immutability, purity, and composability.

This realization left a profound impression on me, prompting me to delve into learning Haskell. It proved to be a pivotal moment that significantly shaped my entire career trajectory.

As I delved deeper into functional programming, I discovered a significant void in terms of software engineering practices that were prevalent in the realm of object-oriented programming.

Drawing from my experiences in C++ and C#, I noticed numerous gaps in our understanding of how to build robust applications using… 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!

Michael Lopp, or Rands, as he is commonly known online, has been sharing his knowledge as a software manager for years, mainly through his blog. He is one of the most insightful voices about the art of management in a software environment, and even if you are not a manager yourself (and don’t want to become one), will make you understand and better collaborate with your own manager, and be ready when you need to lead a team or understand how it is to work with other humans.