Типичные ошибки junior-разработчика и как их избежать

Главное за минуту

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

1. Не просить помощи

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

Как исправить:

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

Задача: добавить фильтр по дате в отчет.
Проблема: API возвращает 400 при передаче даты.
Пробовал: формат ISO, timestamp, смотрел документацию эндпоинта.
Вопрос: какой формат ожидает бэкенд или где это описано?

2. Молчать о блокерах

Задача застряла из-за доступов, непонятного требования или чужого бага, а на стендапе звучит «все нормально, делаю».

Как исправить:

• Говорите о блокере сразу, как он появился, а не в день дедлайна.
• Называйте, что нужно для разблокировки и от кого.
• Если срок под угрозой, предупреждайте заранее и предлагайте варианты: упростить задачу, сдвинуть срок, разбить на части.

3. Оверинжиниринг

Желание показать уровень приводит к абстракциям «на будущее», лишним паттернам и собственным мини-фреймворкам для простой задачи.

Как исправить:

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

4. Игнорировать или оспаривать каждый фидбек

Комментарии на ревью воспринимаются как критика личности: либо молча игнорируются, либо вызывают долгие споры.

Как исправить:

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

5. Огромные pull request'ы

Неделя работы в одном PR тяжело ревьюится и долго висит.

Как исправить: делите работу на небольшие логичные PR, открывайте draft пораньше, чтобы получить ранний фидбек.

6. Не разобраться в задаче до начала

Код написан, а оказалось, что нужно было другое.

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

7. Пропускать проверку своей работы

PR отправлен, но не проверен локально, тесты не запущены, в коде остались отладочные выводы.

Как исправить: заведите личный чеклист перед отправкой:

• задача решена по критериям готовности;
• проверены основные и крайние сценарии;
• тесты и линтер проходят;
• нет закомментированного и отладочного кода;
• описание PR объясняет, что и зачем изменено.

Как понять, что вы растете

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