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.

This is the defining book on the C language, written by the authors of the language and published in 1978.

By the early 1980’s it became the standard for writing systems software, helped by the fact that the UNIX operating system was written in it. UNIX grew to become the world’s dominant operating system, running over 90% of the world’s web servers. 

By the time I encountered the language I already had programmed extensively in assembler, COBOL, FORTRAN, and other languages. I had written a commercial FORTRAN compiler. The language changed my world, and this book was unique then and now for being written by the creators of the language that changed the world of programming forever.

Nothing about all the languages since C makes things better – yes, including C++. All they do is add complexity and put unnecessary constraints on language, along with continuing the focus on language… show more.

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.

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.

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.

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.

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.

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.

“Good agile testing is good context-driven testing applied in an agile context.”

The authors of this book summarize their decades of experience in software testing in over 100 lessons they learned. Follow them along different aspects of the tester’s job, as they re-tell various stories collected over the years with some clear guidance to surviving and testing project.

These software testing industry leaders have some timely contextual advice in here – whether you work as a tester on an agile team or in a more traditional fashion.