Дисклеймер. Изначально статья была рассчитана как дополнительный материал, который поможет начинающим разработчикам. Я его задумал когда работал в аутсорсе, где часто брали перспективных ребят, но без опыта. И всё, что будет дальше в статье, приходилось объяснять на пальцах. Поэтому пришла идея собрать всё в некий вспомогательный методический материал, чтобы не повторяться. В итоге это всё переродилось в доклад (ссылка в конце), а теперь в статью.
Не хотелось бы, чтобы статья воспринималась как руководство «Путь из джуна в синьоры/лиды». Потому что, в первую очередь, нужно хорошо выполнять и перевыполнять свои основные задачи разработчика. А советы из статьи — вспомогательные. На них одних не выехать. Но и без никак.
Итак, представим новичка, который встал на путь героя из джунов в сеньоры или лиды, а может даже в менеджера. Он только прошел курсы ворвался в айти и уже руки чешутся красить кнопки, но тут он встречается с неожиданностями…
Шаг №0. Собеседование
Без собеседований не будет работы, а без работы не будет карьеры.
На собеседованиях мы обычно говорим про event-loop, как специфичность коррелирует с каскадностью, как работают Reflow и Repaint. А еще интервьюеры у нас пытаются прощупать джуна на софтовые скилы, чтобы понять — подходит он команде или нет.
Джун хорошо подготовился, прошел собеседование и получил оффер. И какая у него будет первая задача? Правильно — никогда первой задачей не будет «Передвинуть форму»
Шаг №1. Починить инфраструктуру

У новичка в новом проекте всегда что-то будет не работать: у нас не будет работать VPN или каких-то доступов к GitLab’у или YaTracker’у не будет. Если за первую неделю он смог приступить к работе полноценно — это успех. Но, казалось бы, причем здесь джун?
Ни причем. Поэтому джун не ленится (и не боится) и включает режим «отписок»:
пишет все необходимые формальные заявки;
пишет руководителю, что у него что-то не работает или чего-то нет;
фиксирует(!) все это документально.
Jira, Trello, YaTracker, электронная почта и листы формата А4 по необходимости — всё идет в ход.
Некоторые мои коллеги не пользовались корпоративной почтой, не заводили заявки, потому что считали это ненужным. Вроде сказали руководителю на словах, он услышал. А потом чуть ли не тот же руководитель через полгода спрашивает «А что ты делал тогда?» Заявки и письма тут бы помогли — взятки гладки — вот бумага, ничего не знаю, «проблема не на нашей стороне».
И джуну важно создать заявку, а не просто молча разбираться с проблемой. Так он, во-первых, сообщает о проблеме, а во-вторых — имеет железобетонное доказательство, что 3 сентября у него не было коммитов не потому, что он бездельничал, а потому что физически не мог — и бумажка, как подтверждение.
Шаг №2. Наладить работу своего приложения

Допустим, наш джун быстро усвоил урок, разобрался, инфраструктура налажена. Но приложение всё равно не работает — что-то там с бэкендом.
Что делать? Обратиться к старшему, пересмотреть оценку по времени и починить.
Здесь я хочу напомнить о простой истине — фича должна работать в той среде, где она должна работать — на проде. Фича, работающая на локальном сервере в деревне у бабушки, не считается. Поэтому в разные периоды вашей карьеры вам постоянно придется сталкиваться с тем, что вас вообще не касается, где там что-то на gateway что-то произошло.
Соответственно, мы учимся не только чинить сбои, вместе с нашим джуном,но и предусматривать их возникновение в будущем. Хорошо качает мозг, а опыт можно использовать на других проектах.
Шаг №3. Донести сложное простыми словами

Наш джун выяснил, что бэкенд присылает не те данные, и пошёл с этой проблемой к ментору или лиду. Лид занимается своими задачами и хорошо, если помнит, как зовут нашего джуна. А это значит, что лида надо быстро переключить в контекст задачи, и сделать это максимально быстро и с минимальным объяснением деталей — не вдаваясь в пространные рассуждения на 5 минут.
Поэтому проблему надо задокументировать и объяснить максимально просто: «Я занимаюсь такой задачей, хочу сделать вот так, пока что получается так, если бы мне такие данные начали приходить, то все бы заработало». Идеально задокументировать проблему записью экрана, и тогда лид быстро отправить джуна по другому адресу, но уже поточнее. Но если записи нет, то пакет MS Office с нами уже 30 лет и уходить не собирается.
Шаг №4. Пообщаться со смежными отделами
Нас отправили к бэкендерам. Это и был точный адрес от лида. Но они нас как бы не ждут.

Было у вас такое, что вы приходите к бэку с железными пруфами, а они говорят «Проблема на вашей стороне»? Я так как-то месяц доказывал, что не дурак.
Ладно, это всё лирика. Общаться с ними все равно придется, поэтому если они проводят какие-то презентации раз в квартал, то они вас ждут, ходите, приносите пиво, задавайте вопросы. Это же отличная возможность для тимбилдинга — попинать мячик, а потом перетереть за жизнь. Потом проблемы джуна будут решаться бодрее, гарантирую.
Шаг №5. Переработки

Джун у нас очень ответственный. Он понял, что целый день налаживал инфраструктуру, а к основной задаче так и не приступил. Поэтому он решил переработать! Это же отличная идея (нет): в первые дни тратишь больше часов — больше погружаешься в проект. Хорошо же? Ведь хорошо?

Нет.
На средней и длинной дистанции вам обеспечено то самое выгорание. А еще вы скрываете какие-то недостатки в проекте. Молчите вы, молчит бэкендер, молчит QA — выгораете все вместе. Руководству, конечно, сложно пойти на расширение бюджета, но сообщать об этом нужно.

Если вы попали все же в воронку с переработками, то вылезти из нее можно составлением списка задач. Обычно я его пишу на React бумаге. Написали, приоритизировали, пошли к лиду, может что-то и отпадет.
Шаг №6. Найти взгляд со стороны

Бывает так, что разработчик залипает, попадает в «тоннель» и не может продвинуться вперед. Для этого у меня есть правило двух часов: если за два часа подвижек нет — просто берешь соседа по коворкингу или звонишь команде, и спрашиваешь «Что не так и что делать?» Они помогут увидеть то, что твой замыленный глаз уже не замечает. Ну и горизонты расширит, куда без этого.
Также можно воспользоваться таким инструментом, как код-ревью. Но не когда вас ревьюят, а когда вы. Естественно, здесь возникнет отмазка — «Я новичок и ничего не понимаю, куда мне?!» Но есть такая китайская поговорка: «Лучший день начать что-то делать — сегодня». Начинайте. Если вы ждали знак — то это он.
И не забывайте про интернет: каналы и группы в Телеграм, Хабр, YouTube, GitLab, книги. Задавайте вопросы, но не книгам, конечно, вам ответят.
Шаг №7. Выступить на отчётном демо

За все эти заслуги нашего джуна, который уже почти мидл, позвали выступить на отчётном демо. И эта активность очевидно ведет к вертикальному росту — потому что даст опыт, который пригодится, когда у вас на менеджерской позиции таких демо будет по три. Вот джун и тренируется.
А еще это хорошая зарубка. У разработки всегда есть начало, длительный период самой разработки, правки, которые никогда не заканчиваются и нет конца. Выступления на демо позволят вам подвести итог хоть как-то, хоть какого-то этапа. Поэтому, если вас позвали не демо — это хороший знак — часть работы уже закончена!
Так что, опять же, готовьтесь к демо — фиксируйте свои достижения. Про неудачи мы помним и корим себя за них, а удачи фиксировать как-то не заведено.
А еще демо — это отличный повод для тимбилдинга ?.
Шаг №8. Заняться онбордингом нового сотрудника

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

Поэтому джуна заставляют менторить.
Здесь все очевидно. Единственное, напомню, что это не привилегия, а дополнительная ответственность. Не вешайте на себя корону — у вас кроме своих задач, появляется нагрузка в виде задач подопечного. Поэтому обязательно уточняйте, что от вас ожидают: возможно, вы захотите напичкать его основами JS, а руководство хочет от него знаний какой-то части фреймворка и всё.
Не забывайте установить дружеский контакт, чтобы человек знал, где переодеться, куда сходить пообедать и в каком баре по пятницам тимбилдинги.
Здесь рекомендую две вещи: Notion, чтобы фиксировать контрольные точки, и корректирующую обратную связь (по STAR, GROW) — нужно не только хвалить, но и светить фонариком на зоны роста. Если не знаете как давать обратную связь — спросите у HR, они знают.
Шаг №9. Переехать на новые технологии

Переезд может возникнуть не только по инициативе руководителя, но и по вашей личной. Мы все-таки в активной сфере живем, в которой нужно очень быстро бежать, чтобы не отставать от других.
Наверно все сталкивались, когда у вас в проекте используется старая версия какой-нибудь библиотеки, а интернет кишит уже «Да перейдите на новое». А вам не хватает плагинов каких-то, костылей и так далее.
Всем этим можно заниматься, но сначала нужно ответить на вопрос «Какую задачу решаем?», чтобы не произошло улучшения ради улучшения, ради того, чтобы попробовать. Польза какая-то должна быть, допустим, ускорять сборку или доставку проекта до клиента.
И джун должен не забыть согласовать решение с коллегами, чтобы они завтра придя на работу, не начали с шага №1.
Здесь вынужден дать вредный совет — эта активность потребует работы в ваше личное время. Но делайте это правильно, чтобы оставалось время на обновление версии библиотеки, основные задачи и личную жизнь. Завтра снова работать, поэтому, не забывайте про отдых.
Шаг №10. Тестировать на безопасность, устойчивость, доступность

Эту активность я изобрел, когда делал доклад для митапа. Я понял, что если уперся и не знаешь, куда дальше развиваться, то можно попробовать вспомнить, что ты откинул.
У джуна/вас может возникнуть мысль: «А зачем мне про безопасность читать? Есть умные ребята, которые пишут фреймворки, мне зачем?» или «Вот есть нагрузочное тестирование, причем тут я?» А почему бы и нет? Если не знаете, что дальше учить — возьмите их.
Но не такого совета вы от меня ожидали? Верно. Я недавно участвовал в UX-исследовании нашего продукта. Оно выглядело примерно так: брали рандомного человека с улицы, давали ему продукт и просили совершить несколько действий в определенном порядке. Когда я увидел UX-тестирование в действии, оно перевернуло все мое представление о разработке с ног на голову.
И у вас будет также — больше не будут возникать вопросы зачем нужно тестирование, какие тест-кейсы покрывать (спойлер: все, потом еще два раза все и все равно будет мало), зачем валидировать данные на клиенте и на сервере. Предупрежу — возможно вас накроет жесткой рефлексией. Я предупредил.
Шаг №11. Возглавить разработку новой библиотеки
Выходим на финишную прямую.

Разработчику предложили дополнительные задачи. Он себя зарекомендовал на основных, поэтому ему предложили бОльшую нагрузку за эти успехи. Здесь все очевидно — рекомендую браться за эту активность. Зачем? Хотя бы потому, что вас заметили.
Начинайте коммуникации, тренируйтесь, вы будет точно ошибаться даже если вы выучили какие-то учебники и знаете как правильно делать. Вот на практике и узнаете как «правильно» в учебнике отличается от «правильно» в реальности.
И не забудьте составить план и согласовать с руководителем, потому что как только вы что-то сделаете, узнаете, что вы сделали неверно. Поэтому фиксируйте план сразу.
Здесь вам может помочь не IT-книга — «45 татуировок менеджера». Толковая книга для управления проектами.
Шаг №12. Задокументировать проект

И последняя активность для нашего хардового сеньора — документация. Но не построчная кода, а документирование своего проекта. Ведь, как выяснилось, эту документацию читают не только разработчики той же компетенции, что и вы. Я как-то сталкивался с тем, что аналитики пытались разобраться с куском JS-кода, они знали Java и думали, что корень им поможет. Не вышло — они позвали меня. Я объяснил, что название библиотеки просто не соответствует тому, что она выполняет и им нужна другая библиотека. Но если бы у документации была мотивационная часть, они бы просто не стали тратить время.
А если серьезно — документирование помогает вам разгрузить свою голову, структурировать данные на каком-то носителе, найти узкие места, зоны роста, и за счет того, что место освободилось, получить задел на будущее.
Так что читайте текущую документацию, исправлять или пишите новую. Активность интересная — я год назад начал и всем рекомендую.
И что со всем этим делать?

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

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

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

График такой.

И вроде бы как здесь должен быть другой набор советов. Но нет…
От нас, ребята, требуют того же: тайм-менеджмент, метрики и т.д.
Вот когда вы на пару точечек сдвинетесь вверх…

…то уже думайте о плане развития (например, как подвинуть менеджера), начинайте менторить на регулярной основе (считайте, что это вторая работа) и приезжайте на конфы, например, на MoscowJS или A?.Frontend с докладами.
Надеюсь логику построения графиков вы поняли, там ничего сложного. Но если что, я сделал диагностический тест, который график построит сам — просто отметьте нужные чекбоксы.
Помните, что все советы хороши, но надо думать головой, чувствовать душой и строить свою карьеру — каждый сам себе лид.
А вот и сам доклад, как и обещал.
Почитайте другие наши статьи, может быть интересно:
Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.