There are many Internet lists of best programming and software engineering books. Amazon also has their list of best selling computer programming books. I've also blogged on the topic in the past: "Six must have computer science books" and "What makes a good (tech) book read?" Many of the books I own where purchased based on specific topics of interest and of need. My library is filled with many technical books that I use as references. In general, I like books that are small (a quick read) and focused (they get right to the point). Lately, I've started thinking more about my list of best authors instead of just best books. A great author (and industry luminary) has worthwhile information to impart and also has important things to say. If I enjoy one of their books, I usually check out their other books and often buy all of them.
I've created my top eleven list (in alphabetical order by last name) of best programming and software engineering book authors (some are a combination of authors that often write together as well as individually) and listings of some of their definitive works. My top eleven list (if 11 is good enough for Spinal Tap it is also good enough for me.) is based on:
Kent Beck used to live in the Santa Cruz mountains near where I work and live. I first met Kent Beck at one of the ACM OOPSLA conferences. He was talking about a book by an Architecture professor and architect, Christopher Alexander (A Timeless Way of Building), and how the book was influencing his approach to design with Patterns. Kent also stopped by our company to talk with the R&D team. I've been bumping into Kent ever since at industry events. Kent always challenges assumptions about software engineering and programming. He always makes me stop and think about why what we do.
I have been an ACM member since 1972 when I joined as a student member while I was at Cal Poly San Luis Obispo. Jon Bently's column, Programming Pearls, appeared in the Communications of the ACM montly magazine. The columns provided keen insights into the little algorithmic nuggets that we use (or should use) in our programs. Those columns have been collected into the "Programming Pearls" and "More Programming Pearls" books. "Writing Efficient Programs" The other book that greatly influenced my programming career when I made the move from assembly language programming to using higher level languages. Using compilers and profilers can help us write faster and smaller code. This book trained my mind to think efficient before and during the programming process. I first met Jon Bentley when he was the keynote speaker at the Second Annual Software Development Conference at the San Francisco Marriott. His talk was about "Little Languages". That keynote has driven me to strive for simplicity in programming langauges and application architectures. It was also an important early step in understanding how to embed languages and application engines into my programs.
In the early years of object-oriented programming there were many books on object-oriented analysis and design. Grady Booch, Ivar Jacobsen and Jim Rumbaugh each had their own books and methods. Finally, they got together to combine their approaches into the Unified Modeling Language (UML). I would see them at the many object programming conferences including OOPSLA. I've especially enjoyed my many meetings and conversations with Grady Booch. We were always bumping into each other in airport waiting rooms around the world. Thanks to the three amigos and many other industry members, UML is alive and well as an industry standard specification as part of the OMG set of specifications.
I wrote my first program (a prime number generator) using Fortran on the IBM 360/40 mainframe computer at Cal Poly San Luis Obispo. I still can't believe that this fall it will have been 41 years since I keypunched my first line of code. After graduation I went to work at TRW in Los Angeles. At TRW all of the project planning schedules were broken down into man-hours, man- days and man-months. One of the first non-textbook computer books I bought as a professional programmer was the "Mythical Man Month". The essays helped my improve my software engineering skills on both the large and small projects that I was working on. The book became even more valuable when I made the leap from the technical to the management track (even though I continue to program today). Fred Brooks has a new book, just published this year, called "The Design of Design" with even more essays about design, collaboration, and case studies. I love Brooks' use of essays - they are short, contain complete thoughts, include notes and references.
From the beginning of my career I have always worked in large and small teams. While programming has been more of a solitary activity (except if you are part of a pair programming duo), it is the collaboration in teams that can make and break a project. I learned about project management and team interaction working at TRW. It was DeMarco and Lister's "Peopleware" book that really brought it all home for me - productive teams can really make the difference in the succes and failuer of a project. A more recent book about project risk management, "Waltzing with Bears", help me understand that it is okay to push the limits of programming (we've only been doing this for about 50 years now) as long as we understand the risks.
I've only known Edsger Dijkstra through his articles and books. Numerous articles would appear in the Communications of the ACM monthly magazine. As a young programmer in the 1970s, I thought I could program any computer, anytime and anywhere. The Computer Scientist in me helped keep me grounded in good architecture, efficient algorithms and clean data structures. The Grateful Dead and Jimi Hendrix loving hippie in me drove me to go wild and crazy. Most programmers will remember Dijkstra for his letter, "Go-to statement considered harmful" that appeared in the March 1968 Communications of the ACM magazine. It was Dijkstra's book, "A Discipline of Programming", that taught me "that programs could have a compelling and deep logical beauty". Dijkstra is one of Computer Science's most prolific writers. His books are only one part of the depth and breadth of his work. You can read all of his writings at the Edsger W. Dijkstra Archive.
Before the Refactoring book, we'd all spent hours and days tweaking our code to make it perform and look better. Martin Fowler and others gave us the methods and tools to make refactoring (and in conjunction with unit tests) part of our everyday programming work. We always knew where the problems were, but we often put blinders on so that we could get the job done. With refactoring we were given names for the bad smells and code manipulations that fixed the bad designs and poor implementations in our code. Martin Fowler's Refactoring home page is probably on every programmers bookmark list. Refactoring tooling is built into almost every developer IDE and programmer's editor. Beyond just his writing, Martin Fowler can be found imparting his experiences and sound advice at conferences all over the world.
Thank goodness for Watts Humphrey, Carnegie Mellon University and the Software Engineering Institute (SEI) for helping advance our Software Engineering discipline and improve the skills of every software engineer. Whether you use the Personal Software Process, Team Software Process or some other process, we can all thank Watts Humphrey and the many professors and researchers at the SEI. His latest book, published this year, "Reflections on Management" is subtitled "How to Manage your Software Projects, Your Teams, Your Boss and Yourself". I especially enjoyed Part IV - Managing Yourself. Sometimes it is easy to hide inside a company and a team. The best programmers not only continuously improved the quality of their work, they also influence other members of their team.This book is full of so many nuggets of wisdom and experience that it will help seasoned managers, senior software engineers and beginning programmers.
The title of the book series, "The Art of Computer Programming", says it all. It's not just a job that we enjoy, it is our creative outlet. The book series has been my most trusted programming reference in all my years as a developer. Who hasn't learned an algorithm or used one from his first three books? As a total fan of programming languages and programming, Knuth's lectures have guided my thoughts about simpler languages and faster ways of writing programs. His lecture notes about Literate Programming ring as true today as they did years ago. Part 4 of the Art of Computer Programming is available as a series of sections, definitely worth adding to your programming reference library. I was completely blown away by his honesty in "Things a Computer Scientist rarely talks about". In my opinion, this is a must read for every Computer Science student before they graduate.
How to improve the C programming language? Merge two wonderful languages, C and Simula, and add enough additional syntax and standard libraries so that large and small systems and applications can be built for even the most demanding requirements and operating environments. To put the icing on the cake -- with the cherry on top -- AT&T and Bjarne gave the programming language to the industry so that it can be extended and improved to meet the needs of generations of new programmers and opportunities. Bjarne Stroustrup has not only help shepherd the language, he has also given us key insights in to the philosophy, design, tradeoffs and reasons for the language. His book, "The Design and Evolution of C++", is a must read for anyone interested in creating their own programming language. I've been honored to site on the same panel with Bjarne at several developer conferences. Bjarne also appeared on my "World of C++" instructional video written by Bruce Eckel. I've enjoyed talking with Bjarne about the C++ language and its future. Thanks to Bjarne and the many members of the ISO C++ standards committee, the C++ language will continue to be one of the most important and influential languages for small, medium and large systems.
Before there were objects, there was structured programming. Peter Coad and Ed Yourdon helped teach all of us how to avoid spaghetti code. I first met Peter Coad and Ed Yourdon at many developer conferences. In the early 1990's as we were continuing to expand the capabilities of our C++ IDE, Peter Coad showed me work he was doing to allow C++ programmers to edit their code and edit their object models at the same time. No longer would developers have to go through the "round trip engineering" process. I thought I was a pretty good presenter at conferences, but Peter showed me several additional dimensions beyond use of color ("ROY-G-BIV"), fewer bullet and sub-bullet points and audience contact (ERA = eye contact, reach out and animate). Peter also used music, hat changes, clothing changes, whistles and anything else that would reach out, grad and educate his audiences. I invited Peter to do a keynote at one of our developer conferences. I think it was the largest object modeling exercise ever attempted live (more than 1500 attendees identifying objects, responsibilities and collaborations). Ed Yourdon's books on the rise, fall and resurrection of the (American) programmer books serve as a cautionary tale for all programming communities and developers around the world.
I could have (easily) created a top twenty (or more) author list, but if 11 is good enough for Spinal Tap, it is also good enough for me. Here are a few "honorable mention" authors that, while they have written great books, did not (yet) make it on my final author list: Steve McConnell, Dave Thomas, Charles Petzold, Bruce Eckel, Clifford Stoll, Guy Steele, Larry Constantine, Jeff Duntemann, Ray Kurzweil and Scott Ambler.
I'm sure there will be some authors that are on your list but not mine. Post a comment listing your favorite authors, their books and why they are part of your top ten author list.
Programming is Life!
Recent news for developers:
David Intersimone (David I) is the Vice President of Developer Relations and Chief Evangelist for Embarcadero Technologies. My company blog is at http://blogs.embarcadero.com/davidi. Note: This is a weblog of David Intersimone. The opinions expressed are those of David Intersimone and may not represent those of Computerworld.