Чтение документации: как устроен технический английский

Посчитайте честно, сколько английского текста вы прочитали за последнюю рабочую неделю. Страница документации библиотеки. Три ответа на Stack Overflow. Сообщение об ошибке в CI. Release notes перед обновлением зависимости. Changelog, в котором надо найти, что сломается. Комментарий в чужом коде. README форка, который кто-то предложил взять вместо оригинала. Скорее всего, это десятки тысяч слов — больше, чем вы прочитали по-русски о работе за то же время.

И почти никто из инженеров этому специально не учился. Английский из школы и университета — это разговорный английский: погода, планы на выходные, «Present Perfect против Past Simple». Технический английский устроен иначе: у него другая лексика, другой синтаксис, другой набор конструкций, зато он гораздо более предсказуем. Его можно освоить как формат данных — понять схему и дальше парсить быстро.

Эта глава — про чтение. Не про «пополнение словарного запаса», а про механику: как за секунду понять, страницу какого жанра вы открыли и чего от неё ждать; как разбирать цепочки из пяти существительных подряд; чем must отличается от should и почему это не вежливость; какие слова переворачивают смысл предложения, если их проглядеть; и что делать, когда слово незнакомое — лезть в словарь или ехать дальше. Дальше в треке эти же механизмы работают на письмо: сначала научиться видеть конструкции в чужом тексте, потом пользоваться ими в своём.

Честно про порог входа

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

Всё, что здесь написано, предполагает, что вы уже умеете читать простые английские предложения со словарём и примерно понимаете, где в предложении подлежащее, а где сказуемое. Это примерно уровень A2–B1 в чтении. Если английский текст для вас — сплошная непрозрачная стена, где непонятны не термины, а служебные слова (unless, otherwise, whether, rather than), то никакие приёмы чтения документации не помогут: вам нужен обычный курс английского или полгода систематической работы с учебником, и это честнее, чем делать вид, что «инженерный английский» — обходной путь.

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

Почему технический английский проще разговорного

Это не утешение, а измеримый факт, и полезно понимать, из чего он складывается.

Лексика ограничена и повторяется. В корпусной лингвистике есть старое наблюдение: около 2000 самых частотных семейств слов покрывают порядка 80% любого письменного английского текста (General Service List, Уэст, 1953; позже уточнён Полом Нейшном). Ещё 570 семейств академической лексики — Academic Word List Аверил Коксхед (2000) — добавляют примерно 10% в научных и технических текстах. Остальное — терминология предметной области, которую вы и так знаете по-русски: cache, deadlock, index, latency не нужно учить, нужно только связать со знакомым понятием. Итого: 2500 общих слов плюс уже известные термины дают почти полное покрытие страницы документации. Для сравнения, чтобы свободно смотреть кино, нужно 6000–9000 семейств плюс сленг, идиомы и культурный контекст.

Синтаксис намеренно упрощён. Техническую документацию давно пишут по правилам «управляемых языков». В авиации это формальный стандарт ASD-STE100 Simplified Technical English: около 900 разрешённых слов, одно значение на слово, запрет на пассив в инструкциях, ограничение длины предложения. В индустрии софта то же самое делают style guides: Google developer documentation style guide и Microsoft Writing Style Guide. Оба требуют коротких предложений, активного залога в инструкциях, единообразия терминов и запрещают синонимию: если объект называется bucket, он везде bucket, а не «container» и не «storage unit».

Структура повторяется от проекта к проекту. Страница reference почти всегда устроена одинаково: сигнатура, описание одним предложением, параметры, возвращаемое значение, исключения, примеры, «see also». Это позволяет читать не подряд, а по координатам.

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

Жанр страницы предсказывает её грамматику

Прежде чем читать, определите, что вы открыли. Самая полезная классификация — Diátaxis Даниэле Прочиды: четыре жанра документации, каждый со своей задачей. Практическая ценность для читателя в том, что жанр однозначно предсказывает язык страницы.

Tutorial («Getting started», «Your first app») ведёт за руку. Язык: императивы (Run the following command), местоимение we в значении «мы вместе сейчас сделаем», обещания (You should see a message like this). Читается легко, врать не может — если написано you should see, а вы не видите, что-то сломалось.

How-to («How to configure TLS») решает конкретную задачу у человека, который уже в контексте. Язык: императивы плюс условия (If your cluster uses an external CA, skip step 3). Здесь особенно опасно проглядеть условие: половина шагов относится не к вам.

Reference (API docs, конфиг-параметры, man-страницы) описывает, а не учит. Язык: настоящее время третьего лица (returns, raises, defaults to), плотные именные группы, пассив, максимум точности при минимуме слов. Это самый трудный для чтения жанр — и самый важный, потому что именно тут находится ответ на вопрос «что реально делает эта функция».

Explanation («Why we chose eventual consistency», design docs, ADR) объясняет причины. Язык: связки (because, however, on the other hand), сослагательное наклонение, hedging (tends to, in most cases). Здесь можно читать по диагонали, но именно здесь спрятаны ограничения, которых нет в reference. Про то, как такие документы пишут на своём проекте, — в главе про архитектурные решения.

Типичная ошибка новичка — читать reference так, будто это tutorial, и обижаться, что «непонятно объяснили». Reference не объясняет. Он фиксирует контракт.

Как читать страницу reference: три прохода

Reference не читают сверху вниз. Его читают тремя проходами, и порядок противоположен интуитивному.

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

Проход 2 — код и сигнатура, 30 секунд. Начните с примера кода и сигнатуры, а не с описания. Код — это язык, который вы знаете лучше английского. Часто половина вопросов снимается до чтения текста: видно порядок аргументов, тип возврата, обязательность параметров. Только после этого возвращайтесь к описанию — теперь у вас есть гипотеза, и вы читаете, чтобы её проверить или опровергнуть.

Проход 3 — прицельное чтение, столько, сколько нужно. Медленно и полностью читаются ровно три категории: (1) предложения с отрицанием и условием, (2) блоки Note/Warning, (3) абзац про поведение в граничных случаях. Всё остальное можно просмотреть.

# Тот же контракт, записанный двумя способами.
# Docstring в стиле reference: третье лицо, настоящее время, без «мы» и «вы».
def acquire(self, timeout: float | None = None) -> Connection:
    """Return a connection from the pool.

    Blocks until a connection becomes available or ``timeout`` seconds
    have elapsed. If ``timeout`` is None, blocks indefinitely.

    Raises:
        PoolTimeout: if no connection becomes available in time.
        PoolClosed: if the pool has already been closed.
    """

Разберём, что здесь сказано, по-русски и по частям:

• Return a connection — не «возвращает какое-то соединение из ниоткуда», а «отдаёт одно соединение из пула». Артикль a сигналит: одно из многих, какое именно — не ваше дело.
• Blocks until ... or ... have elapsed — два условия выхода. Слово until задаёт границу: до этого момента поток стоит. Если проглядеть Blocks, метод покажется неблокирующим.
• If timeout is None, blocks indefinitely — отдельное предложение для граничного значения. В reference почти всегда есть такая фраза; её пропуск — источник половины продовых зависаний.
• Raises — не «может выбросить, если не повезёт», а перечень объявленных в контракте исключений.

Сравните с тем, как то же самое звучало бы в tutorial: «Now let’s grab a connection from the pool. Don’t worry about the timeout for now — we’ll come back to it later.» Тот же факт, другой жанр, другая грамматика, другая степень обязательности.

Цепочки существительных: главный барьер

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

maximum connection pool idle timeout
default request retry backoff multiplier
per-tenant background job failure notification policy

Слова знакомые, а смысл ускользает — потому что русский разворачивает такую цепочку в другую сторону, через родительный падеж: «максимальный таймаут простоя соединений в пуле». Мозг пытается читать слева направо и на третьем слове теряет опору.

Правило разбора простое: ядро (head noun) — самое правое слово, всё остальное — определения к нему, и раскручивать надо справа налево.

Проверьте на втором примере: default request retry backoff multiplier. Ядро — multiplier, множитель. Множитель чего? backoff — задержки. Какой задержки? retry — между повторами. Повторами чего? request — запроса. Какой множитель? default — по умолчанию. Итог: «множитель нарастания задержки между повторами запроса, значение по умолчанию».

Третий пример разбирается так же: policy → политика → notification → уведомлений → failure → об отказах → background job → фоновых задач → per-tenant → в разрезе арендатора.

Два практических следствия:

1. Когда встречаете цепочку длиннее трёх слов — не читайте, а разбирайте по шагам. Пять секунд, потраченных на разбор, экономят минуту перечитывания.
2. Дефис — ваш друг. read-only file system и read only file system формально об одном, но дефис явно склеивает read-only в одно определение. Хорошая документация расставляет дефисы; в плохой их приходится домысливать.

Модальные глаголы: не вежливость, а сила требования

В разговорном английском must, should и may часто взаимозаменяемы и отличаются оттенком вежливости. В технической документации — нет. Это разные уровни обязательности, и различие формализовано в RFC 2119 и уточнено в RFC 8174.

Особенно коварно may. В The server may close the connection at any time это не «возможно, закроет» — это «имеет право закрыть, и вы обязаны быть к этому готовы». Отсюда прямое инженерное следствие: любое may со стороны системы означает, что вам нужен код на этот случай. А The client MAY retry означает, что ретраи разрешены, но не обязательны, — и сервер должен это выдерживать.

Отдельно про should в описании поведения (не требования): The call should complete within 100 ms — это не обещание, а ожидание автора. Планировать таймауты по такому предложению нельзя. Подробный разбор нормативного языка — в следующей главе про стандарты и RFC.

Артикли, которые несут смысл

В русском артиклей нет, поэтому глаз их проскакивает. В документации они регулярно несут техническую информацию, и её потеря меняет понимание контракта.

Returns a new list containing the matching elements.

a new list — новый список, каждый вызов создаёт новый объект. the matching elements — те самые элементы, которые подошли под ранее описанный критерий; определённость отсылает к предыдущему предложению. Если бы было Returns the list, это означало бы «возвращает тот самый список» — то есть, скорее всего, ту же ссылку, и мутация результата затронула бы оригинал. Одна буква — разница между копией и алиасом.

The connection is closed when the context is cancelled.

Оба the — про конкретные объекты из текущего контекста, а не про соединения вообще. Если бы речь шла об общем правиле, было бы Connections are closed… (нулевой артикль, множественное число — типичный способ формулировать общие законы в reference).

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

Пассив и безличность: кто на самом деле действует

Reference насыщен пассивом: is called, must be set, are ignored, has been deprecated. Style guides требуют активного залога в инструкциях, но описывать поведение системы пассивом удобно — субъект часто неважен или неизвестен.

Проблема в том, что пассив прячет исполнителя, а исполнитель — это ровно то, что вам нужно знать.

The callback is invoked after the transaction is committed.

Кем invoked? В каком потоке? Синхронно или нет? Предложение честно описывает порядок событий и умалчивает о механике. Это не небрежность автора — этого просто нет в контракте. Правильная реакция читателя: зафиксировать вопрос («в каком потоке вызывается коллбэк?») и искать ответ отдельно, а не додумывать.

Ещё одна безличная конструкция, которую стоит распознавать мгновенно:

It is the caller's responsibility to close the returned file object.

Формально — вежливая безличность, фактически — передача ответственности вам. Каждый раз, когда видите it is the caller's responsibility, the caller must ensure, ownership is transferred to, знайте: здесь потенциальная утечка ресурса, если вы не напишете код.

Слова-шарниры: маленькие, но переворачивают смысл

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

unless = «если только не». Самая частая ловушка, потому что содержит скрытое отрицание.

The value is cached unless the header is present.

Кешируется в обычном случае; наличие заголовка кеширование отключает. Читатель, проглядевший unless, поймёт ровно наоборот и потом полдня будет искать, почему кеш «не работает».

otherwise = «в противном случае» и вводит вторую половину правила.

Returns the value if the key exists; otherwise returns None.

Половина предложения после точки с запятой — это ветка else. В коде вы бы её не пропустили, в тексте — легко.

no longer = «больше не», состояние изменилось.

This option is no longer supported and is ignored.

Не «не поддерживается» вообще, а «раньше работало, теперь нет, и молча игнорируется». Второе важнее первого: ошибки не будет, будет тихое неправильное поведение.

fail to = «не сумеет», а не «упадёт».

If the client fails to renew the lease, the lock is released.

Речь не о падении клиента, а о том, что он по любой причине не продлил аренду.

at most / at least / up to — границы, которые задают контракт, и путать их дорого.

The queue delivers each message at least once.

At least once — «минимум один раз», то есть дубликаты возможны и обязаны обрабатываться. At most once — доставка может потеряться. Разница между этими двумя фразами — это разница между двумя разными архитектурами; подробности в главе про гарантии доставки.

rather than = «а не», выбор в пользу первого.

Use the async client rather than spawning threads.

Не «наряду», а «вместо». Русскоязычный глаз иногда читает rather как «скорее», получая размытую рекомендацию вместо чёткого указания.

only if против if only — первое сужает условие («только при условии, что»), второе вообще не используется в документации (это разговорное сожаление). Если увидели if only в технической прозе, скорее всего, это опечатка или неноситель.

Английский understatement: как переводить сдержанность в реальность

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

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

Отдельная категория — hedging, языковая страховка: tends to, in most cases, generally, by default, typically. Она не размывает смысл, а очерчивает область действия утверждения. Reads are generally consistent означает «в основном да, но есть описанные где-то ниже исключения» — и это приглашение найти, где именно.

Лестница предупреждений: что можно пропустить, а что нельзя

Блоки-врезки в документации не равнозначны, и у них есть устоявшаяся иерархия — она зафиксирована в Google style guide и в Microsoft style guide.

1. Note — дополнительный факт. Можно прочитать по диагонали.
2. Tip — необязательный совет, как сделать удобнее. Пропускается безболезненно.
3. Important — факт, без которого вы, скорее всего, сделаете неправильно. Читать.
4. Caution — можно потерять данные или получить неверный результат. Читать медленно.
5. Warning — можно сломать систему или получить дыру в безопасности. Читать дважды.
6. Danger — необратимые последствия. Встречается редко, обычно в железе и инфраструктуре.

Правило чтения: Note и Tip можно сканировать, всё, что начинается с Important, читается полностью и всегда. Именно в этих блоках живут ограничения, которые потом всплывают в инциденте.

Версии и время: язык устаревания

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

Как читать формулировки на каждом переходе:

• Experimental / Unstable / Alpha — контракта нет, сломать могут в минорной версии. Обычно сопровождается subject to change without notice.
• Available since 3.4 — появилось в 3.4, в 3.3 этого нет. Проверьте свою версию, прежде чем копировать пример.
• As of 4.2, the default changed to true — с версии 4.2 и далее. As of про начало действия, а не про момент написания текста.
• Prior to 4.2, this option was ignored — «до 4.2», не включая саму 4.2. Русское «до» неоднозначно, английское prior to — нет.
• Deprecated since 4.2 — работает, но помечено на удаление; часто печатает warning в логах. Это уже сигнал заводить задачу, а не «когда-нибудь потом».
• Will be removed in 5.0 — план. Removed in 5.0 — свершившийся факт. Разница во времени глагола, и она стоит вам мажорного апгрейда.
• Superseded by X / Use X instead — замена существует, миграция описана где-то рядом.
• Legacy — работает, поддерживается, но новых фич не будет. Не то же самое, что deprecated.
• Backwards-incompatible change / breaking change — читайте целиком и всегда, это единственная секция changelog, которую нельзя сканировать. Соглашение о номерах версий — semver.org; политика устаревания у зрелых проектов описана явно, как, например, release process у Django.

Практика на реальной задаче: перед обновлением зависимости откройте changelog и прочитайте только секции breaking changes и deprecations между вашей версией и целевой. Это 3–5 минут и примерно 80% пользы от чтения changelog.

Слова с техническим значением и ложные друзья

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

eventually — не «в конце концов, может быть», а «рано или поздно обязательно, но неизвестно когда».

Changes are eventually propagated to all replicas. Это гарантия, а не оговорка: изменения дойдут до всех реплик, срок не определён. Отсюда термин eventual consistency — см. модели согласованности.

actually — «на самом деле», а не «актуально».

The value is not actually written until flush is called. «На самом деле значение не записывается, пока не вызван flush». Ложный друг из первой десятки.

resolve — «разрешить, определить окончательное значение», а не «решить проблему».

The hostname is resolved at connection time. Имя хоста преобразуется в адрес в момент соединения. С resolve a conflict смысл ближе к привычному, но базовое значение — «привести к конкретному значению».

argument — «аргумент функции». Спор здесь ни при чём, и это одно из немногих мест, где английское слово уже, чем русское.

assert — «утверждать как инвариант», не «настаивать».

This method asserts that the buffer is not empty. Метод проверяет инвариант и падает, если он нарушен.

sanity check — грубая проверка на очевидную ошибку.

As a sanity check, verify that the counts match. Ни психиатрии, ни «проверки здравомыслия»: это «проверим, что не написали ерунды». В новых документах часто заменяют на basic check по соображениям инклюзивного языка.

expensive / cheap — про стоимость вычислений, не про деньги.

Sorting is an expensive operation on large collections.

naive — «прямолинейный, без оптимизаций», без осуждения.

The naive implementation is O(n²).

opinionated — «навязывающий свой способ делать вещи», обычно как достоинство.

The framework is opinionated about project layout. Означает «структуру проекта фреймворк диктует, спорить не получится».

graceful — «корректный, без резких обрывов».

The server performs a graceful shutdown, draining in-flight requests. Не «изящный»: сервер дорабатывает начатые запросы и только потом выключается.

stale — «устаревший, но всё ещё лежащий и притворяющийся валидным».

A stale cache entry may be returned while the value is being refreshed.

caveat — оговорка, ограничение. Секция Caveats — это то, о чём вы пожалеете, если пропустите.

gotcha — неочевидное поведение, на котором все спотыкаются. Неформально, но встречается даже в официальных доках.

edge case и corner case — граничный случай (один параметр на пределе) и угловой (несколько сразу). Различают их не все, но в спецификациях различие есть.

happy path — сценарий, где всё хорошо. Если документация описывает только его, ищите поведение при ошибках отдельно — см. сообщения об ошибках.

out of the box — «из коробки, без настройки». batteries included — «всё нужное уже внутри» (девиз стандартной библиотеки Python).

first-class — «полноправный, поддерживается наравне с остальным».

Functions are first-class values in Go.

nontrivial, arbitrary, deterministic, idempotent — эти четыре стоит знать точно, потому что они формулируют гарантии: «непростой», «любой, задаваемый пользователем», «одинаковый результат при одинаковом входе», «повторный вызов не меняет результат».

Ложные друзья, которые ловят почти всех: accurate — точный (а не аккуратный); complete — полный/завершённый; data — данные (и в современном техписьме обычно единственное число: the data is); library — библиотека кода (а не читальня); list — список (а не лист); magazine — журнал-издание, а store — магазин; original — исходный, первоначальный; intelligent — умный, а не интеллигентный; character — символ; figure — рисунок или цифра; abstract — реферат/аннотация в статьях.

Что делать с незнакомым словом

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

Два правила, которые из этого следуют.

Термины ищите в самой документации, а не в словаре. Если в доках Kafka встретилось rebalance, англо-русский словарь даст «перебалансировка» — бесполезно. Поиск по документации даст определение через понятия системы, и это и есть нужное знание. Хорошие проекты держат страницу Glossary или Concepts: Kubernetes, Rust, PostgreSQL.

Общие слова смотрите в толковом словаре с примерами, а не в переводчике. Cambridge Dictionary и Merriam-Webster дают значение плюс типичные сочетания. Перевод даёт одно слово без границ употребления — и потом это слово всплывает в вашем письме не в том значении.

Машинный перевод и языковые модели полезны как проверка гипотезы («я понял так — правильно?») и вредны как первичный способ чтения: если вы читаете перевод, вы не учитесь читать оригинал, а в терминах перевод регулярно врёт (replica set превращается в «набор реплик» и теряет статус термина).

Личный глоссарий вместо словарика

Списки слов не работают: они запоминаются как пары «слово — перевод» и разваливаются при первой же встрече в живом тексте. Работает другое — глоссарий употреблений.

Формат одной записи: термин, предложение из реального документа, откуда оно взято, и одна строка своими словами о том, что это значит в системе. Не перевод.

# glossary.yaml — фрагмент личного глоссария инженера
- term: backpressure
  seen_in: "https://doc.akka.io/ — Streams overview"
  quote: "The consumer signals backpressure when it cannot keep up."
  meaning: "механизм, которым медленный потребитель тормозит быстрого производителя"
  note: "в русском тексте обычно оставляют как есть, не переводят"

- term: to be superseded by
  seen_in: "changelog библиотеки, секция Deprecations"
  quote: "This API is superseded by the streaming API and will be removed in 6.0."
  meaning: "вытеснено более новым API, миграция обязательна до 6.0"
  note: "формальнее, чем replaced by — намекает, что старое ещё работает"

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

Практикум на реальных документах

Все задания выполняются на настоящей документации, а не на учебных текстах, и занимают 15–20 минут каждое.

1. Жанры. Откройте документацию PostgreSQL и найдите по одной странице каждого из четырёх жанров Diátaxis. Выпишите по одному предложению с каждой страницы и объясните, по каким грамматическим признакам вы определили жанр.
2. Цепочки. Возьмите страницу конфигурации любого инструмента, которым пользуетесь (nginx, Kubernetes, настройки JVM), выпишите пять именных цепочек длиной от трёх слов и разберите каждую справа налево.
3. Модальность. Откройте RFC 9110 на разделе про кеширование или коды ответов и найдите по три предложения с MUST, SHOULD и MAY. Для каждого ответьте: что произойдёт, если проигнорировать?
4. Устаревание. Возьмите changelog библиотеки, которую вы обновляли в этом году, и выпишите все формулировки про версии: since, as of, prior to, deprecated, removed. Сверьте своё понимание с фактическим поведением кода.
5. Understatement. Найдите в документации любимого фреймворка пять фраз вида not recommended, may not be what you want, use with care. Для каждой сформулируйте по-русски, что автор имел в виду на самом деле, и проверьте по issue tracker, были ли из-за этого реальные проблемы.

Типичные ошибки читателя

• Читать сверху вниз. Reference так не читают. Сигнатура и пример дают больше за меньшее время.
• Переводить в голове. Перевод удваивает работу и теряет термины. Цель — связка «английское слово → понятие», без промежуточного русского.
• Пропускать служебные слова. unless, otherwise, no longer, at most меняют смысл сильнее, чем любой термин.
• Читать may как вероятность. Это разрешение. Каждое may со стороны системы — требование к вашему коду.
• Игнорировать блоки Warning. Они там не для красоты; их пишут после инцидентов.
• Верить tutorial больше, чем reference. Tutorial упрощает, иногда до неправды. Контракт — только в reference.
• Останавливаться на каждом незнакомом слове. Темп важнее полноты: непонятое слово в наречии не стоит потери нити.
• Не проверять версию. Половина непонятных расхождений между документацией и поведением — это чужая версия страницы. Проверяйте селектор версии первым делом.
• Читать через машинный перевод. Приемлемо как костыль на старте, губительно как привычка: навык не растёт, а термины искажаются.

Мини-итог

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

Что стоит унести из главы:

• Определяйте жанр страницы до чтения — он предсказывает грамматику и степень обязательности написанного.
• Reference читайте тремя проходами: структура, код, прицельно.
• Цепочки существительных разбирайте справа налево: ядро всегда последнее.
• must, should, may, will — уровни требований, а не оттенки вежливости.
• Артикли несут контракт: a new list и the list — разные обещания.
• Слова-шарниры (unless, otherwise, no longer, at least once) читаются медленно и полностью.
• Английскую сдержанность калибруйте: not recommended означает «не делайте так».
• Незнакомое слово — не повод останавливаться; повод остановиться — незнакомое слово в условии или отрицании.
• Термины ищите в документации проекта, а не в словаре, и складывайте в глоссарий вместе с предложением.

Что дальше

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

Стандарты и RFC: язык нормативных документов