1. Почему разработчик с Pre-Intermediate может быть ценнее переводчика с C1
В IT работает другой закон. Здесь не нужна красивая речь. Здесь нужна точность и скорость.
Чего НЕ нужно в IT-английском:
- Красивых оборотов и идиом («It’s raining cats and dogs»).
- Литературного стиля («Henceforth, we shall proceed…»).
- Умения поддерживать small talk про погоду (но это плюс).
Что реально нужно:
- Назвать ошибку в логе, чтобы её поняли.
- Задать вопрос в Stack Overflow без помойки.
- Описать баг в Jira так, чтобы тестировщик не переспрашивал.
- Прочитать документацию на английском (80% всей docs — английский).
- Сказать «я не знаю» на митинге, не потеряв лицо.
Главный навык IT-английского — не перевод, а переиспользование готовых конструкций. Индустрия говорит на клише. Выучите их — станете «своим».
2. Три слоя IT-английского
| Слой | Что включает | Кому нужно |
|---|---|---|
| Базовый (A2-B1) | Читать документацию, писать комментарии, заводить issue на GitHub, понимать техдиалог на 50% | Junior-разработчик, тестировщик |
| Рабочий (B1-B2) | Участвовать в daily stand-up, описывать баги, понимать код-ревью, общаться в тикетах | Middle-разработчик, DevOps, аналитик |
| Профессиональный (B2-C1) | Вести код-ревью на английском, обсуждать архитектуру, спорить с заказчиком, презентовать решение | Team lead, архитектор, тимлид зарубежной команды |
Важный факт: Уровень B1 с правильным техническим словарём часто эффективнее на daily-митинге, чем C1 без технической лексики. Знание слова deprecated важнее знания времён группы Perfect.
3. Золотые правила IT-коммуникации
Правило 1: Пишите так, будто ваш коллега — лабрадор с синдромом дефицита внимания.
Коротко, прямо, по делу. Никакой воды.
Правило 2: Одна проблема — одно сообщение.
Не смешивайте баг фикса и фичу в одном письме. Не описывайте три ошибки в одном тикете.
Правило 3: Сообщение об ошибке важнее описания решения.
Сначала скажите что сломалось, потом почему, потом как чинить.
Правило 4: В устной речи — готовые шаблоны.
Не придумывайте фразы на лету. Выучите 20 клише для митингов и используйте их как конструктор.
1. Как писать заголовок тикета (чтобы его не переоткрыли 10 раз)
Плохой заголовок (такой у всех): Bug in login или Something went wrong.
Хороший заголовок (делают профи): [Component] Short description — what + when + impact
Шаблон: [Frontend/Backend/DB/API] Действие + объект + результат
| Плохо | Хорошо |
|---|---|
| «Button not working» | «[FE] Login button — no redirect after click» |
| «Server error» | «[BE] Auth endpoint — returns 500 on empty password» |
| «Fix this» | «[UI] Dashboard chart — wrong color for negative values» |
2. Как описать баг (чтобы тестировщик не переспрашивал)
Структура бага, которую принимают везде:
Steps to reproduce (как воспроизвести)
- Go to login page
- Enter correct email, wrong password
- Click «Login»
Actual result (что происходит)
— App freezes, no error messageExpected result (что должно быть)
— Shows «Invalid password» messageEnvironment (окружение)
Chrome 120, Windows 11, staging branch
Слова, которые нужно знать для описания багов:
| Слово | Значение |
|---|---|
| crash | программа закрывается сама |
| freeze | программа зависает (не реагирует) |
| hang | подвисает на пару секунд |
| timeout | превышение времени ожидания |
| broken | сломано (визуально или функционально) |
| missing | отсутствует (кнопка, текст) |
| incorrect | некорректный (данные, расчет) |
| inconsistent | нестабильный (разное поведение) |
3. GitHub / PR (pull request) — как писать, чтобы ваш код приняли
Заголовок PR: [type] short description — issue #123
Типы: feat (новая фича), fix (багфикс), docs (документация), refactor (переписал без изменения логики), test (тесты).
Описание PR (шаблон):
What does this PR do?
[Опишите изменения в 1-2 предложениях]Why is this needed?
[Проблема, которую решает PR]Testing done:
— [x] Unit tests pass
— [x] Manual tested on stagingScreenshots / logs: (если нужно)
Фразы для код-ревью (для автора PR):
| Вы хотите | Напишите |
|---|---|
| Объяснить сложное решение | «This might look weird, but it’s needed because…» |
| Попросить посмотреть конкретное место | «PTAL (please take a look) at [link], not sure about this logic» |
| Отметить, что это временно | «This is a temporary fix. Will refactor in #123» |
| Сказать, что тесты проходят | «All green, ready for review» |
| Попросить смержить | «LGTM? (looks good to me) Can you merge?» |
Фразы для код-ревью (для ревьюера):
| Что вы думаете | Напишите |
|---|---|
| Код хорош | «LGTM» / «Looks good, nothing to add» |
| Код хорош, но мелкие замечания | «LGTM with a few nits» (nits = мелочи) |
| Одна просьба | «Can you rename this variable?」 |
| Серьёзная проблема | «This won’t work because [причина]» |
| Не поняли логику | «Can you explain why we need this?» |
| Предлагаете альтернативу | «What if we use… instead?» |
| Классная работа | «Nice refactor! / This is way cleaner now» |
4. Slack / Teams в IT-команде
IT-чат — это отдельная культура. Здесь всё короче, аббревиатуры — норма.
Типичные сообщения:
| Ситуация | Пишем |
|---|---|
| Спросить статус | «Status?» / «ETA on this?» |
| Позвать помощь | «Anyone free to look at this bug?」 |
| Сообщить, что сели за задачу | «Taking this» |
| Сообщить, что закончили | «Done. Ready for QA» |
| Задать вопрос в канале | «Question: has anyone seen [ошибка]?」 |
| Пингнуть конкретного человека | «@john can you check this when you have a sec?» |
Аббревиатуры для IT-чата (выучить обязательно):
| Аббревиатура | Значение | Когда использовать |
|---|---|---|
| AFK | away from keyboard | Отошёл |
| BRB | be right back | Скоро вернусь (5-10 минут) |
| EOD | end of day | К концу дня |
| EOW | end of week | К концу недели |
| WFH | work from home | Работаю из дома |
| PTO | paid time off | В отпуске |
| PR | pull request | Запрос на слияние кода |
| QA | quality assurance | Тестировщики |
| DB | database | База данных |
| API | application programming interface | Интерфейс взаимодействия сервисов |
| FE / BE | frontend / backend | Фронт / Бэк |
| WIP | work in progress | В процессе (не доделал) |
| TBD | to be decided | Будет определено позже |
| MVP | minimum viable product | Минимально работающий продукт |
| AC | acceptance criteria | Критерии приемки задачи |
1. Daily stand-up (ежедневное утро страха)
Daily должна занимать 15 минут. Ваше выступление — 30 секунд. Шаблон:
Yesterday I: [что сделал вчера — 1-2 пункта]
Today I’ll: [что буду делать сегодня — 1-2 пункта]
Blockers: [что мешает, если есть]
Готовые фразы для daily:
| Что сказать | Фраза |
|---|---|
| Вчера закончил задачу | «Finished [#123] — login page. Ready for review» |
| Вчера фиксил баг | «Spent yesterday debugging the timeout issue. Found the root cause» |
| Сегодня продолжаю | «Will continue with [#124] — adding tests» |
| Сегодня начинаю новое | «Picking up [#125] — documentation update» |
| Ничего не делал (были другие дела) | «Was mostly in meetings yesterday. Will focus on [#123] today» |
| Застрял на задаче | «Still working on [#126]. No progress yet. Need help with [тема]» |
| Блокер — жду кого-то | «Blocked on [#127] — waiting for design from @anna» |
| Ухожу рано / прихожу позже | «Will be off after standup. Doctor’s appointment» |
| Болею | «Working from home today. Feeling a bit under the weather» |
Что НЕ надо говорить на daily:
- Детали реализации («Then I changed the for loop to forEach, then I added a try-catch…»).
- Три задачи одновременно (выберите главное).
- Жалобы на жизнь.
2. Планирование и ретро (grooming / refinement, retro)
Фразы для обсуждения задачи:
| Ситуация | Фраза |
|---|---|
| Задача непонятна | «I don’t fully understand the AC. Can we clarify?» |
| Задача слишком большая | «This looks like 3 tasks in one. Should we split it?» |
| Не хватает информации | «We need more info on [aspect]. Who can help?» |
| Сложно оценить | «Hard to estimate. We need a spike» (spike = исследование) |
| Ваше мнение о сложности | «I’d say this is an 8-pointer, not a 5» |
| Не согласны с коллегой | «I see your point, but this will take longer because…» |
Фразы для ретроспективы:
| Что хотите сказать | Фраза |
|---|---|
| Что было хорошо | «What went well: code reviews are really helpful. Let’s keep that» |
| Что было плохо | «What went wrong: not enough testing before merge. We had hotfixes» |
| Предложение улучшить | «What can we improve: let’s add a checklist for PRs» |
| Согласие с коллегой | «+1 to what [name] said» |
| Ну, всё ужасно | «Honestly, this sprint was a disaster because [причина]» |
| Мы молодцы | «Great sprint everyone. No blockers, all tasks done» |
3. Техническое обсуждение (архитектура, решения, баги)
Как описать проблему устно (шаблон):
«We have a bug in [компонент]. The [действие] doesn’t work when [условие]. I think it’s because [причина]. My plan is to [решение]. Does that sound right?»
Как сказать, что не знаете решения (честно и профессионально):
| Фраза | Смысл |
|---|---|
| «I’m not sure. Let me investigate and get back» | Я не уверен. Дай проверю и вернусь. |
| «I don’t know. Does anyone else know?» | Не знаю. Кто-нибудь знает? |
| «Let’s look at the logs / docs together» | Давай посмотрим логи / документацию вместе. |
Как просить помощи:
| Фраза | Когда |
|---|---|
| «Can someone pair with me on this?» | Нужен парный программинг |
| «I’m stuck on [проблема]. Any ideas?» | Нужна идея |
| «Can you take a look at this error?» | Посмотри ошибку |
| «Do we have documentation for this?» | Есть документация на это? |
Как предлагать решение:
| Фраза | Сила |
|---|---|
| «What if we…» | Мягкое предложение |
| «I suggest we…» | Уверенное предложение |
| «We should…» | Настоятельная рекомендация |
| «We have to…» | Жёсткое требование |
Популярные технические глаголы (без них никуда):
| Глагол | Значение | Пример |
|---|---|---|
| deploy | выкатить на сервер | «When can we deploy?» |
| rollback | откатить | «Rollback to previous version» |
| refactor | переписать без изменения логики | «This needs refactoring» |
| debug | искать ошибку | «Debugging this for 2 hours» |
| test | тестировать | «Tested locally, works» |
| implement | реализовать | «Implement the new endpoint» |
| fetch | получить (данные) | «Fetch data from API» |
| parse | разобрать (данные) | «Parse JSON response» |
| validate | проверить корректность | «Validate user input» |
4. Собеседование IT на английском (техническое)
Самый частый страх. Запомните: вас проверяют не на грамматику, а на умение думать вслух.
Фразы, которые спасут на техсобеседовании:
| Что происходит | Фраза |
|---|---|
| Получили задачу | «Let me read the problem again to make sure I understand» |
| Думаете вслух | «Let’s think through this. First, I need to… Then…» |
| Не знаете алгоритм | «I’m not sure about the best approach. Let me try a brute force first» |
| Делаете ошибку | «Oh, I see a bug. Let me fix that. It should be…» |
| Оптимизируете | «This works, but time complexity is O(n²). Can we do better?» |
| Заканчиваете | «That’s my solution. Let me dry-run with an example» |
| Не знаете ответа | «I don’t know the answer, but here’s how I’d find out: check docs, ask on Stack Overflow, debug locally» |
Технические вопросы — как отвечать шаблонно:
| Вопрос | Шаблон ответа |
|---|---|
| «What is [термин]?» | «[Термин] means [простое определение]. For example, [пример из практики].» |
| «What’s the difference between X and Y?» | «X is for [ситуация 1]. Y is for [ситуация 2]. Main difference: [разница].» |
| «How would you solve [задача]?» | «I would start by [шаг 1]. Then [шаг 2]. Edge cases: [что может пойти не так].» |
Никогда не говорите на собеседовании:
- «I’m bad at English» (вы себя занижаете).
- «I don’t know» без продолжения (всегда добавляйте «but I would find out»).