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

Самая распространенная и опасная ошибка. Джуниор получает задачу, что-то идет не так, он встает в тупик и... молчит. Часы тикают, дедлайн приближается, а сеньор или тимлид думают, что работа кипит. Когда выясняется, что задача не сдвинулась с места за 8 часов, это воспринимается как катастрофа. В голове джуниора часто крутится мысль: «Сейчас еще полчаса посижу, разберусь сам, не буду отвлекать занятых людей». Правда в том, что час бесплодных попыток — это уже критический максимум. Ваша задача в первый год — не решить задачу любой ценой в одиночку, а доставить результат с помощью команды. Молчание превращает вас в «черный ящик», которому перестают доверять.

Две крайности одного явления. Первые проявляется в том, что джуниор боится показать код, стесняется задавать вопросы, извиняется за каждую строчку и тратит уйму времени на самоедство вместо работы. Второй тип — полярная противоположность: вчерашний студент, выучивший React за месяц, считает, что знает всё лучше всех. Он не слушает код-ревью, спорит по каждой мелочи и отказывается писать документацию. Фатальность здесь в отсутствии адекватной самооценки. Рынок не терпит ни паникеров, ни выскочек. От вас ждут спокойного профессионализма: вы чего-то не знаете — это нормально, вы спокойно спрашиваете и записываете. Вам указывают на ошибку — вы благодарите и исправляете.

Джуниор получает доступ к легаси-коду, который писался «в те далекие времена», и у него чешутся руки всё переписать. Кажется, что вот здесь нужно применить новый паттерн, тут заменить for на map, а этот компонент вообще разбить на 10 маленьких. Часто это происходит без задачи, в рабочее время и без согласования. Результат: вместо выполнения бизнес-задачи, разработчик создает тысячу изменений в коде, ломает существующую логику и подставляет команду. Правило простое: код не трогают, если на это нет прямой задачи или бага. Ваша субъективная оценка «код фигня» — не повод для рефакторинга за счет компании.

«Я нашел библиотеку, которая делает всё!» — частая мантра джуниора. Проблема в том, что библиотека тянет 50 мегабайт зависимостей, имеет 3 известные уязвимости и давно не поддерживается. Другая крайность — копирование кода со StackOverflow без понимания того, как он работает. Скопированный код может содержать уязвимости, не учитывать бизнес-логику конкретного проекта или просто работать неправильно в другом контексте. Фатальная ошибка здесь — отсутствие критического мышления. Любое внешнее решение должно быть проанализировано: зачем оно нам, как оно работает и какие проблемы создаст через месяц.

Классика жанра: джуниор забывает обработать null, не ставит try/catch на важных запросах к API, или, что еще хуже, хардкодит чувствительные данные (токены, пароли) прямо в коде. В staging-среде это может пройти, но на проде — упадет с ошибкой 500 на глазах у пользователей или откроет доступ к базе данных злоумышленникам. Валидация входных данных — это не просто «хорошая практика», это закон выживания в продакшене. Если вы не проверили, что пришло с бэкенда — вы гарантированно получите баг в рантайме.

В команде есть линтер, код-стайл, правила именования веток git, шаблоны для пул-реквестов. Джуниор считает это бюрократией и делает «как удобно мне». Он пушит в main напрямую, не следует code style, называет переменные a, b, c. Это не просто нарушение правил — это проявление неуважения к команде. Поддержка такого кода превращается в ад, код-ревью занимает часы вместо минут. Разработчик, который не соблюдает общие договоренности, быстро становится изгоем и покидает проект.

Представьте: вы делаете пул-реквест, в котором 30 файлов изменений, 5000 строк кода, и описание «fix bugs». Сеньор, который будет это ревьювить, ненавидит вас в этот момент молчаливой профессиональной ненавистью. Маленькие, атомарные коммиты с понятными сообщениями — признак взрослого разработчика. Джуниоры часто делают один гигантский коммит в конце спринта, что делает невозможным откат изменений и поиск ошибок. Правило: один коммит = одна логическая единица работы.

«Работает же! Зачем писать тесты? Это сеньоры пусть пишут, я фичи делаю». Это мышление убивает проекты. Джуниор, который не пишет тесты, перекладывает ответственность за качество своего кода на плечи тестировщиков и коллег. В результате баги уходят на прод, доверие падает. Даже если на проекте нет строгих требований по покрытию тестами, писать юнит-тесты на сложные моменты — это способ защитить себя же от будущих проблем.

Джуниор видит только свою задачу. Ему сказали «сделай кнопку», он сделал кнопку. Но он не посмотрел, что эта кнопка ломает верстку на мобильных устройствах, увеличивает время загрузки страницы или конфликтует с соседним компонентом. Отсутствие системного взгляда на проект приводит к тому, что джуниор постоянно «чинит одно, ломая другое». Чтобы избежать этого, всегда нужно задавать себе вопрос: «Кого еще коснется мое изменение?»

Желание доказать всё и сразу заставляет джуниоров работать по 12 часов, брать задачи сверх нормы, не брать отпуска. Через 3-4 месяца наступает истощение. Код становится грязным, появляются глупые ошибки, пропадает мотивация. Это фатально, потому что восстановиться после выгорания на первом месте работы крайне сложно. Ритм жизни в IT — марафон, а не спринт. Ваша задача — сохранить себя и голову свежей на долгие годы.

Фатальные ошибки джуниоров — это не всегда про код. Это про отношение к работе, про коммуникацию и про честность с самим собой. Лучшая стратегия выживания выглядит так: спрашивай, если не знаешь; предупреждай, если опаздываешь; проверяй, прежде чем отдать; уважай время команды; не бойся признавать ошибки. Если вы будете следовать этим простым правилам, даже самый кривой код простят и помогут исправить. Если же вы нарушаете базовые принципы взаимодействия — вас не спасут даже идеальные алгоритмы.