Инженерный английский: карта трека и для кого он не подойдёт

Разработчик открывает свой pull request и видит комментарий ревьюера:

I wonder if we should be doing this in the request handler at all.

Он читает это как размышление вслух, отвечает Good point, let me think about it и уходит дальше кодить. Через два дня PR всё ещё не смержен, ревьюер молчит, тимлид спрашивает, почему задача висит. Разработчик искренне не понимает: ему же не сказали ничего конкретного.

Сказали. I wonder if we should be doing this ... at all — это не размышление, это отказ. В переводе на прямую речь: «этому коду здесь не место, вынеси логику из хендлера». Ревьюер считает, что дал ясное указание и ждёт либо исправления, либо аргумента. Разработчик считает, что получил философскую реплику. Оба вежливы, оба компетентны, оба потеряли два дня.

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

Чего этого трека нет и не будет

Начнём с границ, потому что они здесь важнее содержания.

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

Это не подготовка к IELTS/TOEFL. Формат экзамена — отдельный навык, слабо связанный с рабочим. Инженер с C1 по бумажке может замолчать на первом же техническом созвоне, а человек с формальным B1 — годами вести переписку с американской командой без потерь.

Это не постановка произношения и не «убирание акцента». Акцент — не проблема, если вас понимают. Проблема — если вы произносите cache как «кэш-э», queue как «квеуе», а null как «нулл», и коллега тратит секунды на распознавание. В главе про выступления (https://courses.digitable.life/post/engineering-english/09-presentations/) мы разберём именно этот узкий класс: как звучат термины, которые вы читали глазами и никогда не слышали.

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

Что тогда есть

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

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

Ключевая идея, которую стоит принять сразу: инженерный английский беднее разговорного и потому осваивается быстрее. Словарь документации — несколько тысяч слов, из которых половина совпадает с тем, что вы уже видите в коде. Конструкции повторяются. Двусмысленность в технических текстах считается дефектом, и хорошие авторы её убивают намеренно. Об этом подробно — в главе про ясность (https://courses.digitable.life/post/engineering-english/11-writing-clearly/).

Но у этой бедности есть цена: вся нагрузка смысла переезжает на нюансы, которых в русском нет или которые в нём работают иначе — модальность (must / should / may), смягчение (hedging), недоговорённость (understatement). Именно там ломается коммуникация людей, которые «в общем-то знают английский».

Честно про уровень: кому этот трек не поможет

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

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

An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.

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

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

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

Картинка объясняет типичную ситуацию «я вроде знаю английский, но на созвоне выключаюсь». Чтение прокачано годами: доки, Stack Overflow, исходники, книги. Письмо — вполовину: вы пишете короткие сообщения, но избегаете длинных объяснений. Аудирование почти не тренировано: письменный текст ждёт вас сколько угодно, а речь ирландского коллеги на скорости 190 слов в минуту — нет. Речь тренирована меньше всего: чтобы говорить, нужен собеседник, а его в жизни инженера часто просто не было.

Отсюда три следствия для того, как читать трек:

1. Не выравнивайте профиль ради красоты. Работа требует разного от разных навыков. Чтение можно оставить как есть — оно уже выше нужного порога. Разрыв в письме и аудировании стоит вам денег и репутации прямо сейчас.
2. Навыки почти не перетекают друг в друга. Прочитанные сто страниц документации не сделают вас понятнее на созвоне. Это разные механизмы, и тренируются они отдельно.
3. Худший навык определяет, как вас оценивают. Команда судит о вашем английском по самому слабому эпизоду — молчанию на встрече, а не по идеально написанному дизайн-документу.

Где именно английский стоит дорого

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

Читается это так:

• Правый верхний угол — комментарии на ревью и созвоны. Происходит постоянно, ошибка дорогая: испорченные отношения, потерянные дни, репутация «сложного человека». Сюда идёт основное внимание трека.
• Правый нижний — чтение доков, коммиты, PR. Дёшево за раз, но повторяется тысячи раз; выгода от навыка накапливается. Здесь нужна не глубина, а автоматизм.
• Левый верхний — собеседование, публичное демо, чтение стандарта, от которого зависит реализация протокола. Случается редко, но одна ошибка стоит очень дорого. Это готовится заранее и отдельно.
• Левый нижний угол пуст намеренно: если ситуация и редкая, и дешёвая, ей не место в учебном треке.

Три регистра, которые нельзя путать

Инженеру приходится читать и писать на трёх разных английских, и они устроены по-разному настолько, что смешение сразу заметно.

Нормативный. Язык стандартов, спецификаций, лицензий, SLA. Определён формально: в RFC заглавные MUST, MUST NOT, SHOULD, MAY имеют строго заданный смысл (RFC 2119, уточнён RFC 8174). Здесь нет вежливости, нет автора, нет читателя — только обязательства. Разбирается в главе https://courses.digitable.life/post/engineering-english/02-specs-and-rfc/.

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

Социальный. Small talk перед созвоном, знакомство, «как прошли выходные», разговор с рекрутером. Формально проще всего, психологически — тяжелее всего, потому что нет опоры на предмет.

Важная ловушка: одно и то же слово меняет силу при переходе между регистрами. should в спецификации — это «настоятельно рекомендуется, отступление требует обоснования». You should add a test here в комментарии ревьюера — это «добавь тест», без вариантов. We should probably grab lunch — это ничего не значащая любезность. Три разных силы у одного модального глагола; ошибка в распознавании регистра приводит либо к тому, что вы проигнорировали требование, либо к тому, что вы восприняли любезность как обещание.

Как читается то, что вы пишете

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

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

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

Отдельно стоит зафиксировать симметричную ошибку, о которой говорят реже: в письме русскоязычные инженеры недосмягчают и звучат резко, а в устной речи пересмягчают и звучат неуверенно. На созвоне то же самое несогласие подаётся как Maybe, I don't know, it's probably not important, but maybe we could possibly... — и предложение тонет, потому что слушатель по количеству оговорок делает вывод, что говорящий сам в него не верит. Лечится это не заучиванием фраз, а пониманием, сколько смягчения требует ситуация; об этом — https://courses.digitable.life/post/engineering-english/06-code-review-comments/ и https://courses.digitable.life/post/engineering-english/08-meetings/.

Анатомия одного недоразумения

Стоит проследить, как безобидная переписка на ревью за четыре реплики превращается в конфликт, о котором узнаёт тимлид.

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

Отсюда практическое правило, которое пригодится раньше, чем вы дочитаете трек: на ревью любой вопрос о вашем коде — это запрос на действие. Have we considered...?, Is there a reason...?, I wonder if... — не приглашение к философии, а требование либо изменить код, либо привести аргумент. Молчание и «подумаю» — не ответ.

Карта трека

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

Подробнее, что в каждой:

• https://courses.digitable.life/post/engineering-english/01-reading-docs/ — Чтение документации. Как устроен технический английский: почему в документации так много пассива и номинализаций, как читать структурно, а не подряд, что означают deprecated, superseded, subject to change.
• https://courses.digitable.life/post/engineering-english/02-specs-and-rfc/ — Стандарты и RFC. Нормативный язык: MUST / SHOULD / MAY, undefined behavior против implementation-defined, почему юридическая точность формулировки важнее её читаемости.
• https://courses.digitable.life/post/engineering-english/03-error-messages/ — Сообщения об ошибках и логи. Как разбирать чужой текст ошибки на составляющие и как писать свои так, чтобы пользователь понял, что делать. Пересекается с текстами интерфейса — см. микрокопирайтинг в треке про UX.
• https://courses.digitable.life/post/engineering-english/04-commits-and-prs/ — Коммиты и pull request. Самый читаемый текст инженера. Императив в заголовке коммита, тело как ответ на «почему», описание PR как инструкция для ревьюера. Процессуальная сторона — в треке git: совместная работа и ежедневный рабочий цикл.
• https://courses.digitable.life/post/engineering-english/05-issues-and-bugs/ — Задачи и баг-репорты. Ожидаемое против фактического, шаги воспроизведения, отделение наблюдения от гипотезы. Содержательная часть баг-репорта — в тестовой документации, здесь только язык.
• https://courses.digitable.life/post/engineering-english/06-code-review-comments/ — Комментарии на ревью. Как сказать «нет», чтобы это восприняли как техническую позицию, а не как атаку; префиксы nit:, optional:, blocking:; как не согласиться со старшим коллегой. Про обратную связь как таковую — отдельная глава в треке про лидерство.
• https://courses.digitable.life/post/engineering-english/07-async-communication/ — Асинхронная переписка. Письма, чаты, статусы, эскалации, часовые пояса. Как написать письмо, на которое ответят, и статус, который не придётся объяснять устно.
• https://courses.digitable.life/post/engineering-english/08-meetings/ — Созвоны. Что делать, когда вы не успеваете за темпом: как перебить, как попросить повторить, не потеряв лицо, как готовиться заранее. Про механику самих встреч — фасилитация.
• https://courses.digitable.life/post/engineering-english/09-presentations/ — Выступления и демо. Структура рассказа и произношение терминов, которые вы знаете только глазами.
• https://courses.digitable.life/post/engineering-english/10-interviews/ — Собеседование на английском. Формулировки, которые ждут на behavioral-секции, как думать вслух на кодинге, что отвечать на «расскажите о себе». Содержание интервью и подготовка по существу — в главе про собеседование со стороны кандидата, а разговор об оффере — в главе про переговоры.
• https://courses.digitable.life/post/engineering-english/11-writing-clearly/ — Ясность. Почему инженерный английский проще разговорного, что такое plain language и как сокращать, ничего не теряя.
• https://courses.digitable.life/post/engineering-english/12-common-mistakes/ — Типичные ошибки русскоязычных инженеров. Ложные друзья (actually, eventually, realize, accurate), кальки с русского, артикли в тех местах, где они меняют смысл, а не только звучание.
• https://courses.digitable.life/post/engineering-english/13-practice-and-resources/ — Практика и ресурсы. Как поддерживать язык без курсов, встраивая тренировку в рабочий день.

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

Маршруты чтения

Читать всё подряд не обязательно. Три осмысленных маршрута:

«Пишу нормально, но на созвоне выключаюсь». Самый частый случай. 08 → 11 → 09 → 12. Начинать с созвонов, потому что там больнее всего, а глава про ясность даёт язык, на котором вы будете формулировать быстрее.

«Через месяц собеседование». 10 → 09 → 11, параллельно глава про собеседование из карьерного трека. Остальное потом.

«Пришёл в международную команду, пишу много». 04 → 06 → 07 → 05 → 11 → 12. Это порядок по частоте: коммиты и ревью каждый день, письма несколько раз в неделю, задачи реже.

«Читаю спецификации и не уверен, что понимаю правильно». 01 → 02 → 03. Короткий и самодостаточный маршрут для тех, кто пишет мало, но читает нормативные документы, от которых зависит реализация.

Как понять, что стало лучше

Уровень языка — плохая метрика: он измеряется медленно и не тем. Инженерный английский измеряется рабочими артефактами. Возьмите две-три из этого списка и проверяйте раз в месяц:

• Сколько уточняющих вопросов приходит на ваши описания задач. Если ревьюер или QA регулярно спрашивают «what do you mean by…», текст неясен. Цель — ноль уточнений на понимание, вопросы только по существу.
• Сколько времени уходит на письмо, которого вы боитесь. Объяснение решения на три абзаца: было сорок минут — стало десять? Значит, конструкции перешли в автоматизм.
• Доля созвонов, где вы сказали что-то кроме статуса. Не «говорил много», а именно: задал вопрос, возразил, предложил. Ноль из десяти — язык вас блокирует; три из десяти — уже другая позиция в команде.
• Сколько раз за месяц вы перечитывали чужой комментарий, не поняв, требование это или мнение. Прямой индикатор работы с модальностью.
• Сколько ваших PR получили LGTM без обсуждения самого описания. Хорошее описание PR снимает половину вопросов до того, как они заданы.

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

Четыре мифа, которые стоит выбросить

«Сначала подтяну грамматику, потом займусь рабочим английским». Не работает, потому что грамматика без применения не удерживается, а рабочие ситуации не ждут. Правильный порядок обратный: закрывать конкретную ситуацию, а грамматику подтягивать точечно — там, где ошибка меняет смысл. Разница между I will send it и I am sending it важна не потому, что это разные времена, а потому что первое коллега слышит как «когда-нибудь», а второе — как «прямо сейчас».

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

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

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

Мини-итог

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

Источники

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

• Google developer documentation style guide — эталон современного технического английского: короткие предложения, активный залог, обращение к читателю. Читается как справочник, а не как учебник.
• Microsoft Writing Style Guide — второй крупный отраслевой стандарт, с сильным разделом про тон и про то, как писать сообщения об ошибках.
• Technical Writing Courses for Engineers — бесплатный курс Google по техническому письму; для инженеров, а не для писателей.
• RFC 2119 и RFC 8174 — полторы страницы, определяющие значение MUST и SHOULD во всей интернет-документации. Прочитать целиком стоит один раз.
• plainlanguage.gov — государственное руководство США по простому языку; полезно как набор проверяемых правил.
• Conventional Commits — соглашение о структуре сообщений коммитов, к которому мы вернёмся в главе 04.
• Erin Meyer, The Culture Map (2014) — про то, почему прямота в одних культурах считается уважением, а в других грубостью. Не про язык, но объясняет половину описанных здесь недоразумений.
• Anna Wierzbicka, Cross-Cultural Pragmatics (2003) — академический разбор различий русской и английской речевой вежливости, включая императив и просьбы.

Что дальше

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