Дисклеймер. Изначально статья была рассчитана как дополнительный материал, который поможет начинающим разработчикам. Я его задумал когда работал в аутсорсе, где часто брали перспективных ребят, но без опыта. И всё, что будет дальше в статье, приходилось объяснять на пальцах. Поэтому пришла идея собрать всё в некий вспомогательный методический материал, чтобы не повторяться. В итоге это всё переродилось в доклад (ссылка в конце), а теперь в статью.

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

Итак, представим новичка, который встал на путь героя из джунов в сеньоры или лиды, а может даже в менеджера. Он только прошел курсы ворвался в айти и уже руки чешутся красить кнопки, но тут он встречается с неожиданностями…

Шаг №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 с докладами.

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

Помните, что все советы хороши, но надо думать головой, чувствовать душой и строить свою карьеру — каждый сам себе лид.

А вот и сам доклад, как и обещал.

Почитайте другие наши статьи, может быть интересно:

• Быть или не быть тимлидом – вот в чём вопрос

• Лучше быть, чем казаться. 10 шагов, чтобы стать «вкусным» кандидатом на собеседовании

• Как стать руководителем и не помереть

• Багатон как в первый раз

• Трансформируемся от разработчика до тимлида

• Про IT рекрутмент и людей

• Кем вы видите себя через 6 лет в тестировании?

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.