Дисклеймер. Изначально статья была рассчитана как дополнительный материал, который поможет начинающим разработчикам. Я его задумал когда работал в аутсорсе, где часто брали перспективных ребят, но без опыта. И всё, что будет дальше в статье, приходилось объяснять на пальцах. Поэтому пришла идея собрать всё в некий вспомогательный методический материал, чтобы не повторяться. В итоге это всё переродилось в доклад (ссылка в конце), а теперь в статью. Не хотелось бы, чтобы статья воспринималась как руководство «Путь из джуна в синьоры/лиды». Потому что, в первую очередь, нужно хорошо выполнять и перевыполнять свои основные задачи разработчика. А советы из статьи — вспомогательные. На них одних не выехать. Но и без никак. Итак, представим новичка, который встал на путь героя из джунов в сеньоры или лиды, а может даже в менеджера. Он только прошел курсы ворвался в айти и уже руки чешутся красить кнопки, но тут он встречается с неожиданностями… Без собеседований не будет работы, а без работы не будет карьеры.  На собеседованиях мы обычно говорим про event-loop, как специфичность коррелирует с каскадностью, как работают Reflow и Repaint. А еще интервьюеры у нас пытаются прощупать джуна на софтовые скилы, чтобы понять — подходит он команде или нет. Джун хорошо подготовился, прошел собеседование и получил оффер. И какая у него будет первая задача? Правильно — никогда первой задачей не будет «Передвинуть форму» У новичка в новом проекте всегда что-то будет не работать: у нас не будет работать VPN или каких-то доступов к GitLab’у или YaTracker’у не будет. Если за первую неделю он смог приступить к работе полноценно — это успех. Но, казалось бы, причем здесь джун?  Ни причем. Поэтому джун не ленится (и не боится) и включает режим «отписок»: пишет все необходимые формальные заявки; пишет руководителю, что у него что-то не работает или чего-то нет; фиксирует(!) все это документально.  Jira, Trello, YaTracker, электронная почта и листы формата А4 по необходимости — всё идет в ход.  Некоторые мои коллеги не пользовались корпоративной почтой, не заводили заявки, потому что считали  это ненужным. Вроде сказали руководителю на словах, он услышал. А потом чуть ли не тот же руководитель через полгода спрашивает «А что ты делал тогда?» Заявки и письма тут бы помогли — взятки гладки — вот бумага, ничего не знаю, «проблема не на нашей стороне». И джуну важно создать заявку, а не просто молча разбираться с проблемой. Так он, во-первых, сообщает о проблеме, а во-вторых — имеет железобетонное доказательство, что 3 сентября у него не было коммитов не потому, что он бездельничал, а потому что физически не мог — и бумажка, как подтверждение. Допустим, наш джун быстро усвоил урок, разобрался, инфраструктура налажена. Но приложение всё равно не работает — что-то там с бэкендом. Что делать? Обратиться к старшему, пересмотреть оценку по времени и починить. Здесь я хочу напомнить о простой истине — фича должна работать в той среде, где она должна работать — на проде. Фича, работающая на локальном сервере в деревне у бабушки, не считается. Поэтому в разные периоды вашей карьеры вам постоянно придется сталкиваться с тем, что вас вообще не касается, где там что-то на gateway что-то произошло.  Соответственно, мы учимся не только чинить сбои, вместе с нашим джуном,но и предусматривать их возникновение в будущем. Хорошо качает мозг, а опыт можно использовать на других проектах. Наш джун выяснил, что бэкенд присылает не те данные, и пошёл с этой проблемой к ментору или лиду. Лид занимается своими задачами и хорошо, если помнит, как зовут нашего джуна. А это значит, что лида надо быстро переключить в контекст задачи, и сделать это максимально быстро и с минимальным объяснением деталей — не вдаваясь в пространные рассуждения на 5 минут. Поэтому проблему надо задокументировать и объяснить максимально просто: «Я занимаюсь такой задачей, хочу сделать вот так, пока что получается так, если бы мне такие данные начали приходить, то все бы заработало». Идеально задокументировать проблему записью экрана, и тогда лид быстро отправить джуна по другому адресу, но уже поточнее. Но если записи нет, то пакет MS Office с нами уже 30 лет и уходить не собирается. Нас отправили к бэкендерам. Это и был точный адрес от лида. Но они нас как бы не ждут. Было у вас такое, что вы приходите к бэку с железными пруфами, а они говорят «Проблема на вашей стороне»? Я так как-то месяц доказывал, что не дурак. Ладно, это всё лирика. Общаться с ними все равно придется, поэтому если они проводят какие-то презентации раз в квартал, то они вас ждут, ходите, приносите пиво, задавайте вопросы. Это же отличная возможность для тимбилдинга — попинать мячик, а потом перетереть за жизнь. Потом проблемы джуна будут решаться бодрее, гарантирую. Джун у нас очень ответственный. Он понял, что целый день налаживал инфраструктуру, а к основной задаче так и не приступил. Поэтому он решил переработать! Это же отличная идея (нет): в первые дни тратишь больше часов — больше погружаешься в проект.  Хорошо же? Ведь хорошо? Нет.  На средней и длинной дистанции вам обеспечено то самое выгорание. А еще вы скрываете какие-то недостатки в проекте. Молчите вы, молчит бэкендер, молчит QA — выгораете все вместе. Руководству, конечно, сложно пойти на расширение бюджета, но сообщать об этом нужно.  Если вы попали все же в воронку с переработками, то вылезти из нее можно составлением списка задач. Обычно я его пишу на React бумаге. Написали, приоритизировали, пошли к лиду, может что-то и отпадет. Бывает так, что разработчик залипает, попадает в «тоннель» и не может продвинуться вперед. Для этого у меня есть правило двух часов: если за два часа подвижек нет — просто берешь соседа по коворкингу или звонишь команде, и спрашиваешь «Что не так и что делать?» Они помогут увидеть то, что твой замыленный глаз уже не замечает. Ну и горизонты расширит, куда без этого. Также можно воспользоваться таким инструментом, как код-ревью. Но не когда вас ревьюят, а когда вы. Естественно, здесь возникнет отмазка — «Я новичок и ничего не понимаю, куда мне?!» Но есть такая китайская поговорка: «Лучший день начать что-то делать — сегодня». Начинайте. Если вы ждали знак — то это он. И не забывайте про интернет: каналы и группы в Телеграм, Хабр, YouTube, GitLab, книги. Задавайте вопросы, но не книгам, конечно, вам ответят. За все эти заслуги нашего джуна, который уже почти мидл, позвали выступить на отчётном демо. И эта активность очевидно ведет к вертикальному росту — потому что даст опыт, который пригодится, когда у вас на менеджерской позиции таких демо будет по три. Вот джун и тренируется. А еще это хорошая зарубка. У разработки всегда есть начало, длительный период самой разработки, правки, которые никогда не заканчиваются и нет конца. Выступления на демо позволят вам подвести итог хоть как-то, хоть какого-то этапа. Поэтому, если вас позвали не демо — это хороший знак — часть работы уже закончена! Так что, опять же, готовьтесь к демо — фиксируйте свои достижения. Про неудачи мы помним и корим себя за них, а удачи фиксировать как-то не заведено. А еще демо — это отличный повод для тимбилдинга 🥂. После фееричного выступления на демо нашего путешественника, естественно, захотят клонировать, но пока в нашей компании это делать не умеют. Поэтому джуна заставляют менторить.  Здесь все очевидно. Единственное, напомню, что это не привилегия, а дополнительная ответственность. Не вешайте на себя корону — у вас кроме своих задач, появляется нагрузка в виде задач подопечного. Поэтому обязательно уточняйте, что от вас ожидают: возможно, вы захотите напичкать его основами JS, а руководство хочет от него знаний какой-то части фреймворка и всё. Не забывайте установить дружеский контакт, чтобы человек знал, где переодеться, куда сходить пообедать и в каком баре по пятницам тимбилдинги.  Здесь рекомендую две вещи: Notion, чтобы фиксировать контрольные точки, и корректирующую обратную связь (по STAR, GROW) — нужно не только хвалить, но и светить фонариком на зоны роста. Если не знаете как давать обратную связь — спросите у HR, они знают. Переезд может возникнуть не только по инициативе руководителя, но и по вашей личной. Мы все-таки в активной сфере живем, в которой нужно очень быстро бежать, чтобы не отставать от других. Наверно все сталкивались, когда у вас в проекте используется старая версия какой-нибудь библиотеки, а интернет кишит уже «Да перейдите на новое». А вам не хватает плагинов каких-то, костылей и так далее.  Всем этим можно заниматься, но сначала нужно ответить на вопрос «Какую задачу решаем?», чтобы не произошло улучшения ради улучшения, ради того, чтобы попробовать. Польза какая-то должна быть, допустим, ускорять сборку или доставку проекта до клиента. И джун должен не забыть согласовать решение с коллегами, чтобы они завтра придя на работу, не начали с шага №1. Здесь вынужден дать вредный совет — эта активность потребует работы в ваше личное время. Но делайте это правильно, чтобы оставалось время на обновление версии библиотеки, основные задачи и личную жизнь. Завтра снова работать, поэтому, не забывайте про отдых. Эту активность я изобрел, когда делал доклад для митапа. Я понял, что если уперся и не знаешь, куда дальше развиваться, то можно попробовать вспомнить, что ты откинул.  У джуна/вас может возникнуть мысль: «А зачем мне про безопасность читать? Есть умные ребята, которые пишут фреймворки, мне зачем?» или «Вот есть нагрузочное тестирование, причем тут я?» А почему бы и нет? Если не знаете, что дальше учить — возьмите их. Но не такого совета вы от меня ожидали? Верно. Я недавно участвовал в UX-исследовании нашего продукта. Оно выглядело примерно так: брали рандомного человека с улицы, давали ему продукт и просили совершить несколько действий в определенном порядке. Когда я увидел UX-тестирование в действии, оно перевернуло все мое представление о разработке с ног на голову.  И у вас будет также — больше не будут возникать вопросы зачем нужно тестирование, какие тест-кейсы покрывать (спойлер: все, потом еще два раза все и все равно будет мало), зачем валидировать данные на клиенте и на сервере. Предупрежу — возможно вас накроет жесткой рефлексией. Я предупредил. Выходим на финишную прямую.  Разработчику предложили дополнительные задачи. Он себя зарекомендовал на основных, поэтому ему предложили бОльшую нагрузку за эти успехи. Здесь все очевидно — рекомендую браться за эту активность. Зачем? Хотя бы потому, что вас заметили. Начинайте коммуникации, тренируйтесь, вы будет точно ошибаться даже если вы выучили какие-то учебники и знаете как правильно делать. Вот на практике и узнаете как «правильно» в учебнике отличается от «правильно» в реальности.  И не забудьте составить план и согласовать с руководителем, потому что как только вы что-то сделаете, узнаете, что вы сделали неверно. Поэтому фиксируйте план сразу. Здесь вам может помочь не IT-книга — «45 татуировок менеджера». Толковая книга для управления проектами. И последняя активность для нашего хардового сеньора — документация. Но не построчная кода, а документирование своего проекта. Ведь, как выяснилось, эту документацию читают не только разработчики той же компетенции, что и вы. Я как-то сталкивался с тем, что аналитики пытались разобраться с куском JS-кода, они знали Java и думали, что корень им поможет. Не вышло — они позвали меня. Я объяснил, что название библиотеки просто не соответствует тому, что она выполняет и им нужна другая библиотека. Но если бы у документации была мотивационная часть, они бы просто не стали тратить время. А если серьезно — документирование помогает вам разгрузить свою голову, структурировать данные на каком-то носителе, найти узкие места, зоны роста, и за счет того, что место освободилось, получить задел на будущее.  Так что читайте текущую документацию, исправлять или пишите новую. Активность интересная — я год назад начал и всем рекомендую. Если бы мы жили пару веков назад, то я бы все заново проговорил, но у нас тут IT, так что давайте все автоматизируем. Я вам просто дам метод, а вы его можете применять как хотите.  Допустим, выяснилось, что вам нравятся только синие активности, а с остальными не согласны. На основе этих данных построим такой график. Наглядно видна склонность к росту по горизонтали.  Но четких советов я вам не дам, только общие. На мой взгляд они никому не помешают: можете почитать про тайм-менеджмент; найдите себе какие-то метрики, которыми можно как-то фиксировать свой прогресс — например, посчитайте техдолг в сторипойнтах и следите, как за год он уменьшается. продолжайте браться за сложные проекты.  А здесь у нас обратная ситуация, называется «хочется в менеджеры» График такой. И вроде бы как здесь должен быть другой набор советов. Но нет… От нас, ребята, требуют того же: тайм-менеджмент, метрики и т.д. Вот когда вы на пару точечек сдвинетесь вверх… …то уже думайте о плане развития (например, как подвинуть менеджера), начинайте менторить на регулярной основе (считайте, что это вторая работа) и приезжайте на конфы, например, на MoscowJS или A?.Frontend с докладами. Надеюсь логику построения графиков вы поняли, там ничего сложного. Но если что, я сделал диагностический тест, который график построит сам — просто отметьте нужные чекбоксы. Помните, что все советы хороши, но надо думать головой, чувствовать душой и строить свою карьеру — каждый сам себе лид. А вот и сам доклад, как и обещал. Почитайте другие наши статьи, может быть интересно: Быть или не быть тимлидом – вот в чём вопрос Лучше быть, чем казаться. 10 шагов, чтобы стать «вкусным» кандидатом на собеседовании Как стать руководителем и не помереть Багатон как в первый раз Трансформируемся от разработчика до тимлида Про IT рекрутмент и людей Кем вы видите себя через 6 лет в тестировании? Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.  JS-developer