Привет, меня зовут Кирилл Павлик. Я JS-разработчик в Альфа-Банке и ментор на курсе «Мидл фронтенд-разработчик» в Практикуме. В этой статье мы пройдём типичный путь джуна-путешественника, который стремится к вертикальному ⬆️ и горизонтальному росту ➡️.

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

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

Маршрут нашего путешествия:

0. Пройти собеседование

1. Починить инфраструктуру

2. Наладить работу своего приложения

3. Донести сложное простыми словами

4. Пообщаться со смежными отделами

5. Поработать сверхурочно

6. Найти взгляд со стороны

7. Выступить на отчётном демо

8. Заняться онбордингом нового сотрудника

9. Переехать на новые технологии

10. Тестировать на безопасность, устойчивость и доступность

11. Возглавить разработку новой библиотеки

12. Задокументировать проект

Шаг 0. Пройти собеседование

На собеседованиях обычно речь идёт про event-loop, как специфичность коррелирует с каскадностью, как работают Reflow, Repaint. Интервьюеры пытаются прощупать джуна на софтовые скилы, чтобы понять, подходит ли он команде.

Чтобы пройти собеседование, джун хорошо подготовился:

• изучил базу JS, особенно асинхронность, событийный цикл, контекст;

• помимо знания тегов HTML и их атрибутов разобрался, из чего состоит критический путь рендеринга и что такое V8;

• научился жонглировать селекторами CSS и не использовать приёмы вроде !important.

Его взяли на работу, начали появляться первые задачи.

1. Починить инфраструктуру ⬆️

Почти всегда получается так, что сотрудник выходит на новый проект и внезапно не работает что-то критично важное: VPN, доступы к GitLab’у или YaTracker’у. Если в течение первой недели разработчик приступил к выполнению непосредственных задач — это успех.

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

Что делать:

• Сообщить руководителям

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

Какие инструменты применить:

• Трекеры: Jira, YaTracker и другие

• Электронную почту

Почему джуну важно создать заявку, а не просто молча разбираться с проблемой? Создав заявку, джун:

• Сообщает ответственным за эту часть инфраструктуры людям о самой проблеме, поэтому она быстрее решится.

• Создает себе железный пруф того, что он не бездельничал на рабочем месте, а решал проблему. Этот пруф можно будет предъявить через месяц, полгода — когда понадобится.

• Заботится о себе и коллегах. Насытив заявку необходимой инфой (скрины, логи), ему не придётся пересказывать всё по тысяче раз или рыться в переписках, чтобы вспомнить детали.

2. Наладить работу своего приложения ⬆️

Наш джун сообщил о проблеме кому надо, и всё быстренько починили. Но приложение всё равно не работает: вроде бы есть какая-проблема с бэкендом.

Что делать:

• Обратиться к старшему и починить

• Разработать план предупреждения таких ситуаций

• Пересмотреть оценку по времени

Какие инструменты применить:

• ????

• Опыт на конкретном проекте

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

Особенности работы (или неработы) частей приложения будут возникать постоянно, на протяжении всей карьеры. Умение реагировать и устранять сбои — важный скил. Это качество является одним из ключевых при определении грейда разработчика.

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

3. Донести сложное простыми словами ➡️

Джун выяснил, что бэкенд не присылает данные, и пошёл с этой проблемой к лиду. Лид занимается своими задачами и не факт даже, что помнит, как джуна зовут. Его надо переключить в контекст своей задачи, и сделать это максимально быстро, с минимальным объяснением деталей — не вдаваться в объяснения по 5 минут.

Чтобы это сделать, нужно задокументировать проблему и объяснить максимально просто: «Я занимаюсь такой задачей, хочу сделать вот так, пока что получается так». Чем лучше джун обрисует проблему, тем быстрее его сориентируют по следующим действиям. Круче всего продемонстрировать проблему на записи экрана, но и просто текстом тоже можно.

Что делать:

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

• Предложить изменения и показать предполагаемый результат

Какие инструменты применить:

• Excalidraw, Miro, Paint

• MS Office

• Запись экрана

4. Пообщаться со смежными отделами ➡️

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

Представим картину: наш джун пошёл к своему лиду. Затем лид пошёл к лиду соседнего отдела. Лид соседнего отдела донёс своему джуну и попросил связаться с нашим джуном. И вот два заинтересованных исполнителя связались, но уже завтра, потеряв целый день.

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

Что делать:

• Сходить на презентации или демо

• Участвовать в тимбилдингах

• Задавать вопросы

Какие инструменты применить:

• ????

• ⚽

• ????

5. Поработать сверхурочно ➡️

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

На средней и длинной дистанции разработчик обречён на выгорание. Он может скрывать переработки, считая, что это показатель его недостаточной компетенции. В таком случае джун скрывает и недостатки в организационной части проекта, а это влияет на весь коллектив и продукт. Чтобы вылезти из воронки переработок, можно составить список задач или обсудить проблему с руководителем. Руководитель поможет скорректировать ресурсы.

Что делать:

• Составить список задач

• Приоритизировать задачи

• Быть на связи с руководителем

Какие инструменты применить:

• Todoist, Trello и другие

6. Найти взгляд со стороны ⬆️

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

Также можно воспользоваться таким инструментом, как код-ревью, — помогать проверять чужой код. У начинающего разработчика может возникнуть аргумент «Я же новичок и ничего не понимаю, зачем мне это нужно?!» Но у китайцев есть поговорка: «Лучший день, чтобы начать что-то делать, — это сегодня». Нельзя забывать и про телеграм-каналы, Хабр, YouTube — весь интернет в его распоряжении.

Что делать:

• Регулярно принимать участие в код-ревью

• Обсудить в профильных группах

• Обменяться опытом с другими

Какие инструменты применить:

• GitLab, Хабр, бакет

• YouTube, книги

7. Выступить на отчётном демо ⬆️

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

Советую обязательно фиксировать свои достижения. Про неудачи мы обычно помним и корим себя за них, но удачи не у всех заведено фиксировать.

Что делать:

• Выдохнуть

• Решить, кому и что рассказать

• Собрать презентацию

Какие инструменты применить:

• Keynote, PowerPoint

• ????????

8. Заняться онбордингом нового сотрудника ⬆️

После фееричного выступления на демо нашего путешественника, естественно, захотят клонировать, но пока что это невозможно. Поэтому его заставят менторить. Важно понимать, что это не привилегия, а дополнительная ответственность. Ему обязательно нужно уточнить, что от него ожидают: возможно, он решит пичкать нового сотрудника основами JS, а для руководителя было бы достаточно уверенного понимания хуков оптимизации React’а.

Наш друг обязательно установит личный контакт и объяснит новичку, где переодеться, куда сходить пообедать и где собираются сотрудники по пятницам. Для фиксирования контрольных точек в работе с подопечным можно использовать Notion или любую другую программу.

Советую обязательно давать корректирующую обратную связь — указывать на точки роста, не только хвалить. Обратную связь тоже надо уметь давать: если непонятно, как, стоит посоветоваться с HR-специалистом.

Что делать:

• Понять ожидания

• Установить дружеский контакт

Какие инструменты применить:

• Notion

• Корректирующая обратная связь по STAR, GROW и так далее

9. Переехать на новые технологии ➡️

Переезд на новые технологии может произойти не только по инициативе руководителя, но и по собственной инициативе разработчика. Мы работаем в такой активной сфере, что нужно очень быстро бежать, чтобы не отставать от других.

Например, в проекте используется старая версия какой-нибудь библиотеки. Интернет кишит уже «Да перейдите на новое» — а у нашего разработчика не хватает плагинов каких-то, костылей и так далее. Нужно что-то делать, но сначала нужно ответить на вопрос «Какую задачу мы решаем?» и согласовать решение с коллегами. В ином случае есть риск затронуть функционал коллег, которым придётся незапланированно переключаться на исправление новых багов.

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

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

Что делать:

• Ответить на вопрос «Какую задачу решаем?»

• Согласовать с коллегами

Какие инструменты применить:

• Свободное время

10. Тестировать на безопасность, устойчивость и доступность ➡️

Разработчик не знает, куда дальше развиваться, — время вспомнить про какие-то дополнительные отрасли знаний. Правда, встречается такой паттерн поведения: «Зачем мне про безопасность читать? Есть умные ребята, которые пишут фреймворки, а я тут ни при чём. У меня мозгов не хватит» или «Вот есть нагрузочное тестирование. Классно, но я тут ни при чём». Очень даже при чём.

Если непонятно, что дальше учить, почему бы не углубиться в эти вещи. Начать что-то ломать-крушить самому или привлечь кого-то со стороны, чтобы провести UX-исследования. Достаточно попросить знакомого не из IT-сферы протестировать концепт вашего продукта. На словах объяснить, что ожидается, и посмотреть, как знакомый пытается пройти пользовательский сценарий. 

После того как разработчик увидит UX-тестирование в действии, у него отпадут вопросы, зачем оно нужно, — это перевернёт всё его понимание разработки.

Что делать:

• Ломать-крушить

• Проводить UX-исследования

Какие инструменты применить:

• Рефлексия

11. Возглавить разработку новой библиотеки ⬆️

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

Что делать:

• Изучить область

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

• Наладить коммуникации

Какие инструменты применить:

• Jira, Trello и другие инструменты для управления проектами

• Книга «45 татуировок менеджера»    

12. Задокументировать проект ➡️

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

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

Что делать:

• Читать текущую документацию

• Исправлять её или писать новую

Какие инструменты применить:

• Google

• Книги

Конец пути

Наш воображаемый джун преодолел большой путь за короткий интервал времени и преуспел во всём – стал звездой. В жизни путь будет дольше и этими двенадцатью активностями не ограничится.

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

Самодиагностика и несколько советов

Возможно, вы готовы только на какие-то отдельные активности, другие вам не интересны или просто не являются приоритетом. Может, вы больше склоняетесь к горизонтальному росту, чем к вертикальному. Чтобы в этом разобраться, посмотрите на путь нашего героя и выберите пункты, которые вам по душе.

Например, вы готовы выступать на отчетном демо ⬆️, переезжать на новые технологии ➡️ и углубиться в UX-исследования ➡️. Делая такой выбор, вы в большей мере растёте по горизонтали.

Ситуация может быть противоположной: вы больше тянетесь в менеджеры. Например, вам больше нравится искать взгляд со стороны ⬆️, помогать осваиваться новичкам ⬆️ и доносить сложное простым языком ➡️.

Я создал диагностический тест, который определит вашу склонность за вас. Просто отметьте нужные чекбоксы: https://shoom1337.github.io/dev-diag/

Общие советы для всех разработчиков довольно банальны:

• Читайте про тайм-менеджмент

• Узнайте больше про метрики и статистику

• Берите более сложные задачи

• Продолжайте улучшать профессиональные навыки

Для тех, кто стремится к вертикальному росту, есть пара дополнительных советов:

• Составьте план развития

• Начните менторить других

• Станьте спикером

Надеюсь, всё у вас сложится, какой бы путь вы ни выбрали. Продолжайте работать и заботьтесь о себе!

---

На курсах программирования в Практикуме за каждым потоком студентов закреплён наставник. Это эксперт в индустрии, который отвечает на вопросы и объясняет задания, если что-то непонятно. А ещё он мотивирует и вдохновляет. Мы верим, что расти в профессии с поддержкой легче, чем без неё.