The most recommended software engineering books

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.

In my consulting gigs, I come across plenty of clueless remarks. Here's a classic one: “We're falling behind schedule, so let's hire more coders.” Or a more recent gem: “We'll be ten times more productive if we generate code with AI.”

When I encounter such nonsense, I don't facepalm or cringe. Instead, I put on my poker face and drop a quote from The Mythical Man-Month.

In an industry where last year’s book is already outdated, Fred Brooks' collection of essays has been a guiding light for nearly half a century. His aphorisms have become legendary. “The bearing of a child takes nine months, no matter how many women are assigned.” “Adding manpower to a late software project makes it later.” “There is no silver bullet.” The list goes on and on.

John Carmack, one of the greatest programmers of our times, used to revisit this book every year or… show more.

Loren’s been contributing to security for over 40 years, and this book captures his hard-won wisdom in a way that’s both humble and accessible. It scales from principles and design approaches to in-depth explanations of exactly how things go wrong and how to avoid those problems. (Also, I was honored to write the foreword.)

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.

This is one of the first books resulting from the Microsoft security “push,” and it’s a classic. It’s of interest both in understanding how Microsoft went about tackling the problem of developing secure software, and as a backdrop for the evolution of secure software development practices that emerged at Microsoft and other major software vendors.   

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!

Okay, hear me out. Yes, this book was published in 2007. Yes, it’s ostensibly about ActionScript, the coding language in Flash, which no one uses anymore. But you won’t use this book to learn ActionScript or Flash: You’ll use it to learn how to make things move with code, in any language. You’ll skip over the ActionScript-specific parts in favor of the lucid explanations and helpful illustrations. Your visual brain will appreciate seeing how sines, cosines, and tangents are relevant—and necessary!—to make digital things move. (Your heart will wish your brain had paid better attention in trigonometry class years earlier, but hey, no regrets!) The chapters “Trigonometry for Animation” and “Velocity and Acceleration” alone are worth the purchase price.

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.

This is an extremely comprehensive overview of most aspects of User Experience (UX).

It’s the kind of book that you may never read from cover to cover (it’s over 800 pages!) but it’s exactly what I’ve appreciated having on my bookshelf when I need a quick how-to overview of a specific design or research method.

This book is a “how-to” guide for teams developing secure software. Written by a team of experts, it covers the important issues in developing software that is better able to prevent successful attacks. The book contains many references, a strategy, and an implementation guide with cross-references. For each topic, the maturity of practice at the time of writing is provided, as well as an indication of the audience.  

Another book that predates GitHub but provides a lot of actionable advice today that’s been mostly ignored across much of our industry.

Hard problems like “why isn’t my software project reliable?” are tackled head-on and addressed here. It was an early nudge for me to automate as much as possible in software projects and not ignore difficult problems with project organisation in favour of “fun” technical tasks.

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.

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.

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.

For years, I couldn’t get yeast to cooperate. I just wasn’t patient enough and it was too darn temperamental. One day, the yeast worked. I made a lovely brioche dough and turned that into the stickiest, sweetest, yummiest cinnamon rolls known to man. 

I might not have stuck with my fussy yeast if it were of the variety in Sourdough. The starter that’s given to the main character sings, hums, and sometimes glows. It’s alive. I know that all yeast is alive, but this yeast is sentient. 

All that being said, the thing I love most about the book is that it is weird. I love weird people and things. I love weird books. What I don’t love about a lot of weird books is that they aren’t as immensely readable as Sourdough. Especially the ones that dance through genres as vastly different as science fiction and romance. But… show more.

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.

With his success at Uber, Stripe, and Calm, Will Larson is probably one of the best-known and current senior engineering leaders writing clear and well-researched advice on developer careers.

StaffEng brings together senior individual contributors from across the industry and strings together the best of their advice. In particular, Will’s elaboration of the 4 types of Staff Engineer is the first time this has been spelled out anywhere on the internet.

I spent my career leading software engineering at two of America’s top banks. It’s not all innovative work, as you might guess, and here is where Toyota comes in. 

Toyota teaches the difference between routine, standardized work (where we use predictive process control) and creative work (where we use adaptive process control). Balancing this in practice is a key to being a great software engineering leader. For those manufacturing-like processes (incremental feature addition, defect repair) the Toyota manufacturing way became the basis of the Agile movement a decade later: flow, pull, level work, quality the first time, process standardization and continuous improvement, and closeness to customers. Toyota Way provides a deeper understanding than any agile seminar. 

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.

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.