Читатели Хабра, категорически вас приветствую! Это вторая часть статьи о граблях, на которые я наступал в начале карьеры Java‑разработчика, и о выводах, которые из этого сделал. В первой части я рассказывал про онбординг, работу с задачами, код — ревью, тесты и чистый код. Если вы её ещё не читали — вот ссылка.

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

1. Синдром самозванца

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

  • Кажется, что я обманул всех: случайно прошёл собеседование, испытательный срок, а теперь месяцами (или даже годами) обманываю наставника, старших коллег и руководство.

  • Когда я решаю сложные задачи — мне просто везёт. А если коллеги не справились до меня, значит, они уже частично решили задачу, и мне оставалось лишь «добить» ее.

  • Если я не могу решить задачу сам, прошу помощи или трачу много времени — причина только в моей некомпетентности.

  • И, конечно, кажется, рано или поздно придёт «настоящий эксперт» и разоблачит наглого диверсанта, который шифруется под программиста.

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

  • Фиксировать достижения. Точное знание, что за время карьеры вы достигли конкретных результатов, помогает увидеть более реальную картину. Это может быть список в заметках, история в таск — трекере, граф коммитов — что угодно. Когда становится совсем грустно — полезно открыть этот список и напомнить себе: вообще‑то вот тут я разобрался с нетривиальной задачей, тут предложил решение, тут мне доверили сложный участок.

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

2. Не изучать всё подряд

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

На старте эффективнее сфокусироваться на том, что используется в вашем проекте, а свободное время тратить на фундаментальные вещи. Такой подход даёт больше пользы и для текущей работы, и для роста как специалиста в целом.

3. Не злоупотреблять переработками

В начале карьеры кажется, что чем больше работаешь, тем быстрее растёшь. 12–14 часов в день, работа ночью, в выходные, в отпуске — я тоже таким промышлял. И у большинства тех, кто так делал, исход примерно одинаковый: кратковременный всплеск продуктивности, а затем резкое и уверенное снижение эффективности и движение в сторону истощения.

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

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

4. Не бояться просить повышения

Вы растёте как специалист, и вместе с этим растёт ваша стоимость на рынке. Некоторые компании сами подходят и говорят: «Мы тебя повышаем». Но бывают и такие, где повышение нужно просить самостоятельно.

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

5. Не бояться проявлять инициативу

Если вы видите, что какой‑то процесс в команде или компании систематически создаёт проблемы, не нужно молчать только потому, что у вас мало опыта.

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

Если сомневаетесь, имеете ли право поднимать такие вопросы, — обсудите их с коллегами. Возможно, они думают о том же, и вместе вам будет проще сформулировать проблему и предложить решение.

Как и в первой части, это не исчерпывающий список, а те вещи, которые лично мне в своё время помогли бы сэкономить нервы и время. Буду рад обсудить в комментариях ваши мысли и опыт.

Буду рад видеть вас в MAX и Telegram — там материал, который не попал в статьи, а еще рассказываю, над чем работаю, и общаюсь с вами