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

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

Предыдущие главы разбирали ошибки внутри своих жанров: прошедшее время в заголовке коммита (https://courses.digitable.life/post/engineering-english/04-commits-and-prs/), кальки в тикетах (https://courses.digitable.life/post/engineering-english/05-issues-and-bugs/), недосмягчение на ревью (https://courses.digitable.life/post/engineering-english/06-code-review-comments/), просьба в конце письма (https://courses.digitable.life/post/engineering-english/07-async-communication/). Здесь — общая картина: откуда всё берётся, что чинится за вечер, что за год, а что не чинится никогда и не нужно.

Что здесь считается ошибкой

Носитель не оценивает ваш английский как экзаменатор. Он делает две вещи автоматически: считает, сколько усилий уходит на понимание, и достраивает по тексту вашу личность. Отсюда три класса последствий.

Шум. Ошибка видна, смысл и впечатление не страдают: I have a question to you вместо for you, пропущенный артикль, informations. Читатель регистрирует «не носитель» и едет дальше. Единственный класс, который можно оставить как есть.

Трение. Приходится перечитать или достроить недостающее: The bug reproduces on staging (кто воспроизводит?), главное закопано в середину предложения. Прямой ущерб — секунды, накопительный — репутация «с ним тяжело переписываться».

Сбой. Смысл прочитан другой или впечатление о вас изменилось в минус: I'll try to do it today вместо «сделаю сегодня», You must rebase before merge в комментарии коллеге. Этот класс стоит денег. Проверка: представьте, что фразу читает человек, который вас не знает и вам не симпатизирует. Осталась нейтральной — шум; стала приказом или претензией — сбой.

Универсального списка «ошибок русскоязычных» не существует: голый императив в заголовке коммита — норма жанра, в чате коллеге — грубость; опечатка в чате — ничто, в письме заказчику — сигнал небрежности. Смотрите на свою колонку.

Откуда берутся ошибки: пять источников

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

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

Школьный английский. Dear Sir or Madam, I would like to inform you, Yours faithfully грамматически безупречны, но принадлежат жанру официального письма середины XX века. В инженерной переписке читаются примерно как «настоящим уведомляю Вас» в чате команды.

Дословный перевод. Ложные друзья (actual, realize, control), кальки рабочих идиом и русские термины отрасли без прямого соответствия: «стенд», «личный кабинет», «ТЗ», «функционал».

Перенос культурной нормы. Самый дорогой класс, потому что не выглядит языковым: прямота, которая у нас означает уважение к чужому времени, в английской норме читается как агрессия; извинения за язык снижают вес сказанного; обещание без срока в распределённой команде значит «никогда». Пятый источник — чужой неродной английский: do the needful, revert back to me, kindly check подхватываются у коллег по интернациональной команде и принимаются за норму, хотя носителями опознаются мгновенно.

Что чинить первым

Горизонталь — как часто вы это делаете, вертикаль — сколько стоит одно срабатывание.

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

Класс первый: ошибки, которые меняют смысл

Вид глагола: «сломалось один раз» или «ломается всегда»

Самая дорогая грамматическая ошибка русскоязычного инженера — не артикль, а глагол. Русский вид («упал» / «падал» / «падает») не отображается на английские времена один в один, и подстановка по привычке меняет фактическое содержание сообщения.

The service fails when the cache is empty.  — воспроизводится всегда, свойство системы
The service is failing.                     — падает прямо сейчас, инцидент идёт
The service has failed twice today.         — уже случилось, последствия живы
The service failed on Tuesday.              — случилось и закончилось, история
The service failed to start.                — не смогло стартовать (fail to = не удалось)

Пять фраз — пять инженерных ситуаций: The service is failing поднимает людей ночью, The service failed on Tuesday не поднимает никого. Русское «сервис падает» покрывает и то и другое, поэтому при переводе на автомате вы регулярно сообщаете не то, что имели в виду. Правило для баг-репортов и статусов: Present Simple — про поведение системы, Present Continuous — про происходящее сейчас, Present Perfect — про факт с живыми последствиями, Past Simple — про закрытый эпизод. Разбор в контексте тикета — https://courses.digitable.life/post/engineering-english/05-issues-and-bugs/, в контексте логов — https://courses.digitable.life/post/engineering-english/03-error-messages/.

Вторая половина той же проблемы — статусы про себя. I do this task читается как «делаю вообще, регулярно», I did this task не сообщает, закончено ли. Работают три формы: I'm working on it (в работе), It's done, PR is up (закончено, есть артефакт), I'll have it by Thursday (обязательство со сроком). I will do it — самая частая формулировка русскоязычного инженера и самая пустая: намерение без срока и без объекта проверки.

try: как одно слово отменяет обещание

Русское «постараюсь» значит «почти наверняка сделаю, но подстрахуюсь». Английское I'll try — «вероятность меньше половины, планируйте без меня». Это разная информация для планирования.

Как надо, по убыванию уверенности — и каждая формулировка честная, а не вежливая:

It'll be done today.                                — обязательство
I should have it done today.                        — высокая уверенность, есть риск
I'm aiming for today, Thursday at the latest.       — цель и запасной срок
It's unlikely to land today — Thursday is realistic. — честное «нет» со сроком

Как выбирать уровень уверенности устно и в переписке — https://courses.digitable.life/post/engineering-english/08-meetings/, https://courses.digitable.life/post/engineering-english/07-async-communication/.

Артикль как указатель «тот самый»

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

I restarted a node.     — какой-то узел; читатель обязан спросить, какой
I restarted the node.   — тот самый, о котором мы говорили
We need a cache here.   — нужен какой-нибудь кэш, вопрос открыт
We need the cache here. — нужен именно наш существующий кэш

Минимум, закрывающий большинство случаев: первое упоминание — a/an, дальше the; единственные в системе сущности — всегда the (the database, the main branch); имена собственные, продукты и неисчисляемые — без артикля (Postgres, Kafka, traffic, data). Проверка одна: подставьте «тот самый»; не подставляется — the лишний. На нормативных текстах, где эта функция критична, — https://courses.digitable.life/post/engineering-english/02-specs-and-rfc/, ADR.

Предлоги: они принадлежат слову, а не смыслу

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

Пара by / till — единственная в таблице из класса «сбой»: Please review it till Friday просит ревьюера читать код всю неделю, by Friday — сдать к пятнице. Остальное — трение.

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

must, should, may — уровни обязательности, закреплённые RFC 2119 и разобранные в https://courses.digitable.life/post/engineering-english/02-specs-and-rfc/. Русскоязычные инженеры ставят must там, где имели в виду «надо бы», — и получают эффект приказа.

You must add a test here.        — распоряжение подчинённому
This needs a test before merge.  — требование к коду, а не к человеку
We should add a test here.       — рекомендация, обсуждаемо
Could we add a test for this?    — предложение, решение за автором

Отдельная ловушка — have to про себя: I have to finish the migration звучит как жалоба на принуждение, I need to... — как нормальное обязательство.

Класс второй: ошибки, которые меняют вас

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

Голый императив. Русская просьба в повелительном наклонении нейтральна: «пришли логи» — обычная реплика коллеге. Английский голый императив нейтрален только в инструкции (документация, README) и в заголовке коммита. Везде ещё — распоряжение.

Send me the logs.  /  Check this PR.  /  Do it before the release.   — приказы

Could you send me the logs?
Any chance you could look at this PR today?
Would you mind checking this before the cut?

Стоимость исправления — три слова, эффект — вся разница между «коллега» и «человек, который раздаёт указания» (https://courses.digitable.life/post/engineering-english/07-async-communication/, https://courses.digitable.life/post/engineering-english/06-code-review-comments/).

Извинения за язык. Sorry for my bad English, sorry for stupid question — самая распространённая привычка и одна из самых вредных: вы подсвечиваете то, чего собеседник мог не заметить, и заранее обесцениваете содержание. Дальше вас читают как человека, который сам не уверен в том, что говорит. Вместо этого — ничего; если фраза непонятна, переспросят. Нужна помощь с формулировкой — просите конкретно: Is "throttling" the right word here, or do you say "rate limiting"? Та же логика на собеседовании (https://courses.digitable.life/post/engineering-english/10-interviews/, подготовка к интервью).

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

Слова, которые звучат как давление или претензия.

ASAP                        — «моё время важнее вашего»; вместо — срок и причина
As I already said           — «вы не слушали»; вместо — To recap + ссылка
You didn't understand me    — обвинение; вместо — Let me put it differently
It's a simple fix           — обесценивает чужую работу (см. про `just` в главе о ревью)
Why did you do it this way? — требование оправданий; вместо — What led you to this approach?

Сюда же Obviously и Of course: в русском «конечно» часто просто подтверждение, а английский ответ Of course на вопрос коллеги читается как «разумеется, а вы что, не знали?». Замена — Sure.

Класс третий: кальки и русские термины отрасли

Ложные друзья первого ряда (actual, realize, control, decide, normally, accurate, eventually) разобраны в https://courses.digitable.life/post/engineering-english/01-reading-docs/, https://courses.digitable.life/post/engineering-english/04-commits-and-prs/ и https://courses.digitable.life/post/engineering-english/05-issues-and-bugs/. Ниже — второй ряд: кальки рабочих фраз и отраслевые термины без прямого соответствия, которые выдают неродной английский быстрее всего.

Три термина из таблицы регулярно попадают в документы для заказчика и не значат там ничего: personal cabinet (такого понятия в англоязычных продуктах нет), technical task (читается буквально) и stand (в английском — стенд на выставке).

Неисчисляемые существительные. information, feedback, software, hardware, advice, research, progress, equipment, staff, traffic не имеют множественного числа и не берут a; I have some feedbacks — самый узнаваемый маркер русскоязычного автора, а посчитать можно через a piece of feedback. Про data: формально множественное, но в современной технической прозе и в стайлгайдах Google и Microsoft — единственное (the data is stale).

Класс четвёртый: структура текста

Эти ошибки не ловятся ни грамматической проверкой, ни словарём: каждое предложение правильное, а текст читается тяжело.

Главное — в конец предложения. Русский переставляет слова, английский не может: позиции заняты грамматикой. Чтобы вынести причину или следствие в фокус, англоязычный автор меняет не порядок слов, а конструкцию — активный залог на пассив, обычное предложение на расщеплённое (What crashes the service is...). Русскоязычный автор двигает слова внутри английской рамки и получает предложение, где главное стоит в середине и теряется.

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

Плохо:  We looked at the metrics for the past two weeks, and after checking the
        connection pool settings and comparing them with the staging environment,
        it turned out that the timeout was too low.
Хорошо: The timeout is too low. We compared prod and staging pool settings over
        the past two weeks; prod is set to 2s, staging to 30s.

Первый вариант заставляет держать в голове весь путь расследования ради вывода в последнем слове. Подробно — https://courses.digitable.life/post/engineering-english/11-writing-clearly/.

Номинализация. Отглагольные существительные переносятся из русского целыми конструкциями: perform a validation of the input, make a decision about the schema. По-английски это глаголы: validate the input, decide on the schema.

Пропавший агент. It was decided to use a queue («было принято решение») вызывает ровно один вопрос: кем? В инженерном тексте агент называется: We chose a queue because the write spikes were dropping requests. Исключение — постмортемы, где безагентность выбрана намеренно, чтобы не искать виноватых.

Длина предложения. Русское инженерное письмо живёт с предложениями по 40 слов, английское — нет: в хорошей технической прозе 15–20. Лечение механическое — найдите предложения длиннее двух строк и разбейте каждое на два.

Класс пятый: то, что видно на письме

Здесь всё чинится инструментами, и тратить на это внимание не нужно.

recieve → receive      seperate → separate      occured → occurred
existance → existence  sucessful → successful   dependecies → dependencies
adress → address       lenght → length          enviroment → environment

Отдельная группа — удвоение согласной: commit → committed, refer → referred, но benefit → benefited. Правило зависит от ударения, и держать его в голове не нужно — это работа спелчекера. Пара behaviour / behavior, initialise / initialize — не ошибка ни в одну сторону; ошибка — смешать их в одном документе (в коде следуйте кодовой базе, в прозе — стайлгайду). Произношение порождает ошибки в письме через созвучия: тот, кто читает suite как «сьют», пишет sweet spot как suite spot; разбор терминов, которые русскоязычные читают по написанию (queue, cache, schema, tuple, height, char), — в https://courses.digitable.life/post/engineering-english/09-presentations/.

Класс шестой: ошибки, которые не про язык

Их принимают за языковые, потому что они проявляются в тексте. Исправляются поведением.

Просьба без ask — есть контекст, факты и ссылки, нет того, чего вы хотите от читателя; лечится вопросом к себе перед отправкой: «что должен сделать адресат?». «Я не понял» вместо конкретного вопроса: I don't understand не даёт зацепки, I follow the retry logic, but I don't see where the deadline is enforced — даёт. Процесс вместо результата: I was working on the migration не сообщает ничего, Migration is written, blocked on DBA review since Tuesday сообщает всё. Молчание — наша норма не отвечать, пока нет результата; норма распределённой команды — сказать, что вопрос увиден и когда будет ответ (https://courses.digitable.life/post/engineering-english/07-async-communication/). Спор в переписке (https://courses.digitable.life/post/engineering-english/08-meetings/, трудные разговоры) и отсутствие сигнала о риске — Heads up: the migration may slip to Monday (работа вверх).

Как это чинить

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

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

Работайте над тремя-пятью паттернами, не над всеми. Внимание при письме — ресурс на два-три пункта; список из тридцати правил не помещается в голову, когда вы пишете в чат между задачами. И помните, что устная речь откатывается: доведённое до состояния 5 на письме в разговоре вернётся в состояние 3, это нормально.

Личный журнал ошибок

Три колонки: что написал, как поправили, правило одной фразой. Пополняется по факту, перечитывается раз в неделю пять минут.

| Написал                      | Правильно           | Правило                      |
|------------------------------|---------------------|------------------------------|
| I'll try to finish today     | It'll be done today | try = «скорее всего нет»     |
| Please review it till Friday | by Friday           | by = дедлайн, till = процесс |
| on production                | in production       | идиома фиксирована           |

Источники записей по убыванию ценности: правки редактора или коллеги; сравнение вашего текста с переписанным; повторяющиеся уточняющие вопросы («what do you mean by…?»).

Инструменты

Правый нижний квадрант приоритетов отдаётся автоматике целиком, и настраивается она один раз. codespell (github.com/codespell-project/codespell) ставится в pre-commit и ловит опечатки в коде, комментариях и сообщениях коммитов почти без ложных срабатываний — с флагами --ignore-words для проектных терминов и --skip для бинарников. Vale (vale.sh) — линтер прозы с готовыми правилами по Google developer documentation style guide и Microsoft Writing Style Guide; ставится на документацию и описания PR. LanguageTool (languagetool.org) — грамматика в редакторе, плагины для VS Code и JetBrains; артикли, предлоги и согласование ловит лучше всего бесплатного.

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

Here is a message I'm about to send to a US-based colleague. Do not rewrite it.
List the three phrases a native reader would notice, say what each one signals
about me, and give a shorter alternative for each.

Запрет на переписывание — ключевая часть промпта: он превращает модель в источник обратной связи, то есть в то, чего не хватает для перехода 2 → 3 → 4.

Чего чинить не надо

• Акцент. В международной команде он есть у всех, включая шотландцев и техасцев. Работать стоит только над терминами, которые вас не понимают с первого раза.
• Идиомы, сленг и «богатая лексика». Синонимы к use и make не нужны: инженерный английский беден намеренно (https://courses.digitable.life/post/engineering-english/11-writing-clearly/).
• Артикли в чате и мелкие ошибки в устной речи. Их никто не считает; считают, понятна ли мысль.

Мини-практикум

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

2. Тест на прочтение недоброжелателем (10 минут). Прочитайте три своих комментария на ревью как человек, которому вы неприятны. Каждый, что в таком чтении становится претензией, перепишите.

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

Мини-итог

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

Источники

• Michael Swan, Bernard Smith. Learner English: A Teacher’s Guide to Interference and Other Problems (Cambridge University Press) — глава про русскоязычных описывает ровно те переносы, что разобраны выше: cambridge.org
• Michael Swan. Practical English Usage — справочник, устроенный по проблемам, а не по темам: elt.oup.com
• Google developer documentation style guide, раздел Voice and tone — норма, от которой считаются отклонения; Microsoft Writing Style Guide — ближе к продуктовым текстам, вместе с микрокопией.
• RFC 2119 — нормативные модальные глаголы; Vale, codespell, LanguageTool — инструменты из раздела выше.

Что дальше

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

Практика и ресурсы: как поддерживать язык без курсов