Как вынести максимум пользы при чтении профессиональной ИТ-литературы

Преподаватель GeekBrains Александр Пряхин об эффективном чтении книг по программированию.

Александр Пряхин

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

При этом очень много книг, связанных с профессиональной деятельностью, довольно велики по объёму и редко могут быть прочитаны за один вечер. Да и нужно ли так торопиться?

В начале карьерного пути многие стараются поглотить как можно больше литературы, найденной в списке «Топ-10 книг для начинающего программиста». Но без сформированного подхода к чтению технической литературы книга может не оставить и следа в вашей памяти. Давайте рассмотрим шаги, которые помогут вам эффективно читать книги с максимальной отдачей для себя. Будем подразумевать, что вопрос о том, стоит ли читать ту или иную книгу, у вас не стоит.

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

Теория

В 1940 году Мортимер Адлер уже столкнулся с задачей, которую мы пытаемся осветить в данной статье. Его работа «Как читать книги. Руководство по чтению великих произведений» послужит фундаментом для создания собственного подхода к чтению литературы.

Адлер делит чтение на четыре типа:

  • Элементарный.
  • Инспекционный.
  • Аналитический.
  • Исследовательский.

Элементарный и инспекционный методы относятся к методам быстрого чтения без погружения в детали, что делает их неподходящими для решения нашей задачи. А мы хотим получить качественные знания с твёрдым их закреплением.

Аналитический тип чтения характеризуется тем, что читатель максимально взаимодействует с книгой, включая работу со ссылками на сторонние материалы и прочие шаги, которые мы ещё рассмотрим.

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

Аналитическое чтение

Раз уж мы остановились именно на этом типе чтения, давайте рассмотрим, что же характерно для него и как оно работает. Это самый «долгий» тип чтения. На выходе читатель, используя внешние источники информации и определенные методики, получает максимально полный пакет информации.

Самый первый хинт, который в данном случае применим — это чтение с блокнотом, в котором вы будете делать для себя заметки по ходу чтения книги. По результатам вы вынесете для себя набор мыслей, которые сформировали в процессе чтения. Но пока что этого мало. Заметки — лишь подспорье для получения результата, так как по прошествии времени вам будет сложнее ещё и ещё раз возвращаться к этим заметкам, ведь пока они не систематизированы.

На выходе, пользуясь своими заметками и памятью о прочитанном, напишите для себя рецензию, которая будет отвечать на следующие вопросы:

  1. В чём суть прочитанного? Если это книга по программированию, общую суть бывает довольно тяжело выделить: она будет формироваться в виде типа «Книга про Java». Но материал в подобного рода книгах разбит по довольно большим главам или разделам. Поэтому отвечайте на этот вопрос после каждого раздела.
  2. Если в книге автор делится с вами своей точкой зрения, отметьте, согласны вы с ним или нет. Разумеется, это должен быть не односложный ответ, а аргументированная позиция.
  3. Какие выводы вы сделали для себя после прочтения раздела? Заметьте, что здесь вы указываете только выводы! Многие начинающие разработчики спешат тут же применить свои знания на практике, не систематизировав их и не имея общей картины. Поэтому сначала дочитайте книгу до конца.

  4. Что полезного для себя вы вынесли из раздела или книги? Нужно чаще делать бэкапы? Или использовать системы контроля версий? Ещё что-то? Здорово! Сформулируйте этот ответ как конкретную рекомендацию к действию («Мне нужно начать использовать GIT, потому что версионирование кода облегчает командную разработку»), а не как констатацию факта («Резервирование систем – это хорошо»).

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

Разумеется, в данном упражнении нужно быть предельно честным с самим собой, так как написание «рецензии» просто потому, что нужно, не даст нужного результата на выходе.

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

Практика

Самым очевидным и в то же время самым игнорируемым моментом в чтении технической литературы является практическое применение новых знаний. Хорошим примером книг с практической частью является серия Head first, которая содержит множество упражнений по пройденному материалу в конце занятия. Эти упражнения ни в коем случае нельзя игнорировать. Вспомните школьные занятия по русскому языку — они насыщены практическими примерами для каждого правила в огромных количествах.

Множество книг по программированию содержат в себе листинги кода, которые разработчики зачастую просто перепечатывают в IDE и пытаются запустить. В этом нет ничего плохого, но в самом процессе уже кроется ошибка. Нельзя перепечатывать код бездумно. Запуская тот или иной пример, пусть даже заранее подготовленный на GitHub, вы должны чётко осознавать назначение каждой строчки кода, с которым работаете.

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

В идеальной ситуации код, который вы пишете по результатам чтения книги, стоит отдавать на проверку тем, кто уже знаком с изучаемой вами технологией. Но такие люди есть не всегда, поэтому если вы не можете обосновать то или иное решение или решить задачу, не пренебрегайте внешними ресурсами вроде Stack Overflow. Случается, что прочитанная информация воспринимается не совсем корректно — в силу перевода или технической подготовки. Поэтому сторонний взгляд на ту же часть теории, вполне вероятно, даст ясное понимание того, с чем вы работаете.

«Потрачено»

Не исключена в реальной жизни и ситуация, когда книжка, что называется, «не зашла». Такое происходит по разным причинам: неправильный выбор, высокая для текущего уровня знаний сложность, плохой перевод. Момент потери интереса к книге должен чётко фиксироваться читателем.

Не следует читать через силу. Напротив, всегда будьте предельно честны к себе. Если вы теряете интерес к книге, отложите её. Вероятно, вы ещё вернётесь к ней в будущем. Время, которое вы потратите на работу с ненужным материалом или же, что ещё хуже, на некачественную работу, вернуть не получится. А его можно было потратить на более полезную литературу.

Здесь есть коварная ловушка — лень. Она всегда будет на стороне отказа от дальнейшей работы над материалом и оправданий в силу его бесполезности. Будьте крайне осторожны! Как всегда, ответственность перед собой будет самым эффективным противодействием. Всегда помните цель, с которой вы начинаете читать ту или иную книгу.

Резюме

Создатель методики эффективного чтения книг Мортимер Адлер говорил: «Если, научившись читать и изучив величие книги, вы продолжаете действовать неразумно в личной жизни или в политике, значит, вы напрасно потратили время. Возможно, вы получили удовольствие, но долго оно не продлится».

Чтение технической литературы для ИТ-специалиста — это такая же часть работы, как проектирование систем и написание кода. Поэтому к нему нужно подходить серьёзно и системно. Приёмы, которые были рассмотрены в этой статье, — лишь малая (но не менее эффективная от этого) толика в построении процесса работы с литературой.

Пользуясь полученными знаниями о работе с внешними источниками, ознакомьтесь с трудом Адлера. Он поможет выработать такой подход к чтению, чтобы вы могли получать максимум полезной информации из выбранной книги.

0
19 комментариев
Написать комментарий...
Misha Kasalapi

Может формат книги просто устарел, если, чтобы извлечь из нее пользу, приходится делать столько непредусмотренных, посторонних вещей? Из всех хороших программистов, которых я знаю, книги читают единицы, остальные же обходятся актуальными статьями и блогами на проф тематику.

Ответить
Развернуть ветку
Никита Шультайс

Не путайте хороших программистов с начинающими. Сложно научиться программированию с нуля по актуальным статьям и блогам, так как там информация разбросана и не систематизирована. Для обучения важнее системность и последовательность.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Misha Kasalapi

Извините, перепутал

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Antony Sedov

Вообще самые эффективные книги по программированию, на мой взгляд, в серии Head First. Очень много практики и очень мало «воды». Иногда в книгах целые главы посвящены истории языка, где-то вас учат работать с cmd, а в этой серии сразу к делу. Но есть и минусы. Книги из этой серии надо читать от корки до корки, так как обычно код там совершенствуется из главы в главу, поэтому если вы что-то упустили, можете не понять.

Ответить
Развернуть ветку
Павел Новойдарский

Согласен , решил первым языком выучить python , взял курс на курсере , и не заметил что там стоит уровень intermediate, в итоге дошёл до второй недели и не осилил одну из задач , да и вообще , сложно было понимать о чем с тобой говорят на лекциях . Потом как раз смотрел вебинар Александра Пряхина , и он посоветовал Head First , взял книжку по питону и удивился от того насколько там понятна каждая строчка , в итоге смог влиться обратно в курс

Ответить
Развернуть ветку
Alex Pryakhin

Да, я и сам в своё время по ним учился кодить. Отличная литература для новичков, имеющая оригинальный подход. Но со временем всё равно приходишь к классике.

Ответить
Развернуть ветку
Павел Новойдарский

я вот только дочитал книгу по питону , и не знаю , что делать дальше , что учить , что читать 😂

Ответить
Развернуть ветку
Alex Pryakhin

Кодить. Есть ещё одна моя статейка - почитать можно вот тут https://devenergy.ru/archives/575
Как раз про то, какие задачки порешать.

Вкратце - попробуйте codewars, почитайте codekata. Практикуйтесь.

Ответить
Развернуть ветку
Павел Новойдарский

На codewars как раз после вашего вебинара сижу 😂

Ответить
Развернуть ветку
Alexey Laptev

Кто не умеет работать тот учит?

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

Тк ни одна книжка не даст прочувствовать проблемы кривого кода.

А если тебе надо конспектировать чтобы понять что ты прочитал - скорее всего программирование не твое.

На мой взгляд когда постоянно все меняется, важнее просто по заголовкам фиксировать где какие проблемы обсуждаются что бы потом знать что гуглить, тк вникать во все "полезное" физически нет времени.

Ответить
Развернуть ветку
Никита Шультайс

А что нужно делать в промежутке между "Hello World" и попаданием в реальный проект в составе сильной команды? Сильная команда не возьмет человека, который совсем не умеет программировать. Соответственно ему нужно как-то научиться. Как?

Ответить
Развернуть ветку
Serge Arsentiev

Ну, ребята знакомые просто учились - брали новый язык, книжку по нему, компилятор и переписывали старую задачу на новом языке, до тех пор пока не получалось, более-менее. Потом, еще одну старую задачу.
У них хватало времени и упорства - обычно это все же 20 ... 25 лет, освоить на базовом уровне несколько языков - и дальше развивать знания того, на который сейчас есть реальная вакансия базового уровня, допустим.
 
У меня, к сожалению, после как раз лет 22-х (когда некоторые становятся миллионерами, на сайте, слепленном на php скриптах вокруг БД), совсем отрубило желание программировать - я сам не понимаю почему, вот просто "пропало желание" и все - и никакими стимулами, никакой востребованностью профессии во всем мире это не вернуть.
 
Уже все изменилось - уже девушки реагируют на слово "программист" с середины 2000-ных, почти также как на слово банкир в начале 90-х ... уже десятки тысяч программеров успели съездить и остаться/вернуться в/из США/ЕС ... а я, ну вот как Вы - с интересом думаю - свихнулся бы я окончательно, если бы ушел в программинг, или нет?
 
Потому что программирование сворачивает мозги, всерьез и надолго, и это к сожалению правда :(

Ответить
Развернуть ветку
Alexey Laptev

У вас бы не возникали эти вопросы, если бы вы имели хоть какой-то реальный опыт разработки :) Думаю обучаете вы так же профессионально.

Но алгоритм в целом такой:
1. Ставим реальную задачу - коммерческий проект или пет-проект
2. Открываем мануал , сейчас в основном дока от разработчиков.
3. Делаем проект, лучше несколько.
4. С этими проектами уже можно куда-то пробиваться, в том числе в команды

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

Ответить
Развернуть ветку
Никита Шультайс

По поводу бездумного перепечатывания и построчного разбора примеров. Нужно всегда задавать вопрос "А что произойдет если я поменяю тут параметр?". То есть нужно экспериментировать с кодом, который только что набрал из учебника. Это лучше дает понимание, как он работает и какие у него есть ограничения.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Alex Pryakhin

Тут вопрос в том - а зачем вообще Вы её будете читать? Если для повышения скилла, то я почему-то уверен, что, запланировав в своём рабочем дне полчаса на вдумчивое чтение (хотя бы во время обеда), можно без больших потерь читать книжки. Главное - следить за своим графиком и быть предельно честным с собой. Ведь никто из нас не работает 8 из 8 часов в день (8 - условное число, у каждого оно своё). И чтение чего-то нового здорово помогает отвлечься.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Дима Корно

Не подскажите подкаст?)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
16 комментариев
Раскрывать всегда