Ясность: почему инженерный английский проще разговорного

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

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

Что здесь считается ясностью

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

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

Почему потолок здесь ниже, чем в разговорном

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

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

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

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

Требуемая грамматика умещается в школьный курс. Present Simple, Past Simple, Present Perfect, модальные глаголы, условные первого типа, пассив. Ни инверсий, ни сослагательного третьего типа: они не добавляют точности, только места для ошибок.

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

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

Четыре уровня, на которых текст бывает неясным

Правка неэффективна, когда её делают хаотично: человек полирует артикли в предложении, которое надо целиком удалить.

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

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

Самая частая проблема русскоязычного автора — не ошибки, а длина предложения. В русской письменной норме период на 30–40 слов с двумя причастными оборотами читается как признак образованности; в английском рабочем тексте — как черновик.

Because the upstream service returns 503 during deploys and our policy does not retry them,
the checkout request fails.

Грамматически безупречно. Проблема в другом: читатель проходит 15 слов, не зная, о чём предложение. Подлежащее the checkout request появляется на 16-м слове, глагол fails — на 19-м, и всё это время придаточное висит в памяти без опоры.

The upstream service returns 503 during deploys.
Our retry policy does not treat 503 as retryable.
So the checkout request fails.

Слов стало на четыре больше — читать стало заметно легче. Отсюда ключевое наблюдение главы: ясность не равна краткости. Краткость — частый побочный эффект, но не цель. Три операции, в порядке отдачи.

1. Разрезать по второму сказуемому. Найдите все глаголы в личной форме; больше двух — почти всегда можно резать. Границы: and, but, which, because, while, точка с запятой.

2. Сделать подлежащим того, кто действует. Центральный принцип Джозефа Уильямса из книги Style: Lessons in Clarity and Grace: действующие лица — в подлежащее, их действия — в глаголы.

Плохо:  The implementation of the validation logic was completed by the team on Tuesday.
Хорошо: The team finished the validation logic on Tuesday.

В первом варианте деятель the team задвинут в конец, а место подлежащего занято абстракцией. Во втором 8 слов вместо 14, и ни одного потерянного факта.

3. Держать глагол рядом с подлежащим — между ними не должно помещаться придаточное.

Плохо:  The migration script, which we wrote last quarter and which has not been
        run in production since the schema change, fails on empty tables.
Хорошо: The migration script fails on empty tables. We wrote it last quarter and
        have not run it in production since the schema change.

Ориентир: средняя длина 15–20 слов, максимум около 30. Одно длинное предложение среди коротких полезно для ритма, три подряд — читатель начинает пропускать.

Порядок информации: главное первым

Второй по частоте дефект — правильный текст в неправильном порядке. Пишут в порядке, в котором думали: контекст, попытки, рассуждения, вывод. Читают наоборот: сначала вывод, дальше — только если он касается читателя лично.

Принцип известен как BLUF (bottom line up front, из практики военной переписки США) и как «перевёрнутая пирамида» в журналистике. Эмпирика чтения с экрана (Nielsen Norman Group) говорит то же: читают первые строки абзаца и первые слова строки, остальное сканируют.

Subject: Update

Hi team, I hope this email finds you well. I wanted to reach out and give you a quick update
regarding the current status of the work that has been done on the migration of the reporting
service to the new database cluster. Unfortunately, during the course of the implementation,
a number of issues were encountered in relation to the performance of certain queries, and it
was determined that additional investigation would be required in order to fully understand the
root cause of the degradation that was observed. At this point in time, our current thinking is
that it would probably make sense to consider postponing the cutover planned for Friday.

Около 120 слов, ни одной грамматической ошибки — и почти нет информации. Не названо, какие запросы, насколько медленнее, к какому сроку нужен ответ и что будет, если никто не ответит. Тема Update не сообщает ничего.

Subject: Reporting migration — proposing to move Friday's cutover to Sep 12

Decision needed by Wed 17:00 CET.

Three report queries run 8x slower on the new cluster (p95 2.4s vs 0.3s). We have not found the
cause yet — the query plan differs — and we need about two days to confirm.

I propose we move the cutover from Friday to Sep 12. Nothing else in the migration is blocked.
If you disagree, reply by Wednesday. Otherwise I will update the release calendar on Thursday.

66 слов вместо 120 — и информации стало больше: появились числа, срок, предложение и действие по умолчанию. Соотношение типичное: сокращение вдвое обычно вынуждает добавить факты, потому что после удаления оборотов видно, что фактов не было. Последняя строка отдельно: Otherwise I will update the release calendar on Thursday — это действие по умолчанию, превращающее письмо из запроса на обсуждение в механизм, который работает даже при молчании; про молчание и сроки — в главе про переписку.

Зомби-существительные: где прячется действие

Английский легко превращает глаголы в существительные: implement → implementation, fail → failure, validate → validation. Хелен Сворд назвала их zombie nouns: действие есть, но оно перестало быть действием, а на месте глагола оказалась пустышка вроде perform, conduct, provide.

Два признака ловятся регулярным выражением: суффиксы -tion, -ment, -ance, -sis рядом с пустым глаголом и предлог of сразу после такого существительного. Оговорка: номинализации не запрещены — они нужны, когда действие само стало объектом обсуждения (the migration is scheduled for Friday, this validation runs on every request). Проверка: рядом стоит содержательный глагол — всё в порядке; глагол пустой — действие спрятано.

Родственная беда — цепочки существительных вроде connection pool idle timeout configuration update. Как их читать, разобрано в главе про документацию; здесь обратная задача — не производить их самому. Правило: три существительных подряд — потолок, на четвёртом вставляйте предлог: update to the idle timeout of the connection pool.

Пассив: где он честен, а где прячет виноватого

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

Уместен:  The request is rejected if the signature does not match.   (нормативное правило)
          Tokens are stored in Redis with a 15-minute TTL.           (кто хранит — неважно)
          The endpoint was deprecated in v4.2.                       (деятель — история проекта)

Прячет:   It was determined that the rollback was necessary.         (кем определено?)
          Mistakes were made during the migration.                   (кем?)
          The config was changed on Friday.                          (кем и зачем?)

Первая тройка — нормальный язык reference и нормативных документов, про который есть глава про стандарты и RFC. Вторая — то, что называют past exonerative: mistakes were made опознаётся мгновенно как формула ухода от ответственности, известная по политическим извинениям. Критерий: если читатель может спросить «кем?» и ответ ему нужен — переписывайте в актив. Если «кем?» очевидно или не имеет значения, пассив лучше: короче и не заставляет придумывать формального деятеля. Отдельный случай — постмортемы, где пассив используют намеренно, чтобы разговор шёл о системе: the config change was not reviewed вместо Alex did not review the config change. Это не уход от ответственности, а культура blameless: ответственность там всё равно названа, но в виде «что чинит система», а не «кто виноват».

Слова, которые не делают работы

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

Не перегнуть здесь так же важно: полностью «обезжиренный» текст в переписке читается холодно. Разница в том, что вежливость несут отдельные короткие формулы (Thanks for the quick turnaround, No rush on this), а не длинные обороты внутри предложений; дозировка смягчения разобрана в главах про ревью и переписку. Попутно снимем частое опасение: короткое не значит грубое. Грубым текст делают приказ вместо просьбы и оценка человека вместо факта о работе — Review this today. резче, чем вдвое более длинное Could you review this today? The release is blocked on it.

Точность: числа вместо оценок, уверенность как факт

Усилители — very, really, extremely, significantly, quite — почти всегда сигнал, что автор не измерял.

Слабо:  The endpoint is very slow and this is a really big problem.
Точно:  The endpoint takes 12s at p99. The checkout page times out at 10s.

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

Последняя строка недооценена. Русскоязычные инженеры часто избегают признавать незнание письменно; в англоязычной инженерной культуре I don't know yet, I'll find out by X читается как профессионализм, а размытая формулировка, маскирующая незнание, — как ненадёжность. Самая дорогая ошибка раздела — подать гипотезу как факт: на ней построят решение.

Имена и списки

Один объект — одно имя. В художественном тексте повтор слова дефект, и школа учит искать синонимы. В техническом синоним — источник багов: если в абзаце user, customer, account holder и client, читатель обязан решить, четыре это сущности или одна, и решит неправильно.

Плохо:  The user submits the form. The customer's data is then validated, and the client
        receives a confirmation.
Хорошо: The user submits the form. We validate the user's data and send a confirmation to the user.

Три повтора user — не бедность языка, а гарантия. То же с именами компонентов, статусов и параметров: если объект называется bucket, он везде bucket; в домене, описанном через DDD, тот же приём называется единым языком.

Параллелизм в списках. Все пункты должны быть одной грамматической формы.

Плохо:                             Хорошо:
  - Validate the payload             - Validate the payload
  - Retries on 5xx                   - Retry on 5xx
  - The response should be cached    - Cache the response
  - Logging                          - Log the request id

Слева четыре разные формы: императив, глагол в 3-м лице, пассив с модальностью, герундий. Читатель тратит усилие на распознавание каждой; хуже — из-за should третий пункт выглядит менее обязательным, хотя автор этого не имел в виду: модальность работает ровно так, как описано в главе про RFC. Проверка — подставьте каждый пункт в общую вводную фразу: получилось грамматично для всех, значит, параллелизм соблюдён. Больше семи пунктов — группируйте; список из одного пункта не делают вовсе.

Процедура правки: что проверять по предложению

Ясность достигается не вдохновением, а прогоном по конечному числу проверок.

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

Что стоит правки, а что нет

Правый нижний угол стоит прокомментировать честно: артикли и предлоги — то, на что русскоязычные авторы тратят больше всего тревоги и что почти не влияет на понимание. Исключение одно — артикль, меняющий смысл (a service против the service), и оно разобрано в главе про типичные ошибки. Остальное читатель исправляет в голове бесплатно и не запоминает.

Инструменты: линтеры вместо силы воли

Половину проверок делает машина — и делает их, когда вы устали, а неясный текст пишется именно в этом состоянии. Vale — линтер прозы для CI и редактора, проверяет текст по опубликованным style guides: пакет Google, пакет Microsoft, write-good, proselint.

brew install vale                            # macOS; для Linux — бинарь из GitHub Releases
vale sync                                    # скачивает пакеты стилей из .vale.ini
vale --output=line --minAlertLevel=error .   # формат для CI и редакторов

; .vale.ini — конфигурация репозитория с документацией
StylesPath = .vale/styles
MinAlertLevel = suggestion
Packages = Google, write-good

[*.md]
BasedOnStyles = Vale, Google, write-good

; в комментариях на ревью «we» — осознанный приём, а не дефект стиля
Google.We = NO

Остальное полезное: LanguageTool — грамматика и пунктуация, работает локально; Hemingway Editor — подсветка длинных предложений и пассива для разовой проверки важного письма; alex — ловит формулировки, неудачные в международной команде (master/slave, guys в обращении к смешанной группе). Метрику Flesch–Kincaid используйте как термометр, а не как цель: она считает только длину слов и предложений, и полезное применение у неё одно — сравнить две версии своего текста. Собственные правила пишутся за полчаса: три регулярных выражения — предложение длиннее 25 слов, (?:perform|conduct|make|provide)\s+\w+(?:tion|ment|ance) для спрятанных действий и (?:is|are|was|were)\s+\w+(?:ed|en) для пассива — покрывают три четверти дефектов из этой главы. Ложных срабатываний будет много (is used, is based on), и это осознанный размен: инструмент не судья, а маркер.

LLM как редактор

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

Плохо:  Rewrite this to sound more professional.   → на 40% длиннее и не вашими словами
Хорошо: Rewrite for clarity for a non-native reader. Keep it under 80 words.
        Keep my terminology exactly as written. Move the request to the first line.
        Do not add pleasantries. Return only the rewritten text.

Четыре правила: просите ясности, а не «профессиональности» (второе модель понимает как «многословно и осторожно»); задавайте бюджет слов, иначе текст растёт всегда; запрещайте менять терминологию — модель охотно заменит ваш retry policy на retransmission strategy и сломает единство имён; спрашивайте про неоднозначность, а не только про правку — самый полезный промпт звучит как List every sentence that could be read in more than one way, and say how. Два ограничения: не отправляйте во внешнюю модель внутренние данные — код, логи с идентификаторами клиентов, детали инцидента, — если это не разрешено политикой компании; и помните, что если вы всегда отправляете текст на правку, ваш собственный не улучшается. Рабочая схема — писать самому, править по чек-листу и только потом просить модель найти пропущенное.

Жизненный цикл черновика

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

Про переход Structured → Rewritten: если правок больше половины текста, дешевле закрыть черновик и написать заново, глядя только на список фактов, — спасать неудачную структуру редактированием дороже второго захода, ровно как с кодом. Про паузу: сразу после написания вы читаете свой замысел, а не свой текст. Стивен Пинкер в The Sense of Style называет это the curse of knowledge — автор не может развидеть то, что знает, и не замечает пропущенных звеньев.

Когда ясность вредна

Честная глава обязана назвать границы. Нормативный текст: в спецификации точность важнее читаемости, и длинное предложение с тремя условиями иногда единственный способ не оставить дыру — см. главу про стандарты и RFC. Плохие новости человеку: «ясно» не равно «в лоб», отказ или несогласие требуют смягчения, иначе читатель займётся защитой, а не содержанием — механика в главе про ревью и в главе про обратную связь. Тексты с юридическими последствиями: ясно сформулированное обещание становится обязательством, и We will fix this by Friday против We are targeting Friday — разные уровни. Решение ещё не принято: преждевременно ясная формулировка в общем канале фиксирует позицию, от которой трудно отойти, и правильный ход — we are still exploring options.

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

Практикум

Лексические кальки и ложные друзья — тема следующей главы; проверим структурные привычки, переносимые из русского письма. Два фрагмента: сначала перепишите сами, потом сверьтесь.

1. It was decided during the discussion that took place yesterday that the implementation
   of the caching layer should probably be postponed until such time as the performance
   testing has been completed by the QA team.

2. Hi! Sorry to bother you. I was wondering if you might possibly have some time at some
   point to take a look at my PR, if it's not too much trouble. It's not urgent at all but
   it would be great if it could be merged at some point this week, no pressure of course.

Первый. 37 слов, три номинализации (discussion, implementation, testing), два пассива без деятеля (it was decided, has been completed), probably и отсутствие срока. Кто решил — неизвестно, а это ровно тот случай, когда «кем?» читателю нужно. Вариант: We agreed yesterday to postpone the caching layer until QA finishes performance testing (ETA Thursday). — 14 слов, деятели названы, срок появился.

Второй. 60 слов, шесть смягчителей подряд, просьба спрятана в середину, срок противоречит сам себе (not urgent плюс this week), и реакции не будет — текст сам сообщил, что дело неважное. Вариант: Could you review PR #412 before Thursday? It unblocks the billing release. ~20 minutes of changes. — 16 слов, просьба первой строкой, названы причина, срок и объём работы.

Чек-лист на одну минуту

• Вывод или просьба — в первой строке?
• Названы действие, адресат и срок? Сказано, что будет, если никто не ответит?
• Есть предложения длиннее 30 слов? В каждом ли предложении подлежащее — тот, кто действует?
• Есть perform, make, provide, conduct рядом с существительным на -tion?
• Каждый пассив осмыслен: деятель либо не нужен, либо назван?
• Оценки (very, significantly, a lot) заменены числами?
• Один объект называется везде одинаково, пункты списка — одной формы?
• Понятно, что здесь факт, а что гипотеза? Текст прочитан вслух хотя бы про себя?

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

Мини-итог

• Ясность — не уровень английского, а свойство текста: одно прочтение, понятное следующее действие, минимум усилий читателя. Потолок конечен, потому что критерий качества — однозначность, а не естественность: простые конструкции здесь норма отрасли, а не поблажка неносителю.
• Правка идёт сверху вниз: документ → абзац → предложение → слово; дефект верхнего уровня обесценивает работу на нижних. Основной эффект дают три операции: вывод в первую строку, разрезание длинных предложений, действующее лицо в подлежащем.
• Ясность не равна краткости: правильный текст часто длиннее исходного, потому что в него добавляются числа, сроки и действие по умолчанию.
• Пассив и номинализации — инструменты, а не запреты: вопрос в том, нужен ли читателю деятель. Линтеры и LLM ускоряют правку, но не заменяют собственный чек-лист.
• Есть места, где прямота вредит: нормативные документы, плохие новости, обязательства с юридическими последствиями.

Источники

• Joseph M. Williams. Style: Lessons in Clarity and Grace — принцип «действующие лица в подлежащее, действия в глаголы» взят оттуда.
• Steven Pinker. The Sense of Style — про curse of knowledge.
• Federal Plain Language Guidelines — руководство, стоящее за Plain Writing Act of 2010, и ISO 24495-1:2023 — стандарт на понятный язык.
• Google developer documentation style guide и Microsoft Writing Style Guide.
• Helen Sword. Zombie Nouns, The New York Times, 2012.
• Nielsen Norman Group: How Users Read on the Web — эмпирика чтения с экрана.
• Vale, LanguageTool, alex — инструменты для CI и редактора.

Что дальше

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

Типичные ошибки русскоязычных инженеров