The most recommended software engineering books

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.

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.)

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.  

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.

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.

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.

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. 

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.

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.

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.