Як редактор двох книг серії O'Reilly 97 Things — 97 Things Every Programmer Should Know та, разом з Trisha Gee, 97 Things Every Java Programmer Should Know — найпоширеніше питання, яке я отримую, не є “Яка з 97 є твоєю улюбленою?” (це майже на другому місці), а “Чому 97?”
По-перше, я не обирав це число. Воно виникло в результаті обговорення між Richard Monson-Haefel та Jeremy Meyer і пов’язане з історією походження першої книги в серії, 97 Things Every Software Architect Should Know. Ось що сказано в подяках у тій книзі:
Я хотів би подякувати Jay Zimmerman, який запропонував провести презентацію на симпозіумі No Fluff, Just Stuff під назвою “10 Things Every Software Architect Should Know”; Bruce Eckel, за управління списком розсилки, на якому ідея цієї книги зародилась; Jeremy Meyer, за пропозицію створити книгу з того, що мало бути просто слайд-шоу; Nitin Borwankar, який запропонував створити публічну вікі-сторінку, щоб кожен міг взяти участь.
Ідея полягала в тому, щоб мати кілька внесків, які не є есе, але й не є лише звукофрагментами. Книга на 100 сторінок була б занадто тонкою — фактично це був би буклет — тож щось близько до 200 сторінок або більше. Якщо обмежити кожен внесок до близько 500 слів (2 сторінки), це дає приблизно 100 внесків. 100 — популярне число для списків, але, можливо, занадто популярне. 97, однак, наближається до 100, але, на відміну від 99 і 101, не намагається занадто явно уникати 100. Це також робить його зручнішим для пошуку. І звучить добре. І це все.
(До речі, я дійсно переживав щодо фінального вибору для 97 Things Every Programmer Should Know, зменшуючи його з понад 160 до 99, поки не зіткнувся з реальним складним вибором. Щоб зменшити його до 97, я взяв тривалу перерву і прогулявся, перш ніж вирішити, які два останні пункти виключити. Японський переклад включав ще 10 пунктів від японських авторів, що дало загалом 107 пунктів, але назва книги залишилася незмінною. Мораль цієї історії — це вже те, що програмістам потрібно знати: уникати захардкожених магічних чисел. Іронічно, ніхто не надіслав внесок з цією конкретною порадою.)
Richard спочатку називав це аксіомами, але на щастя слово things замість axioms виявилось тим, що залишилось. Немає сенсу в тому, щоб те, що ви повинні знати, було обов'язково аксіоматичним — знання рідко бувають настільки впорядкованими.
Я надав два внески до 97 Things Every Software Architect Should Know — “Use Uncertainty as a Driver” та “Simplicity Before Generality, Use Before Reuse”— перед тим як потім натхненний створити 97 Things Every Programmer Should Know:
Конкретна ідея зробити книгу для програмістів прийшла до мене, коли я розглядав проблему в деякому коді, який я читав, і чув себе міркуючим щось на кшталт “Чорт, це ж одна з тих речей, які кожен програміст повинен знати!” (щось схоже… але початковий настрій, ймовірно, був виражений дещо сильніше). Фраза “кожен програміст повинен знати” була тим тригером. Я вже писав та представляв різні списки рекомендацій і роздумів, але вже взявши участь в Software Architect, я знайшов підхід “мудрості натовпу” привабливим.
Конкретна проблема, яку я спостерігав, була проблемною порівнянням рівності з плаваючими точками.
Це зрештою призвело до однієї з речей в фінальній книзі.
Дотримуючись шаблону першої книги в серії, я зробив запити на внески через соціальні мережі, на конференціях, через прямі запрошення та за рекомендаціями.
Як і в 97 Things Every Software Architect Should Know, внески до 97 Things Every Programmer Should Know були зроблені за ліцензією Creative Commons, що зробило вміст книги відкритим для публічного доступу. Інші більш нові книги в серії не дотримувалися цієї практики, але я ціную її і ми з Trisha продовжили її у 97 Things Every Java Programmer Should Know.
А на відповідь на друге питання: я не вибираю улюблених.
Перекладено з: FAQ: Why 97 Things?