Алгоритм чтения книг по программированию

Всем привет. Меня зовут Борис, уже несколько лет я увлекаюсь теорией обучения и запоминания — тем, как работает мозг с новой информацией. Сегодня я поделюсь своим способом читать книги.


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


Алгоритм для обычных книг


Всё очень просто:


  1. Читаем автора и название;
  2. Задаем вопросы, ответы на которые мы хотим найти в книге;
  3. Пролистываем: разглядываем картинки, цитаты;
  4. Читаем содержание, оглавление, аннотации;
  5. Читаем книгу (чем быстрее, тем лучше);
  6. Выделяем основную тему;
  7. Выделяем факты и новизну;
  8. Пролистываем книгу;
  9. Опционально: записываем в табличку в экселе, о чем книга, кто ее посоветовал, стоит ли перечитывать и почему.

Если через полгода нужно будет вспомнить, что было в той книге, ее можно будет просто пролистать — этого будет достаточно. Работает отлично с книгами по психологии, переговорам, маркетингу, etc.


Увы, читать таким способом книгу Дэвида Флэнэгэна «JavaScript. Подробное руководство, 6-е издание» или ng-book бессмысленно и бесполезно. В голове не останется ничего, а время потеряется. И вообще, техника скорочтения для подобных книг скорее вредна, чем полезна.


Когда-то я занимался по книжке "Learn Ruby the hard way" (когда она еще была бесплатной). Главный ее принцип в том, что вам нужно перепечатать 100 программ. Конечно, часть из них нужно улучшить, но главное — это перепечатать 100 листингов. В процессе перепечатки неизбежны ошибки. А в процессе поиска и исправления ошибок приходит понимание того, что собственно в программе делается. Чуть позже я посмотрел курс на Coursera про то, как правильно выстроить процесс собственного обучения, и постепенно у меня сформировался собственный алгоритм чтения технической литературы.


Алгоритм для технической литературы


Выглядит он так:


  1. Формулируем задачу, которую мы хотим решить, прочитав книгу;
  2. Начинаем читать медленно и внимательно, перепечатывая каждый из приведенных листингов;
  3. Регулярно — раз в полчаса-час — делаем паузу и вспоминаем, что именно мы делали предыдущий час;
  4. Заканчивая очередную тему, смотрим, достаточно ли мы узнали для того, чтобы решить задачу;
  5. Медленно, но верно дочитываем до конца;
  6. Еще раз вспоминаем, про что была книга;
  7. Пишем программу, используя максимум того, что было в книге.

Формулируем задачу, которую мы хотим решить, прочитав книгу


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


Начинаем читать медленно и внимательно, перепечатывая каждый из приведенных листингов


Ключевое слово «медленно» — не нужно торопиться, особенно если в этой теме вы еще ничего не понимаете или понимаете не все. Здесь принцип тот же, что и с книжкой по ruby: ручной труд порождает ошибки —> ошибки порождают задачи –> решение задач тренирует мозг и добавляет понимания.


Регулярно — раз в полчаса-час — делаем паузу и вспоминаем, что именно мы делали предыдущий час


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


Заканчивая очередную тему, смотрим, достаточно ли мы узнали для того, чтобы решить задачу


И если достаточно, то либо заканчиваем чтение (вернемся к этой книге, когда появится в этом необходимость), либо дополняем и расширяем задачу. Важно, что сделать это нужно до того, как вы начнете читать дальше: попробуйте дополнить задачу и придумать, как ее можно было бы решить в идеальном мире.


Медленно, но верно дочитываем до конца


Ну или перестаем читать, потому что узнали все, что было нужно.


Еще раз вспоминаем, про что была книга


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


Важно! Пишем программу, используя максимум того, что было в книге


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


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


Полезные ссылки


Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 20
  • +1
    Спасибо, подход интересный, я обычно просто веду конспект (вещи которые новые), либо на полях пометки делаю карандашом.
    • 0
      У меня нет чёткого алгоритма, при прочтении книг по программированию. Но всегда, когда я начинал учить разные языки, будь то С, GoLang или Swift, я всегда перепечатывал примеры (не копипаста) в свою IDE и тестировал как они работают. Если в книге были ошибки, то я вспоминал создателей книги и старался их исправить.

      Я знаю, что мой подход не претендует на новизну или «скорочтение», но это помогло мне впитать ту разницу в терминах «объявление» и «определение» :) да и познать язык.
      • 0

        А зачем Вы просто перепечатываете пример? Его (каждый набранный пример) надо ещё и обязательно изменять самому — в итоге к концу книги все примеры превращаются в Франкенштейнов, взамен оставляя в голове запомненный язык программирования.

        • 0
          Я писал с телефона, поэтому не указал всех деталей. Да, вы правы, конечно я не только перепечатывал пример, но и экспериментировал. Например, когда проходишь std:cout, или printf (знаю, что это из разных библиотек), то приходилось тратить продолжительное время, чтобы протестировать всё то, что приходило в голову.

          Просто перепечатывать тоже полезно, как я считаю, потому что развивает механическую память, и потом уже ты автоматом создаёшь функцию main не глядя на её объявление в книге. Если не перепечатывать, а сразу лепить своё, то когда тема новая, сразу же твой пример перестаёт работать и ты не понимаешь что к чему…
          • 0

            Зато придётся проявлять изобретательность, аналитические и лингвистические способности (в смысле как английского, так и С++)...:) Представьте себе, как прокачаются скилы, если таким способом поизучать что нибудь сложное — например, шаблоны в С++ — можно даже запретить себе искать готовые рецепты для исправления ошибок в сети, а разрешив пользоваться только, например, ISO/IEC 14882 1998, ISO/IEC 14882:2011, C++ ISO/IEC JTC1, draft C++17 и, в особо сложных случаях (в качестве "послабления") — документацией на компилятор и отладчиком. Такая прокачка скилов — отличная замена для взрослых прочитанных в юности историй о Шерлоке Холмсе — только тут есть возможность самому в него поиграть.

        • 0
          Если в книге были ошибки, то я вспоминал создателей книги
          недобрым словом?
          • 0
            Да, это ужасно, единственная книга, которая попортила мне нервов, это какой-то там самоучитель С++ за 21 день (одна из моих первых книг), которая мне досталась нахаляву. И там практически каждый, каждый, чтоб их, пример был с дефектом. То точку с запятой потеряют, то один знак больше/меньше.
            Главу с какой-то Борландовской гуи-библиотекой для Borland C++ 5.02 я решил пропустить. И хорошо. Всё равно этот фреймворк был вытеснен VCL, а потом и вовсе пропал где-то.
            • 0
              Примеры с ошибками на мой взгляд требуют большего и внимания и понимания того, что в них написано.
              Поиски «почему не работает» эффективнее отложит информацию в голове, чем копипаста и небольшие правки в рабочем коде
          • 0
            Неоднократно встречал утверждение, что ошибки в листингах помогают в изучении языка.

            Типа, человека заставляют думать, самостоятельно разбираться в языке (а не тупо «копипастить»).
          • –2
            Да, про перепечатывание совет хороший. Всегда так делал, когда только начинал программировать. Хотя и сейчас так делаю иногда.
            • 0
              Я сначала просто читаю, просто подряд не зацикливаясь особо понял или нет. Потом перечитываю, текст уже знаком. Бывает что-то рассматривается и никак в голове не указывается, а через пару глав это всё разъясняется и само встаёт на свои места. Поэтому сначала быстро прочитываю, не проглядываю, а прочитываю, а затем читаю внимательно. Бывает перечитываю больше двух раз.
              • 0
                аналогично) ибо если не в теме, даже не знаешь, какую задачу ставить.
                1) читаю поверхностно, особо не вникая. Ток примечаю главные идеи. Отмечаю маркером, моменты, кот. показались важными. Понял, о чём вообще в книге, где что смотреть.
                2) перечитываю несколько раз пока не пойму, спокойно и вдумчиво. Важные места уже отмечены маркером.

                Вообще ещё обстановка при чтении важна. Чтоб никто не отвлекал и тп. Читаю в метро — никуда не деться, не отвлечься на удовольствия.
                • 0
                  У меня так не получается. Если начинаю читать незнакомую тему бегло — теряю суть и мысли уходят в сторону. Через время ловлю себя на том, что часть текста просто «просмотрена».
                  Наиболее эффективно, с точки зрения «минимум времени-максимум эффективности», получается:
                  • максимально вникая прочитать главу (или её подраздел). При этом отмечая что необходимо законспектировать;
                  • второй заход — быстро пробежаться по прочитанному, останавливаясь на конспектирование важных моментов. Часто получается так, что при конспектировании разъясняются непонятые участки. А бывает, как вы написали, что-то разъясняется через несколько глав. Конспект в этом случае помогает, не отвлекаясь от текущей темы, вспомнить основные моменты необходимого участка текста.

                  Еще, как правило, некоторое время приходится привыкать к стилю изложения автора.
                • 0
                  Ох уж эти программисты, и тут алгоритм выдумали!
                  • –1
                    Настоящие программисты думают алгоритмами всегда.
                    Например, как лучше идти, по левой или по правой стороне дороги, чтобы быстрее добраться до дома?
                    Сколько светофоров по пути домой, с какой скоростью надо ехать, идти, чтобы минимизировать стояние на светофорах?

                    Как ускорить алгоритм ухода ко сну :)
                    Как ускорить поход по магазинам на 10 минут.

                    и тп :)
                    Эти мысли — это ежедневность.

                    • +1

                      Хороший пример — смотрит настоящий программист "Побег из Шоушенка" или "Полёт над гнездом кукушки" читает и думает — ах, как бы оптимизировать и ускорить побег — ну там, ускорить рытьё туннеля изменив алгоритм копания, оптимизировать инструмент, применить социнженерию к охране и санитарам… так усиленно думает, что забывает даже про свою жену или девушку.)

                  • +1
                    Бюзан "Супермышление", Learn Ruby the hard way....

                    Сергей Поварнин — Как читать книги — 1924 год.

                    • 0
                      В целом ничего нового, много книг нынче содержат задачки после каждой главы. Это действительно эффективнее.
                      • 0
                        Кажется, наиболее действенный алгоритм — обращаться к литературе по мере необходимости, решая конкретные задачи.
                        • 0
                          1) Ставится задача.
                          2) Выбирается инструмент.
                          3) По мере выполнения задачи (возможно, с первых шагов), ищем в книге ответы.
                          После такого алгоритма хорошие книги станут настольными. Плохие отвалятся очень быстро.
                          У меня так Фаронов стал настольной книгой по программированию на Паскале, а Джеффри Рихтер — по C++ под Windows.

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