Зачем читать книги

С первых же строк скажу, что разработчику можно книги не читать. Более того, подавляющее большинство не читало и не читает. В интернете хватает статей и форумов, StackOverflow открыт круглосуточно, документация щедра, наконец, исходники часто открыты. Так и справляются вплоть до senior’ов и руководителей разных мастей. Короче говоря, я в курсе.
И это не очень хорошо. Дальше вразброс и кратко накидаю, чтобы больше уместить, полноты и цельности не будет. Скорее, россыпь аргументов и примеров для осмысления.

Вне книг вам доступно не всё.
Во-первых, часть информации существует только в книгах. Если вы не читаете, значит, не читаете [Frederick P. Brooks Jr. The Mythical Man-Month. Addison-Wesley, 1995] или [Robert C. Martin. Clean Architecture. Prentice Hall, 2017]. Вам, быть может, такое и не надо, но вполне можно представить текст, что нужен, а проходит мимо. Также стоит упомянуть, что некоторые книги в наличии только в бумажном качестве. Из недавних примеров [Фельдман Б.Я. От калькулятора к суперкомпьютеру. РТСофт, 2014]. Интереснейшие мемуары, а тираж с гулькин нос.
Во-вторых, иная информация такого объёма, что даже в цикл статей не укладывается, а если уложить, получится та же книга, а распиливать её на автономные клочки глупо, т.к. главы опираются одна на другую. Обычно это фундаментальные труды по фундаментальным знаниям. Примером могут служить талмуды вроде [Andrew S. Tanenbaum, Herbert Bos. Modern Operating Systems. Pearson, 2014] или [Олифер В., Олифер Н. Компьютерные сети. Питер, 2017].
Как ни крути, а лишаете себя не свежих похождений клоунов из телевизора отказом от телевизора, но профессиональных знаний.

Книга — удобный контейнер для плавного и последовательного строительства системы знаний в голове. Это давно опробованный и оформившийся формат обучения. Современная практика делит ремесленный учебник на следующие части:

  1. Введение — небольшой рассказ о том, что за текст, как его читать, что пропускать можно, а что не рекомендуется и т.п.
  2. Софт — если нужен софт, тут объяснят, как его ставить, какие версии нужны, как вообще оборудовать рабочее место.
  3. Главы основы (entry level) — в голову внедряются понятия, без которых более сложные темы не понять. Здесь же иногда объясняют, для каких целей появился объект учебника, дают немножко теории. Для языков программирования вводят понятия функций, типов данных, элементы ООП и т.д.
  4. Специальные главы (middle level) — после того, как отработали первые helloworld’ы, переходят к более другим задачам: работа с RDBMS, графика, сеть, всё такое. В некоторых учебниках эта часть построена на микропроектах, чтобы собрать на одну нитку сведения из предыдущих глав: а давайте напишем небольшой почтовый сервер, ага.
  5. Дополнительные главы — сюда авторы скидывают style guides, best practices, немножко справочной информации, нужной для книги, и всё такое.
  6. Библиография — иногда невероятно важная и полезная штука, если хотите углубиться в какую-либо тему.

Таким макаром легко изучать что-то новое. Джависту вёрстку, фронтендеру Python, джуниору SQL, начинающему пользователю ClickHouse осваивать Kafka. Т.е. нет, книга не пересказывает документацию (иначе это плохая книга, я о таких иногда гадости тут пишу), она таки даёт курс от и дальше.


Иногда книга — продукт работы автора, дизайнера, вёрстки. Сам по себе файл / бумажный том сделаны так, что усвоение информации облегчается, да и вообще превращается в удовольствие. Элементы инфографики, разрежающие вставки, пиктограммы, выделение блоками. Шедевром считаю [Jon Duckett. HTML and CSS: Design and Build Websites. Wiley, 2011], вот уж где красота.
Мне очень нравится и то, как издают учебники западные лидеры мануалостроения, так сказать: Addison-Wesley, O’Reilly, Pearson, Prentice Hall, Wiley, MIT Press. Из относительных новичков отмечу ещё No Starch Press. Ни авторам, ни издательствам не интересно, чтобы у читателя вспухла и взорвалась голова, в которую всунули гранитную плиту знаний. Интересно, чтобы книга понравилась, информация дошла, автор запомнился. Если вам кажется, что до сих пор текст подаётся так, как подавался в учебниках издательства «Наука» (и как же прекрасно на их фоне выглядели издания, которые переводил и печатал с соблюдением формата «Мир»), прекращайте. С этим нынче всё хорошо, глаза под веки стекать не будут.

Если авторы хотят текстом повлиять на мышление и дать устойчивое мнение, без объёма никуда. Люди так устроены. Вас не убедит один пример и не убедят даже пять. Ну типа да, какую-то там стачку в 1903 году разогнали залпами, поубивав народ, и шо? А если таких стачек десятки, да ещё с годами, да ещё с фамилиями, да ещё с причинами каждой? Тут и дурак задумается о том, чем булки в России пахли. Только вот все эти примеры занимают место. Хочет автор или нет, а для подтверждения своих утверждений он будет страницу за страницей исписывать текстом. Объём, объём… Нет объёма и уместить в статью? Значит, минус примеры. Значит, минус убедительность. Значит, часть читателей пройдёт мимо чего-то важного, быть может.
Примером такой книги в разработке могу назвать [Jonathan Shariat, Cynthia Savard Saucier. Tragic Design: The Impact of Bad Product Design and How to Fix It. O’Reilly, 2017]. Как показать читателю (дизайнеру, разработчику, менеджеру), что он не просто делает софт, но делает продукты, которые влияют на жизнь людей? Как показать, что ошибки могут привести к трагедии (и хорошо, если только лишь к снижению потока пользователей)? Убедит ли читателя текстик в пять страниц (столько в распечатке занимает одна среднего объёма статья блогов)? Не думаю.
Кто книги не читает, тот среди прочего не знакомится и с культурой вот такого обоснования, понижая планку качества убеждений. Не ок.

Иногда встречаю узкий взгляд на профессиональную литературу: разработчики сводят книги к сугубо техническим мануалам. Словно книги и документация дублируют друг друга. Повторюсь, если книга дублирует документацию, автор плохой и книга его плохая (любители такую фигню выпускать: Packt и Apress). Реальный репертуар же намного шире.
Во-первых, есть «культурные» книги. То, что не научит вас циклы правильно лепить, но расскажет историю того, в чём вы варитесь. Может, даже воодушевит. К персональным историям этой категории можно отнести [Linus Torvalds, David Diamond. Just for Fun. HarperCollins, 2001] или [Kevin Mitnick. Ghost in the Wires. Back Bay Books, 2012]. Истории корпораций не менее интересны: [Tim Jackson. Inside Intel. Dutton Adult, 1997]. Как и их сражения: [Fred Vogelstein. Dogfight: How Apple and Google Went to War and Started a Revolution. Sarah Crichton Books, 2013].
Во-вторых, есть мануалы не к софту или технологии, но к профессии. Пишут их вполне толковые люди, а уровень текстов… В общем, когда подобное читаю, представляю, как сижу с автором в пабе, цежу пиво, заодно слушая детальный и любопытный рассказ о том, как писать софт, как проектировать, в чём сила. Такие книги всем известны, но напомню пару примеров: [Steve McConnell. Code Complete. Microsoft Press, 2004] и [Martin Fowler с толпой чуваков. Refactoring. Addison-Wesley, 1999]. Из недавних снова упомяну задорную [Катрин Пассиг, Йоханнес Яндер. Программирование без дураков. Питер, 2017].
В-третьих, есть книги по довольно специальным темам, совершенно не укладывающимся в статью. Известные труды такого рода написаны хорошим языком, глубоко и профессионально разбирают объект по косточкам, да и просто интересные. Вот некоторые. [Henry S. Warren. Hacker’s Delight. Addison-Wesley, 2012] — распрекрасные игры с битами и байтами от аксакала индустрии. [Robert Love. Linux Kernel Development. Addison-Wesley, 2010] — интересная книга о том, как работает ядро Linux. [Jeff Duntemann. Assembly Language Step-by-Step. Wiley, 2009] — настолько доступно, толково и занятно рассказать про не самую весёлую область — автор гений.
А ещё сборники интервью [Federico Biancuzzi. Masterminds of Programming. O’Reilly, 2009] и [Peter Seibel. Coders at Work. Apress, 2009]. И классика азов информатики с 400+ customer reviews на Amazon [Charles Petzold. Code. Microsoft Press, 2000]. И взорвавшая девопсами мир [Gene Kim, Kevin Behr, George Spafford. The Phoenix Project. IT Revolution Press, 2013]. И до опупения ещё всякого. В общем, не мануалами едиными.

Чтение книг представляет собою определённый вид активности головного мозга. Вы учитесь впитывать массив информации. Не белый шум Твиттера, не десять статей на разные темы за день, не развлекающую техномелочь с Хабра. Пять сотен страниц. Открываете книгу и день за днём. Она оседает в памяти, встраивается в вашу систему взгляда на мир. Если вы потребляете знания отрывочно, вы кидаете в котлован кирпичи в надежде, что там сам собою сварится дом. Если читаете книги, в котлован опускаются готовые блоки.
Ну ок, это лирика. Не лирика (накидаю всякое просто для демонстрации, что чтение книг не просто ужасная советская пропаганда, чтобы люди на баррикады не шли, а занимали себя тихо в хатах):

И ещё множество ссылок в интернетах, было бы желание гуглить. Суть в том, что чтение книг — это не просто чтение, но неплохо развивающая активность, если заниматься регулярно и в удовольствие.


Как-то так. Вряд ли скажу лучше или обосную глубже, т.к. всю хоть сколь объективную аргументацию исчерпал. Для меня вопрос «зачем читать книги» звучит как «зачем быть здоровым, умным и [разумно] богатым», настолько лежащими на поверхности кажутся ответы.
Но в стопицотый скажу: вы можете не читать. Вас не заставляют. Чтение книг само по себе не делает человека умнее или глупее (если он не ребёнок, тут уже в тысячный раз упомяну [Манфред Шпитцер. Антимозг. Цифровые технологии и мозг. АСТ, Кладезь, 2013]). Как говорят наблюдения, семь миллиардов разработчиков не читали и не читают, но при этом работают, успешно зарабатывая евродоллары в кубышку. Джуниоры, сеньоры, руководители. Так зачем книги читать-то, раз всё хорошо и без них? Затем, что, быть может, всё-таки всё не так уж и хорошо. Просто достаточно.

Зачем читать книги: 2 комментария

  1. Интересно было бы некий топ-10 книг от автора блога. И еще интересен подход к чтению — проходите ли все задачки, конспекты ведете или просто читаете — что-то понял, что-то запомнилось а что-то мимо пролетело.

    Например по себе я заметил такую вещь — иногда я читаю книгу, понимаю не все, но спустя время могу прочесть другую книгу, по этой же теме (или даже заметку на хабре/блоге) и сразу все встает на свои места. Как пример книги по Linux/Unix, невозможно из одной книги и сразу все понять.

    Из чего делаю вывод, что не надо себя насиловать над каждой строчкой и пропускать что-то или не до конца осознавать, это нормально.

Добавить комментарий