small medium large xlarge

Swaine’s World

What Makes a (Tech) Book a Classic?

by Michael Swaine

Generic image illustrating the article
  To try to get a handle on what makes a book a must-read, I examined the phrases people used repeatedly in recommending their must-read books for programmers.  

Like many of you, I suspect, I’ve read a science fiction book or two in my life. Like you, I’ve read a few books on programming issues. Quite a few. Some of them I would call classics.

Those who share my interest in science fiction may be aware that the Nebula Award nominees for 2009 have been selected by the Science Fiction Writers of America. Most Nebula-watchers are probably focused on the dramatic presentation competition this year, where the choice is among Avatar, Coraline, District 9, Moon, Star Trek, and Up. I’m more interested in the novel competition.

I want to know what professional science fiction writers think is an exemplary book, and I want to know what professionals in software think is an exemplary technical book. I track the Jolt awards and wade through lists of Books Every Software Developer Should Read and Best Books for Software Developers and technically-focused Amazon listmakers’ Wish Lists.

I realize I’ll find more careful and sage advice on what makes a good tech book by reading, say, Dave Thomas’s advice to would-be writers. But I keep going back to the lists. Maybe I’m just a list junkie. Maybe I’m taking that whole Wisdom of Crowds meme too seriously.

But for me there are solid reasons to read lists of recommended books. I read to discover gems I didn’t know about, to be reminded of classics I’d forgotten, and to get moral support for my own prejudices.

I recently studied a number of recommended reading lists with a particular question in mind: what makes a book a classic? Is the book a textbook that has been critical to many a programmer’s education? Is it the seminal text in some area? Is it a comprehensive tome on some subject? Is it just charming and engaging? Did it change the reader’s life, or her thinking? Or is it one of those books that nobody reads but everybody just knows is really important?

Reading Lists, Refactored

Five books appeared on just about every list I examined:

  • Programming Pearls by Jon Bentley

  • The Mythical Man Month: Essays on Software Engineering by Fredrick P. Brooks

  • Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister

  • The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas

  • Code Complete 2: A Practical Handbook of Software Construction by Steve McConnell

Maybe some of those books are too new to be called classics. Maybe they’re candidates for classic status. But these five books do seem to be regarded as must-reads. Then there were the books that kept appearing, but not as reliably as those five:

  • Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Jay Sussman

  • Compilers: Principles, Techniques, and Tools by Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman

  • About Face 3.0: The Essentials of Interaction Design by Alan Cooper

  • Refactoring: Improving the Design of Existing Code by Martin Fowler

  • Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides

  • The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie

  • The Art of Computer Programming by Donald E. Knuth

  • Rapid Development Steve McConnell

  • The Design of Everyday Things by Donald S. Norman

  • Code by Charles Petzold

  • The Art of UNIX Programming by Eric S. Raymond

  • Joel on Software by Joel Spolsky

  • Agile Web Development with Rails by Dave Thomas, David Hansson, Leon Breedt, and Mike Clark

You probably have one or more books in mind that didn’t make these lists, like P. J. Plauger’s Programming on Purpose, Andy Hunt’s Pragmatic Thinking and Learning, Steve McConnell’s Code Complete, Andrew Schulman’s Undocumented Windows, Larry Wall’s Programming Perl, or Alistair Cockburn’s Agile Software Development. Oh, and I didn’t mention the Pickaxe Book. Can’t leave that out. Or how about Kent Beck’s Extreme Programming Explained, Kernighan and Pike’s The Practice of Programming, Dan Friedman and Matthias Felleisen’s The Little Schemer/The Little Lisper, Bruce Eckel’s Thinking in Java, Venkat Subramaniam and Andy Hunt’s Practices of an Agile Developer, Bertrand Meyer’s Object-Oriented Software Construction, or any of Edward Tufte’s amazing books. And there may be books in these lists that you wouldn’t wish on a dog. My selection of lists was arbitrary, and a different selection would have yielded different results. But those top five are likely to appear in most lists.

I Couldn’t Put It Down

To try to get a handle on what makes a book a must-read, I examined the phrases people used repeatedly in recommending their must-read books for programmers. I’ve tried to group them conceptually.

Some of the terms referred to the stature of the book: terms like “classic,” “widely quoted,” “highly regarded,” “popular,” “standard,” “influential.”

Another category of terms emphasized conciseness or clarity: “to the point,” “tells you exactly what you need and no more,” “clear,” “concise,” “practical,” “simple and useful ideas,” “direct,” “straightforward advice,” “well organized,” “logical,” “does a great job of explaining,” “clear examples.”

Another theme was comprehensiveness: “covers everything you’d expect,” “wide range,” “covers just about every aspect,” “depth,” “generally applicable,” “definitive,” “covers a lot of ground,” “chock full,” “encyclopedia.”

Another theme that emerged was practicality: “save you time,” “learn good practices,” “refresher,” “general how to solve problems,” “down and dirty,” “useful for beginners and experts alike,” “handy,” “relevant,” “useful,” “reality check,” “nuts and bolts,” “cross-developer,” “cross-language impact,” “found a lot of ways of improving my code.”

Another reason for recommending a book was that it was engaging or a fun read: “entertaining,” “really draws you in,” “fun,” “readable.”

Yet another theme was inspiration: “mind-expanding,” “thoughtful,” “changed the way I thought about software development,” “influenced me,” “thought-provoking,” “ah-ha moments.”

Then there was breadth of applicability: “suitable for any audience,” “cross-developer,” “cross-language impact.”

Clear. Concise. Comprehensive. Pragmatic. Engaging. Inspiring. Broadly applicable. Based on the evidence of these lists, those are the attributes that people look for in books they consider must-reads. That first attribute, stature, I suppose is a consequence of the others, not really a primary virtue.

This little exercise was not a scientific study. If you tried to replicate it, you’d probably come up with different results. But not too different, I hope.

I also hope that my sharing of this exercise was of some use or interest to you. By the way, there was one other attribute that I noticed recurring in people’s explanations for why a book was a classic: “excellent reference.”

A classic book is one you go back to again and again.

While working as one of the founding editors of InfoWorld, Michael Swaine wrote Fire in the Valley: The Making of the Personal Computer with Paul Freiberger; the movie Pirates of Silicon Valley was based on it. He was editor-in-chief and editor-at-large for Dr. Dobb’s, for whom he still writes his “Swaine’s Flames” column. Michael is the editor of PragPub.