100 books like Erlang Programming

Smalltalk is not as common or popular as it once was, but the influence its design had on programming is hard to overstate.

Reading this book has changed how I think about object orientation, and how I design systems, learning the patterns of Smalltalk makes it clear what object oriented design is really intended to achieve.

I learned my first programming language as a kid, and Basic always felt like a beginner’s language. It wasn’t until I started writing C that I felt in control of the machine. This book is a classic and was on every C-programmer’s shelf in the 80s and 90s. It isn’t the easiest read but is remarkably comprehensive for a relatively thin volume. The fact that it has been in print for over 30 years tells you something about its staying power.

Nowadays, I tend to code in higher level languages, but every once and a while I dip down, getting closer to the bare metal, and brush this baby off. It is probably one of my most well-worn books.

Lisp will always have a special place in my brain, not language can be as expressive and molded to what the programmer wants to do in my opinion.

Learning a programming language can be a bit dry, but not in the case of Land of Lisp, honestly I just found this book to be fun from beginning to end, and even so I was already familiar with Lisp before reading it I actually followed all the way through not skipping a page.

Yes Lisp is hardly in use these days, but if you know it you will find its concepts popping up all over the place and this is why knowing it is so useful.

Not really a programming book, Modern Operating Systems has been influential for me to understand what I am working with.

When learning about how OSs do their job it is impossible to know everything, but having a rough picture and being able to know how and where to drill down further is what it is all about and this is where this book really shined for me. Even when never writing a driver or working with kernel code, knowing how the details fit together helps in estimating complexity.

The knowledge I got from this book more than once helped me recognize when something was too good to be true, or simplify complex software by working with not against the OS, in my opinion a must read for every programmer.

I found Normand’s focus on functional programming techniques incredibly practical and enlightening. Despite its technical content, I found the book accessible and engaging.

I believe this book is essential for anyone looking to tame complexity in their code. It’s a book I revisit when I need to explain the power of functional programming to my colleagues.

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.

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.

This book helped me set my initial approach to software development and I still periodically return to it for grounding.

An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.

Not only does this book provide insight into the planning and development of one of the first visual IDEs, it’s overflowing with hilarious, profound, and pragmatic real-life lessons for how to manage a software team and deliver a complex project.

As a product of its time, the writing isn’t always politically correct. However, many of the lessons and memes are still part of our vernacular today: Don’t flip the bozo bit; If you build it, it will ship; and [Love] the customer.

Some of its lessons should be memes: Beware of [an engineer] in a room, Be an authority, not an authority figure, and Don’t trade a bad date for an equally bad date.

Some sections show their age in our current world of continuous delivery, but few current books have the humor and concise insight of this remarkable work.

Many agile projects employ user stories as a way to represent requirements rather than a more traditional approach combining use cases and functional requirements. I favor the latter approach for several reasons. Nonetheless, user stories are well established in the agile development world, and if you wish to learn about them, there’s no better author to read than Mike Cohn. Cohn describes how to craft user stories well and how they fit into the agile development process.