Чтение технических текстов: документация, статьи, книги

Чтение — основной канал, по которому в голову инженера попадает новое. Не курсы, не конференции, не менторы: документация, исходники, RFC, статьи, треды в issue, книги. По количеству времени это, скорее всего, самая большая статья расхода в вашем обучении.

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

Отсюда две задачи этой главы, и ни одна из них не звучит как «читать быстрее».

Первая — отбор и режим. Технические тексты — это не один жанр. Справочник по API, RFC, статья с конференции и книга на четыреста страниц требуют разного обращения, и ошибка режима стоит дороже, чем медленное чтение. Читать RFC как книгу — потеря дня. Читать книгу как справочник — потеря книги.

Вторая — что делать с текстом, пока и после того, как вы его читаете, чтобы прочитанное оказалось в голове, а не в закладках.

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

Что здесь известно, а что нет

Последняя строка — про бо́льшую часть главы. Это честно: контролируемых экспериментов «как инженеры читают RFC» не существует. Но у нас есть исследованные механизмы (извлечение, самообъяснение, роль предзнания), и практики ниже разобраны через них, а не через «у меня работает».

Чтение — это два разных действия

Первое, что стоит развести: найти ответ и построить модель.

• Поиск. У вас есть конкретный вопрос: какой таймаут по умолчанию, какая сигнатура у метода, что означает этот код ошибки. Успех — правильный ответ за минимальное время. Забыть его через час нормально и даже правильно.
• Построение модели. Вы хотите уметь предсказывать поведение системы в ситуациях, которых в тексте нет. Успех — способность ответить на вопрос, который в документе не задан, через месяц, без документа.

Это разные операции с разными метриками, и путать их дорого в обе стороны. Читать полностью то, что нужно один раз, — трата. Гуглить фрагмент десятый раз вместо получаса на устройство механизма — тоже трата, просто размазанная.

Обратите внимание на два ребра, которые чаще всего отсутствуют в реальной практике: Deep → Check и Apply → Check. Без первого рабочий проход заканчивается ощущением понимания вместо понимания. Без второго вы не узнаёте, что модель была неполной, — вы просто чините симптом и идёте дальше.

Что происходит при понимании текста

Полезная рамка — модель понимания дискурса Walter Kintsch и Teun van Dijk (1978, «Toward a Model of Text Comprehension and Production», Psychological Review), в более поздней версии — конструктивно-интеграционная модель Kintsch (1988, «The Role of Knowledge in Discourse Comprehension»).

В ней читатель строит три уровня представления:

1. Поверхностная форма — собственно слова и их порядок. Удерживается недолго.
2. Текстовая база — сеть пропозиций, извлечённых из текста. Это то, что можно пересказать «по тексту».
3. Ситуационная модель — представление о том, что описывает текст, собранное из текста и из уже имеющихся у вас знаний. Это то, из чего делаются выводы, которых в тексте не было.

Инженеру аналогия даётся легко: поверхностная форма — токены, текстовая база — AST, ситуационная модель — семантика в контексте вашего рантайма. Компилировать можно и без последней. Понимать — нет.

Практическое следствие ровно одно и оно важно: ситуационная модель строится из того, что у вас уже есть. Если базы нет, из текста получается текстовая база и ничего сверх. Это ощущается как «слова знакомые, а смысла нет» — знакомое состояние при первом чтении статьи по консенсусу или главы про модели памяти.

Это же объясняет, почему разбор в главе про перенос знания и чтение так тесно связаны: перенос требует ситуационной модели, а не текстовой базы.

Предварительное знание решает больше, чем навык чтения

Самая цитируемая демонстрация — Donna Recht и Lauren Leslie (1988), «Effect of Prior Knowledge on Good and Poor Readers’ Memory of Text», Journal of Educational Psychology.

Устройство: школьников разделили по двум независимым признакам — уровню навыка чтения (по стандартному тесту) и знанию бейсбола. Получилось четыре группы. Всем дали текст с описанием фрагмента бейсбольного матча и попросили воспроизвести и разыграть описанное на макете поля.

Результат: знание бейсбола объясняло результат лучше, чем навык чтения. Слабые читатели, разбирающиеся в бейсболе, обошли сильных читателей, в бейсболе не разбирающихся.

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

Что из этого следует инженеру.

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

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

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

Скорочтение: почему оно не работает

Это тот случай, где данных достаточно, чтобы говорить прямо.

Обзор: Keith Rayner, Elizabeth Schotter, Michael Masson, Mary Potter, Rebecca Treiman (2016), «So Much to Read, So Little Time: How Do We Read, and Can Speed Reading Help?», Psychological Science in the Public Interest (открытый доступ). Rayner — один из главных исследователей движений глаз при чтении, обзор написан на корпусе работ за несколько десятилетий.

Ключевые факты из обзора:

• Чтение состоит из фиксаций (порядка 200–250 мс, во время которых поступает информация) и саккад (быстрых скачков на 7–9 знаков, во время которых не поступает ничего).
• Перцептивный охват ограничен физически: полезная информация снимается примерно с 3–4 знаков влево и 14–15 знаков вправо от точки фиксации. Ограничение — острота зрения, падающая от центра сетчатки. Тренировкой это не расширяется.
• Около 10–15 % движений глаз — регрессии, возвраты к уже прочитанному. Они не дефект, а механизм починки неверно собранной фразы.
• Обычная скорость чтения с сохранением понимания — примерно 200–300 слов в минуту.
• Заявленные многократные ускорения достигаются за счёт понимания. Методы вроде RSVP (слова подаются в одну точку по очереди, глазам двигаться незачем) убирают возможность регрессий и упираются в ограничение рабочей памяти, а не глаз.

Вывод авторов сформулирован прямо: узкое место находится в разборе языка и построении смысла, а не в моторике глаз. Ускорить его нельзя, потому что оно не про глаза.

Что тогда реально даёт прирост. Три вещи, и все они не про скорость:

1. Знание темы (предыдущий раздел).
2. Решение не читать. Самая большая экономия — страницы, которые вы не открыли.
3. Просмотр как отдельная операция с ясной целью.

Про третье есть отдельное измерение: Geoffrey Duggan и Stephen Payne (2009), «Text Skimming: The Process and Effectiveness of Foraging Through Text Under Time Pressure», Journal of Experimental Psychology: Applied. При жёстком лимите времени просмотр текста охватывал важное содержание лучше, чем последовательное чтение с начала в том же бюджете. То есть просмотр — не испорченное чтение, а другая стратегия, разумная при дефиците времени.

Цена просмотра: вы теряете детали и — что хуже — не знаете, какие именно. Когда не окупается: нормативный текст. Пропущенное «MUST NOT» в спецификации стоит дороже сэкономленного часа.

Экран, бумага и калибровка

Небольшой, но методологически интересный сюжет.

Pablo Delgado, Cristina Vargas, Rakefet Ackerman, Ladislao Salmerón (2018), «Don’t Throw Away Your Printed Books: A Meta-Analysis on the Effects of Reading Media on Reading Comprehension», Educational Research Review — мета-анализ, показавший небольшое преимущество бумаги. Эффект сильнее при чтении под ограничением времени и на информационных, а не повествовательных текстах. Отдельно авторы отмечают, что разрыв не сокращался с годами, вопреки ожиданию «новые поколения привыкнут».

Virginia Clinton (2019), «Reading from Paper Compared to Screens: A Systematic Review and Meta-Analysis», Journal of Research in Reading — независимый мета-анализ того же направления с сопоставимым выводом.

Механизм подсказывает более раннее наблюдение: Rakefet Ackerman и Morris Goldsmith (2011), «Metacognitive Regulation of Text Learning: On Screen Versus on Paper», Journal of Experimental Psychology: Applied. При свободном режиме изучения на экране участники хуже распределяли время и переоценивали собственное понимание сильнее, чем на бумаге. При принудительном режиме разница уменьшалась.

Честная интерпретация: эффект маленький, модераторов много, и практический вывод из него — не «печатайте документацию». Вывод в том, что на экране ваша самооценка понимания завышена сильнее обычного, а она и так завышена (глава 3). Значит, для экранного чтения проверка извлечением нужнее, а не наоборот.

Пять жанров и что от каждого требовать

Полезная рамка для классификации документации — Diátaxis Дэниела Прочиды: четыре типа документов, различающихся не темой, а функцией — учебник (tutorial), руководство под задачу (how-to), справочник (reference) и объяснение (explanation). Оговорка обязательна: это фреймворк для авторов документации, контролируемых исследований его эффективности нет. Ценность для читателя — диагностическая: понять, какой тип документа у вас в руках, и не требовать от него того, чего он не даёт. В треке technical-writing рамка разобрана со стороны автора.

Расширим на технические тексты вообще.

Отдельный жанр — исходный код: он разобран в следующей главе.

Основная ошибка здесь — требовать от справочника объяснения. «Документация плохая, из неё ничего не понятно» часто означает «я открыл reference и ждал explanation». Иногда explanation и правда нет — тогда её роль выполняют исходники, тикеты и design docs, и это уже другой поиск.

Как выбрать режим: два вопроса

Решение о режиме сводится к двум вопросам: как долго проживёт это знание и нужна ли мне модель или хватит рецепта.

Точки расставлены по одному конкретному контексту — бэкенд на долгоживущем продукте. У встроенного разработчика или фронтендера картина сдвинута. Смысл диаграммы не в позициях, а в том, что позиция определяет режим чтения, а не важность темы. Модель памяти языка не «важнее» флагов CLI — она просто требует другого обращения.

Карту собственных пробелов относительно позиций удобно смотреть в разделе карты карьеры на портале; как из этого собирается план чтения — в главе 15.

Многопроходное чтение

Идея одна: не пытаться извлечь всё за один линейный проход, а идти несколькими проходами с разными целями и с ранним отсевом.

Схема Кешава для научных статей

S. Keshav (2007), «How to Read a Paper», ACM SIGCOMM Computer Communication Review (PDF) — две страницы, которые стоит прочитать целиком. Это не результат исследования, а систематизированный опыт исследователя; но схема хороша тем, что у каждого прохода есть критерий выхода, а не только описание.

Три детали, которые чаще всего теряют при пересказе этой схемы:

• «Выбросить» — основной исход. Схема оптимизирует не глубину, а отсев. Если у вас после первого прохода отсеивается меньше половины, вы либо слишком хорошо отбираете статьи на входе, либо не отсеиваете вовсе.
• Критерий выхода второго прохода — пересказ при закрытом источнике. Это ровно практика извлечения, встроенная в схему. Пересказ при открытой статье критерием не является.
• Третий проход — реконструкция, а не внимательное перечитывание. Вы пытаетесь построить работу заново с теми же допущениями. Это желательная трудность в чистом виде.

«Как читать книгу» и почему это не то же самое

Mortimer Adler и Charles Van Doren, «How to Read a Book» (издание 1972 года, первое — 1940) — классика с четырьмя уровнями: элементарное, инспекционное, аналитическое и синоптическое чтение. Инспекционное — систематический просмотр целого перед погружением; синоптическое — чтение нескольких источников по одной теме как единого спора.

Статус: это метод, а не результат эксперимента. Контролируемых сравнений «читал по Адлеру» против «читал обычно» я назвать не могу. Полезность инспекционного прохода при этом хорошо согласуется с механизмом: он создаёт каркас, в который потом укладываются детали, — то же самое, о чём говорит модель Kintsch. Но «согласуется с механизмом» — не «доказано».

SQ3R и родственные схемы

SQ3R (Survey, Question, Read, Recite, Review) — Francis Robinson, «Effective Study», 1946. Схема пережила восемь десятилетий и попала в бесчисленные учебные пособия.

Честно: убедительной контролируемой базы у SQ3R как целостного метода я привести не могу. В обзор Dunlosky и коллег (2013) он не входил. Отдельные компоненты проверены сами по себе, и как раз они и работают: Question — это предварительные вопросы, Recite — извлечение, Review — распределённое повторение. То есть полезное в SQ3R — это упаковка приёмов, у которых своя доказательная база. Аббревиатура ничего не добавляет.

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

Приёмы во время чтения, у которых есть база

Самообъяснение

Самый прямо применимый к техническим текстам приём с реальными данными.

Michelene Chi, Miriam Bassok, Matthew Lewis, Peter Reimann, Robert Glaser (1989), «Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems», Cognitive Science. Наблюдение за студентами, изучающими проработанные примеры по механике. Различие между успешными и неуспешными оказалось не в количестве времени, а в том, что успешные проговаривали объяснения себе: почему здесь этот шаг, что из чего следует, где границы. Неуспешные читали примеры и переходили к задачам.

Chi, Nicholas de Leeuw, Mei-Hung Chiu, Christian LaVancher (1994), «Eliciting Self-Explanations Improves Understanding», Cognitive Science — уже не наблюдение, а вмешательство: студентов просили объяснять себе каждое предложение текста про кровеносную систему. Группа с самообъяснением показала лучший результат, особенно на вопросах, требующих вывода за пределы текста.

Мета-анализ: Bisra, Liu, Nesbit, Salimi, Winne (2018), «Inducing Self-Explanation: A Meta-Analysis», Educational Psychology Review — эффект в районе половины стандартного отклонения, что для учебного вмешательства существенно.

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

Цена. Замедление в два-три раза. Это не преувеличение: страница спецификации с честным самообъяснением занимает не пять минут, а пятнадцать-двадцать.

Когда не окупается. На справочном материале — объяснять себе сигнатуру метода нечего. На тексте, по которому у вас нет базы: без знаний самообъяснение вырождается в правдоподобные выдумки, и вы закрепите неверную модель. Признак — ваши объяснения звучат гладко и не содержат ни одного «не знаю».

Уточняющие вопросы

Elaborative interrogation: вместо принятия утверждения задавать «почему это так, а не иначе?». Линия исследований идёт от Michael Pressley, Mark McDaniel и коллег (1987, «Generation and Precision of Elaboration», JEP: Learning, Memory, and Cognition).

В обзоре Dunlosky, Rawson, Marsh, Nathan, Willingham (2013), «Improving Students’ Learning With Effective Learning Techniques» (открытый доступ) приём получил умеренную оценку полезности — вместе с самообъяснением, ниже практики извлечения и распределённой практики.

Границы, которые называют сами авторы обзора: большинство работ — на отдельных фактических утверждениях, а не на связных сложных текстах, и эффект сильно зависит от наличия базовых знаний.

У инженера это выглядит как чтение с постоянным вопросом «почему не иначе»: почему в этом протоколе подтверждение отправляется до записи, а не после; почему в этом API идентификатор строка, а не число; почему в этом стандарте значение по умолчанию именно такое. Часть ответов есть в тексте, часть — в истории решения, часть отсутствует, и это тоже информация.

Предварительные вопросы

Прочитать вопросы до текста — и, что важно, попытаться на них ответить, заведомо не зная ответа. Это уже знакомый по главе 6 эффект предварительного тестирования: Lindsey Richland, Nate Kornell, Liche Kao (2009), «The Pretesting Effect: Do Unsuccessful Retrieval Attempts Enhance Learning?», JEP: Applied. Неудачная попытка перед объяснением улучшает последующее усвоение.

Shana Carpenter и Alexandra Toftness (2017), «The Effect of Prequestions on Learning from Video Presentations», Journal of Applied Research in Memory and Cognition — тот же эффект на видеолекциях.

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

У инженера это ровно та ситуация, когда вы приходите к документации с конкретным вопросом от задачи. Такое чтение и правда даёт больше, чем чтение «чтобы ознакомиться», — и теперь понятно, почему.

И два приёма, которые не работают

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

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

Ключевое различение: конспект при открытом тексте — это переписывание. Восстановление содержания при закрытом — это извлечение, и это уже другой приём с другой доказательной базой. Разница ровно в том, откуда идёт поток символов. Подробнее про заметки как инструмент — глава 13 и разбор систем заметок в треке по тайм-менеджменту, где прямо сказано, что контролируемых исследований эффективности этих систем нет.

Про формат: рисунок и текст должны быть рядом

Эффект разделённого внимания (split-attention): Paul Chandler и John Sweller (1991), «Cognitive Load Theory and the Format of Instruction», Cognition and Instruction. Когда для понимания нужно мысленно совмещать два разнесённых источника — текст на одной странице, схема на другой, — часть рабочей памяти уходит на удержание и совмещение, а не на обучение.

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

Документация: что делать конкретно

Дальше идёт отраслевая практика. Контролируемых исследований по чтению технической документации инженерами я не знаю; ниже — приёмы, разобранные через уже описанные механизмы. Оценивайте соответственно.

Прочитать оглавление целиком — один раз. Не содержание, а оглавление. Цель — знать, что в документации есть, чтобы потом искать не в поисковике, а в конкретном разделе. Это дешёвая операция: пятнадцать минут на крупный продукт. Она даёт каркас, в который потом ложатся детали.

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

Читать changelog и deprecations, а не только текущую версию. Список изменений — самый плотный по информации документ проекта. Он показывает, что авторы считают ошибкой в прошлом дизайне, и это чаще всего именно то, на чём вы споткнётесь.

Искать в тексте границы. Три вещи, которые надо целенаправленно вылавливать и которые почти никогда не выделены:

• что явно запрещено;
• что не определено — «поведение зависит от реализации», «порядок не гарантируется»;
• что гарантируется только при условии.

Неопределённое поведение — это места, где живут будущие баги. Реальный пример: в документации PostgreSQL по уровням изоляции прямо написано, что запрошенный уровень Read Uncommitted работает как Read Committed — грязных чтений в этой СУБД просто нет. Из стандарта SQL это не следует, из названия уровня — тем более. Такие абзацы читаются за десять секунд и экономят дни.

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

Цена: обзорный проход по документации среднего продукта — от двух до шести часов. Когда не окупается: инструмент на один раз; продукт, который вы, скорее всего, замените через квартал; документация, которая заведомо отстала от кода — тогда источником истины становятся исходники.

Спецификации и RFC

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

Нормативный язык — это система типов. RFC 2119 (Scott Bradner, 1997, «Key words for use in RFCs to Indicate Requirement Levels», rfc-editor.org/rfc/rfc2119), уточнённый RFC 8174 (2017: ключевые слова нормативны только в верхнем регистре), задаёт значения MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY.

Ловушка в SHOULD. В обиходной речи это «желательно». В RFC 2119 это означает: в отдельных обстоятельствах требование можно проигнорировать, но полные последствия должны быть поняты и взвешены. То есть SHOULD — это MUST с обязательным обоснованием отклонения, а не рекомендация. Читать спецификацию, не зная этого, — читать другой документ.

Цепочка версий. Прежде чем читать, проверьте шапку: Obsoletes, Updates, Obsoleted by. Спецификации не правят — их заменяют.

Практический смысл картинки: ссылка на RFC 2616 в чьём-то блог-посте 2013 года не просто устарела — она указывает на документ, который два раза заменяли целиком. Про сам протокол — глава про HTTP в треке по сетям.

Errata — отдельный слой. Опубликованный RFC неизменяем, а ошибки в нём фиксируются в отдельном реестре на rfc-editor.org. Проверять стоит, если вы реализуете спецификацию, а не читаете её для общего понимания.

Грамматика. Синтаксис в IETF-документах задаётся формально, через ABNF (RFC 5234). Читать нормативную часть, не глядя в грамматику, — то же самое, что читать код, не глядя на типы. Держите грамматику открытой рядом (см. выше про разделённое внимание).

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

Приём: превратить спецификацию в проверяемые утверждения. Отраслевая практика без исследовательской базы, но механизм понятен — это генерация вместо узнавания. Читая раздел, выписывайте не конспект, а таблицу: условие → что обязан сделать отправитель → что обязан сделать получатель → что происходит при нарушении. Дальше по строкам пишутся тест-кейсы. На выходе вы получаете и артефакт, и проверку понимания: строки, которые не заполняются, — это места, которые вы не поняли, и они видны сразу.

Проверка усвоения: сформулировать, что стандарт разрешает, а ваша реализация не делает. Если сформулировать нечего — вы, скорее всего, читали невнимательно: расхождения есть почти всегда.

Цена. Серьёзная спецификация — это дни. RFC 9110 — сотни страниц. Когда не окупается: если вы пользуетесь готовой библиотекой и не ловите странных багов на границе. Читать стандарт стоит, когда вы реализуете, отлаживаете совместимость или проектируете поверх.

Языковая сторона чтения спецификаций — в главе про спецификации и RFC трека engineering-english; там разбирается, как устроен английский нормативных документов.

Научные статьи

Три прохода по Кешаву описаны выше. Добавлю два слоя, которых в его заметке нет.

Как оценивать доказательность, а не убедительность

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

• Есть ли контрольное условие, и что именно с чем сравнивали? Формулировка «метод показал 92 % точности» без базовой линии не значит ничего.
• Отложенное измерение или сразу после вмешательства? В психологии обучения это критично: эффекты расходятся в разные стороны в зависимости от момента замера.
• Размер выборки и способ набора. Тридцать студентов одного вуза — это пилот, а не основание.
• Раздел Limitations. Обычно самый информативный в статье. Авторы сами перечисляют, куда результат не переносится.
• Воспроизводился ли результат независимо. Одна публикация — гипотеза.
• Артефакты: есть ли код, данные, скрипты. В CS это отчасти решается процедурой artifact evaluation на конференциях.
• Кто финансировал и кто авторы. Не для дисквалификации, а для калибровки.

Ошибки рассуждения, на которых легче всего попасться при чтении результатов, разобраны в треке logic — особенно в главах про причинные и статистические ошибки и про научное и инженерное рассуждение.

Специфика computer science

• Основной канал публикации — конференции, а не журналы, и уровень рецензирования на топовых конференциях выше, чем в среднем журнале. Знание иерархии площадок экономит время на отсеве.
• Много препринтов на arXiv без рецензирования вообще. Это не значит «плохо», это значит «фильтра не было».
• Бенчмарки выбирают. Утверждение о превосходстве метода часто держится на конкретном наборе данных и конкретной настройке базовой линии. Смотрите не на итоговую таблицу, а на то, как настраивали то, с чем сравнивают.
• Для работ про модели полезен контекст из трека ai-basics: без понимания устройства модели статья про её поведение читается как набор утверждений, которые нечем проверить.

Цена. Первый проход — 5–10 минут. Полное чтение серьёзной статьи с реконструкцией — рабочий день. Когда не окупается: почти всегда, если статья не относится прямо к тому, что вы делаете или собираетесь делать. Это нормально. Отсев — часть метода, а не его провал.

Технические книги

Книга даёт то, чего не даёт никакой другой формат: длинную связную аргументацию, которую нельзя нарезать на посты. Устройство транзакций, теория типов, эволюция архитектурного стиля — темы, где половина ценности в порядке изложения и в том, как одно опирается на другое.

Она же дороже всех: серьёзная книга — 15–40 часов чтения, и это без практики.

Обзорный проход обязателен и стоит 30 минут. Оглавление целиком, предисловие (там обычно прямо написано, кому книга адресована и что предполагается известным), введение и заключение, выборочно — первые абзацы глав. После этого вы знаете, какие главы вам нужны, а какие нет. Часто выясняется, что нужны три.

Читать под задачу. Глава, прочитанная за неделю до того, как понадобилась, забудется; глава, прочитанная в момент, когда вы упёрлись в проблему, которую она решает, — нет. Это не гипотеза о мотивации, а следствие уже описанного: у вас есть контекст, в который её укладывать, и есть немедленная возможность применить.

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

Что делать с главой, чтобы она не осталась приятным воспоминанием. Одно упражнение на главу: применить изложенное к системе, которую вы знаете. Не «сделать конспект» — применить. Для книги по проектированию БД это разбор реальной схемы; для книги по конкурентности — найти в своём коде место, где описанная проблема воспроизводится или где её нет и надо понять почему.

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

Что делать с прочитанным

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

1. Закрыть источник и восстановить. Не пересказ вслух с открытой вкладкой. Закрыть, записать или проговорить основное, потом сверить. Расхождения — это и есть то, что вы не знали.
2. Один вопрос вместо конспекта. После рабочего прохода сформулируйте один вопрос, ответ на который требует построенной модели, и отложите его на неделю. Один хороший вопрос полезнее десяти страниц выписок — потому что вопрос требует извлечения, а выписки требуют перечитывания.
3. Отложить проверку. Немедленная проверка измеряет доступность, а не прочность (глава 5). Осмысленный горизонт — дни и недели.
4. Проверить перенос на своей системе. Финальный критерий того, что текст усвоен: вы можете сказать, что из прочитанного меняет ваши решения, и в чём конкретно. Если ответ «ни в чём» — либо текст был не нужен, либо усвоена текстовая база, а не ситуационная модель.

Что из этого стоит фиксировать в заметках, а что нет — глава 13.

ИИ и чтение

Полный разбор — в главе 14. Здесь только то, что относится к чтению.

Где помогает, не отнимая обучения:

• Навигация. «В каком разделе спецификации описано поведение при повторной отправке?» — это поиск, и он законно ускоряется.
• Языковой барьер. Разбор тяжёлой английской фразы. Про язык технических документов подробно — трек engineering-english.
• Терминология. Быстрое объяснение незнакомого термина, чтобы не терять нить.
• Генерация вопросов к тексту. Попросить модель составить вопросы по разделу — и отвечать на них самому, при закрытом источнике. Здесь ИИ производит именно то, что вам нужно и что скучно делать вручную.
• Проверка вашего пересказа. Вы пересказываете по памяти, модель сверяет с текстом и указывает на пропуски. Это обратная связь (глава 9), а не подмена работы.

Где отнимает:

• Пересказ вместо первого прохода. Вы получаете чужую ситуационную модель — сжатую, гладкую и не вашу. Ровно ту работу, которая строит понимание, модель выполнила за вас. По результату это близко к перечитыванию: ощущение знания есть, знания нет.
• Ответы вместо чтения нормативного текста. Сводка спецификации теряет модальности. «Сервер должен вернуть 400» — а в тексте было SHOULD, и это другой смысл.

Отдельный риск: уверенная неточность именно в тонких местах. Пересказ тем надёжнее, чем банальнее содержание. Там, где формулировка нагружена — граничные условия, исключения, взаимодействие требований, — вероятность искажения выше всего, а проверить его вы не можете, потому что источник не читали. Про то, как это устроено, — ai-basics; про построение проверок — ai-agents.

Рабочее правило, короткое: модель может задавать вам вопросы по тексту, искать в нём места и проверять ваш пересказ. Она не должна отвечать на вопросы вместо вас, если вы собирались этот текст выучить.

Типичные ошибки

1. Читать всё в одном режиме. Обычно это «внимательно и подряд» — режим, разумный для книги и катастрофический для спецификации и статьи.
2. Пытаться ускорить чтение вместо того, чтобы сократить объём. Данные по физиологии чтения закрывают этот путь. Открытый путь — не открывать половину текстов.
3. Не отсеивать. Первый проход существует для того, чтобы выбросить. Если вы дочитываете всё, что начали, вы не выбираете, а обслуживаете очередь.
4. Перечитывать непонятный абзац в третий раз. После второго раза проблема, скорее всего, не в абзаце, а в отсутствующей базе. Спуститесь на уровень ниже.
5. Подчёркивать и конспектировать при открытом источнике. Ощущение работы высокое, эффект низкий, а маркированный текст потом перечитывают.
6. Читать reference, ожидая explanation. И делать вывод, что документация плохая.
7. Читать спецификацию как рекомендацию. SHOULD — не «желательно». Незнание нормативного языка меняет смысл документа целиком.
8. Не проверять актуальность документа. Заголовок RFC с Obsoleted by, документация от предыдущей мажорной версии, книга по фреймворку четырёхлетней давности.
9. Заканчивать чтением. Прочитано — не значит усвоено; без извлечения при закрытом источнике вы не знаете, что осталось.
10. Отдавать первый проход модели. Экономится время, теряется ровно то, ради чего вы читали.

Мини-итог

• Чтение — основной канал ввода, но ввод не равен обучению. Задача главы — выбрать режим под жанр и встроить в чтение извлечение.
• Понимание текста строится в три слоя (Kintsch и van Dijk, 1978; Kintsch, 1988); работает и переносится только верхний — ситуационная модель, и собирается она из уже имеющихся знаний.
• Поэтому предзнание решает больше, чем навык чтения (Recht и Leslie, 1988). Практический вывод: непонятный текст — чаще сигнал спуститься на уровень ниже, чем перечитать.
• Скорочтение не работает: ограничение в разборе языка, а не в глазах (Rayner и др., 2016). Перцептивный охват и регрессии — физиология, а не привычка. Просмотр под жёстким лимитом времени — рабочая стратегия (Duggan и Payne, 2009), но не для нормативных текстов.
• Бумага немного лучше экрана (Delgado и др., 2018; Clinton, 2019), эффект маленький; важнее то, что на экране самооценка понимания завышена сильнее (Ackerman и Goldsmith, 2011).
• Приёмы с базой: самообъяснение (Chi и др., 1989, 1994; мета-анализ Bisra и др., 2018), уточняющие вопросы (умеренная оценка у Dunlosky и др., 2013), предварительные вопросы (Richland и др., 2009), извлечение при закрытом источнике.
• Приёмы без базы: подчёркивание, конспект при открытом источнике (низкая оценка там же), SQ3R как целостная схема.
• Многопроходное чтение — метод, а не результат эксперимента. Ценность схемы Кешава (2007) не в трёх проходах, а в критериях выхода и в том, что основной исход — отсев.
• Пять жанров требуют пяти режимов. Главная ошибка — требовать от справочника объяснения.
• В спецификациях: нормативный язык (RFC 2119 и 8174) — система типов; цепочка Obsoletes и errata определяют, тот ли документ вы читаете; Security Considerations — готовая модель отказов; проверка усвоения — расхождение стандарта и вашей реализации.
• ИИ законно ускоряет навигацию, снятие языкового барьера и генерацию вопросов. Пересказ вместо первого прохода отдаёт наружу ровно ту работу, которая строит понимание, и искажает именно тонкие места.
• Финальный критерий любого чтения: что из прочитанного меняет ваши решения и в чём именно.

Источники

• Walter Kintsch, Teun A. van Dijk. Toward a Model of Text Comprehension and Production. Psychological Review, 1978.
• Walter Kintsch. The Role of Knowledge in Discourse Comprehension: A Construction-Integration Model. Psychological Review, 1988.
• Donna R. Recht, Lauren Leslie. Effect of Prior Knowledge on Good and Poor Readers’ Memory of Text. Journal of Educational Psychology, 1988.
• Keith Rayner, Elizabeth R. Schotter, Michael E. J. Masson, Mary C. Potter, Rebecca Treiman. So Much to Read, So Little Time: How Do We Read, and Can Speed Reading Help? Psychological Science in the Public Interest, 2016. Открытый доступ
• Geoffrey B. Duggan, Stephen J. Payne. Text Skimming: The Process and Effectiveness of Foraging Through Text Under Time Pressure. JEP: Applied, 2009.
• Pablo Delgado, Cristina Vargas, Rakefet Ackerman, Ladislao Salmerón. Don’t Throw Away Your Printed Books: A Meta-Analysis on the Effects of Reading Media on Reading Comprehension. Educational Research Review, 2018.
• Virginia Clinton. Reading from Paper Compared to Screens: A Systematic Review and Meta-Analysis. Journal of Research in Reading, 2019.
• Rakefet Ackerman, Morris Goldsmith. Metacognitive Regulation of Text Learning: On Screen Versus on Paper. JEP: Applied, 2011.
• Michelene T. H. Chi, Miriam Bassok, Matthew W. Lewis, Peter Reimann, Robert Glaser. Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems. Cognitive Science, 1989.
• Michelene T. H. Chi, Nicholas de Leeuw, Mei-Hung Chiu, Christian LaVancher. Eliciting Self-Explanations Improves Understanding. Cognitive Science, 1994.
• Kiran Bisra, Qing Liu, John C. Nesbit, Farimah Salimi, Philip H. Winne. Inducing Self-Explanation: A Meta-Analysis. Educational Psychology Review, 2018.
• Michael Pressley, Mark A. McDaniel, James E. Turnure, Eileen Wood, Maheen Ahmad. Generation and Precision of Elaboration: Effects on Intentional and Incidental Learning. JEP: Learning, Memory, and Cognition, 1987.
• Lindsey E. Richland, Nate Kornell, Liche Sean Kao. The Pretesting Effect: Do Unsuccessful Retrieval Attempts Enhance Learning? JEP: Applied, 2009.
• Shana K. Carpenter, Alexandra B. Toftness. The Effect of Prequestions on Learning from Video Presentations. Journal of Applied Research in Memory and Cognition, 2017.
• John Dunlosky, Katherine A. Rawson, Elizabeth J. Marsh, Mitchell J. Nathan, Daniel T. Willingham. Improving Students’ Learning With Effective Learning Techniques. Psychological Science in the Public Interest, 2013. Открытый доступ
• Paul Chandler, John Sweller. Cognitive Load Theory and the Format of Instruction. Cognition and Instruction, 1991.
• S. Keshav. How to Read a Paper. ACM SIGCOMM Computer Communication Review, 2007. PDF
• Mortimer J. Adler, Charles Van Doren. How to Read a Book. Revised edition, Touchstone, 1972.
• Francis P. Robinson. Effective Study. Harper & Brothers, 1946 — первоисточник схемы SQ3R.
• Daniele Procida. Diátaxis: A Systematic Approach to Technical Documentation Authoring. diataxis.fr
• Scott Bradner. Key Words for Use in RFCs to Indicate Requirement Levels. RFC 2119, 1997. rfc-editor.org
• Barry Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. RFC 8174, 2017. rfc-editor.org
• Dave Crocker, Paul Overell. Augmented BNF for Syntax Specifications: ABNF. RFC 5234, 2008. rfc-editor.org
• Roy Fielding, Mark Nottingham, Julian Reschke. HTTP Semantics. RFC 9110, 2022. rfc-editor.org
• Реестр опечаток RFC. rfc-editor.org/errata
• Документация PostgreSQL, раздел про уровни изоляции транзакций. postgresql.org

Что дальше

Всё, что разобрано выше, относится к текстам, которые кто-то написал для чтения. Основной же источник, из которого инженер учится в реальности, для чтения не предназначен вовсе: чужой код и собственные рабочие задачи. Там нет ни аннотации, ни оглавления, ни раздела с ограничениями, зато есть свойство, которого нет ни у одного текста, — исполнимость: гипотезу о том, как это работает, можно проверить за секунды, а не искать подтверждение в словах.

Учиться на чужом коде и внутри рабочих задач