Сам себе ментор: что ещё делать, кроме работы, чтобы подрасти

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

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

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

Шаг №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. Выступить на отчётном демо

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

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

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

А еще демо — это отличный повод для тимбилдинга