FAQ: Why 97 Things?
Hardcoded magic numbers and origin stories
As editor of two books in O’Reilly’s 97 Things series — 97 Things Every Programmer Should Know and, with Trisha Gee, 97 Things Every Java Programmer Should Know — the most common question I get is not “Which of the 97 is your favourite?” (that’s a close second) but “Why 97?”
First up, I didn’t chose the number. The number came out of a discussion between Richard Monson-Haefel and Jeremy Meyer and is tied to the origin story of the first book in the series, 97 Things Every Software Architect Should Know. From the acknowledgments in that book:
I would like to thank Jay Zimmerman, who suggested that I do a presentation for the No Fluff, Just Stuff symposiums called “10 Things Every Software Architect Should Know”; Bruce Eckel, for managing the mailing list on which the idea for this book was germinated; Jeremy Meyer, for suggesting that I create a book out of what was going to be a simple slide show; Nitin Borwankar, who suggested doing a public wiki so that everyone can be involved.
The vision was for a number of contributions that would not be essays but would also be more than soundbites. A 100-page book was considered to be too thin — basically a pamphlet — so something of the order of 200 pages or more. If you constrain each piece to around 500 words (2 pages), that gives you something of the order of 100 contributions. 100 is a popular number for lists and listicles, but perhaps too popular. 97, however, is close to 100 but, unlike 99 and 101, is not trying too hard to not be 100. That also makes it more search friendly. And it sounds good. And that’s it.
(That said, I did struggle with the final cut for 97 Things Every Programmer Should Know, whittling it down from over 160 to 99 before getting really stuck. To reduce it to 97 I had to take a long break and go for a walk before deciding on the last two to omit. The Japanese translation included 10 more items from Japanese authors, giving a total of 107 things, but with the book title unchanged. The moral of the story is already one programmers should know: avoid hardcoded magic numbers. Ironically, no one submitted a contribution with that specific advice.)
Richard originally referred to these as axioms, but fortunately things rather than axioms is what stuck. There is no sense in which the things you should know need necessarily be axiomatic — knowledge is rarely that tidy.
I contributed two pieces to 97 Things Every Software Architect Should Know — “Use Uncertainty as a Driver” and “Simplicity Before Generality, Use Before Reuse”— before then being inspired to pull together 97 Things Every Programmer Should Know:
The specific idea to do a programmer-focused book came to me when I was pondering an oversight in some code I was reading, and found myself muttering something like “Dammit, that’s just one of those things every programmer should know!” (something like… but the initial sentiment was probably expressed a little more strongly). The phrase “every programmer should know” was the trigger. I have written up and presented various lists of recommendations and considerations in the past, but having already contributed to Software Architect, I found the wisdom-of-crowds approach appealing.
The specific oversight I observed was a problematic floating-point equality comparison. That ultimately led to one of the things in the final book.
Following the pattern of the first book in the series, I made calls for contributions on social media, at conferences, via direct invitations and from recommendations.
As with 97 Things Every Software Architect Should Know, contributions were made to 97 Things Every Programmer Should Know under a Creative Commons licence, making the content of the book open source. Other more recent books in the series have not followed this practice, but it’s one I value and that Trisha and I continued with 97 Things Every Java Programmer Should Know.
And to answer that second question: I don’t pick favourites.
