Осознанная Меркантильность | Антон Назаров

Как джуниору стать мидлом?

Added 2022-12-23 17:37:42 +0000 UTC

Вы нашли первую работу, обрели гордый статус джуниора и самое страшное будто бы позади. Можно выдохнуть, но не стоит расслабляться слишком сильно. Если решите просто плыть по течению текущих задач, совсем скоро можно обнаружить себя в болоте без мотивации и сил к профессиональному росту. Чтобы этого избежать, мы собрали полезные советы и подсказки вместе с Александром Ильиным — Python/Go разработчиком и автором канала Digital Ninja. Эта статья — конспект недавнего стрима.

Как джуниору стать мидлом?

— В чём отличие грейдов Junior и Middle?

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

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

— Выходит, в одной компании не вырасти?

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

- перформанс-ревью, когда смотрят на твои предыдущие заслуги и успехи за время работы;

- проверка знаний, когда вас гоняют вопросами по технологиями из стека компании или процессам, проверяя глубину их понимания.

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

В смелость упирается и крайне полезный «рост от коллег». Его суть в том, чтобы как можно активнее познакомиться с людьми на новом месте и найти среди них тех, кто в силу опыта и желания сам не против поделиться знаниями и помочь. Особенно полезно, если таким человеком оказывается тимлид — он поможет быстро вкатиться в процессы и заодно оценит вашу инициативность как руководитель».

— А как расти на рынке?

Рынок оценивает вас через собеседования. Здесь важно то, как вы сможете подать и подтвердить свои навыки. Отсобеседуетесь дежурно и без заморочек — получите средний оффер. Докажете, что вы крутой и нужный компании специалист — предложение может стать значительно выше.

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

- при смене работы вы наращиваете опыт. Новые фреймворки, библиотек и другое расширение стека всегда будет играть на пользу и увеличивать вашу ценность;

- вы видите больше бизнес-доменов и можете поработать в разных сферах над разными продуктами.

Получается, ответ нам уже знаком. Хотите расти на рынке? Наберитесь смелости, упорства и не старайтесь отсиживаться невидимкой год за годом.

— Ошибки, задачи и экспертиза

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

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

Отдельно стоит поговорить о тасках. Кто знаком с джедайскими практиками знает, что задачи бывают красными и зелёными. К первой группе относятся рутинные повторяющиеся практики, которые вы с каждым разом делаете всё быстрее и тратите меньше сил, а вторая группа — творческие задачи. Например, новая фича, которую вы не знаете как делать, или настройка CI. Именно такая практика становится наиболее полезной, ускоряет ваш рост и прокачивает опыт. Когда вы делаете что-то новое, читаете материалы в интернете и бегаете по stack overflow в поисках подсказок, вы увеличиваете свою полезность. Логика проста: нельзя набраться опыта, если делать только то, что вы и так умеете.

Компаниям выгодно, чтобы вы росли и совершенствовались. Очевидно быстрее и легче повысить сотрудника, который уже какое-то время работает, знает всю кухню изнутри и влился в коллектив. Но в некоторых случаях ушлые работодатели могут быть не заинтересованы в системном росте сотрудников. Например, если заказчик в требованиях прописал, что ему нужна команда из 20 мидлов и 10 синьоров, которые есть в компании, но некоторые мидлы пришли просить повышения. Часто в такую ситуацию можно попасть в аутсорс-компаниях, которые разрабатывают ПО на заказ. Бывают работодатели, которым как раз нужно, чтобы вы условно вечно выполняли рутинные задачи. Задерживаться в них не нужно. Либо можете переиграть всех и найти, как максимально оптимизировать и автоматизировать рутину, чтобы она выполняла себя сама 🙂

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

— Хард скиллы, учёба и книги

В первую очередь полезно ещё на ранних этапах карьеры задавать себе вопрос о качестве вашего кода и уровне технической экспертизы. Кто-то измеряет эти абстрактные показатели уровнем покрытия тестов, соответствию SOLID или чему-то ещё. На самом деле, в рабочих реалиях определить их проще. Ваш код будет качественным, когда коллеги-разработчики смогут читать и понимать его без ругательств. Если на работе всё так — считайте себя молодцом. Объективно определить хороший код можно как масштабируемый, с возможностью удобного внедрения новых фичей, читаемый и желательно без багов.

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

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

Пример из опыта Александра Ильина: во время работы в Ozon он какое-то время занимался сервисом, который ответственен за блок комментариев и звёзды оценки пользователей под каждым товаром. Ради интереса он спросил у продакта, что будет, если убрать блок звёзд и комментариев из товара — согласно статистике, конверсия падала на зверские 50%. Когда видны конкретные цифры, сразу становится ясна ценность вашей работы, не так ли?

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

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

Время, которое вы не потратили на пустые споры и волнения по поводу токсичных коллег, гораздо полезнее потратить на учёбу в любой форме. Это не обязательно должно быть многочасовое сидение за курсами. Слушайте подкасты, смотрите видео разных блогеров и компаний — это хорошая база для развития общей эрудиции в профессии. Так вы сможете узнать новые термины, мнения и тенденции, которые появляются и набирают популярность в вашей сфере. Кроме того, не стесняйтесь глубже изучать технологии, которые вы пусть даже минимально используете в работе. Например, если Docker для ваших задач выглядит как одна строчка кода, попробуйте копнуть его чуть глубже. Можно просто вбить «Docker для новичков» и посмотреть пару видео на Youtube.

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

Всё ещё помогают в развитии книги. Не ленитесь читать тематическую литературу по своему профилю, в любом направлении её хватит на несколько лет вперёд. Не рекомендуется читать узкоспециализированные книги по разработке: с момента их написания до издания может пройти несколько лет, и язык за это время переживёт несколько обновлений. В итоге книга будет просто неактуальной. Лучше в начале карьеры читать вечную классику про алгоритмы, чистый код или computer science. И не забывайте про менторов — никто не посоветует вам книг и других материалов лучше, чем люди, которым уже платят деньги за ту работу, которую вы только хотите найти или нашли. Вот здесь можно найти себе ментора.

Боб Мартин «Чистый код», «Рефакторинг» и другие базовые книги, с которыми даже можно не полностью соглашаться. Их ценность в том, что вы узнаете мнение людей, которые имеют вес в интересной вам индустрии, начнёте говорить на одном языке с коллегами и в целом более плавно вкатитесь в профессиональное сообщество. Ещё можно попробовать «Дедлайн» и «Проект Феникс» — книги, которые рассказывают о том, как делают продукты. Также небесполезной будет книга «Инноваторы» Уолтера Айзексона, из которой можно узнать о глобальном пути развития технологий с XIX века до наших дней.

— Soft Skills, Scrum и другие удивительные вещи

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

Бывает так, что в новой задаче вам не понятно вообще ничего — не старайтесь сразу свалить этот ком на других. Попробуйте разобрать загадку на составные части: почитайте вводные, пересмотрите код, вернитесь к описанию и сопоставьте всё, что увидели и попробовали сделать. Только тогда стоит идти к коллегам с вопросами и вместо абстрактного «я ничего не понимаю» давать им более зрелое «я получил задачу, попытался разобраться, сделал это и это, но не смог понять вот здесь». Никто не сможет объяснить вам всё. Попробуйте загуглить и сделать хотя бы часть, а с оставшимся обратиться к кому-то на работе, ментору или компетентному другу. Задавайте конкретные вопросы и старайтесь найти максимум ответов самостоятельно — так вы будете расти быстрее и заслужите любовь и уважение на работе.

Здесь же можно упомянуть Scrum. Часто среди разработчиков встречается скептическое мнение насчёт проджектов и внедряемых ими практик. В итоге писатели невероятно чистого и бесценного кода снисходят до новой «игры», лишь бы побыстрее её закончить и вернуться к своим делам. Стоит помнить, что скрам не софт скилл, а самостоятельная технология. Она помогает вашей команде давать результат за определённое время и по определённым правилам. Не погружайтесь в предрассудки и снобизм — лучше освойте полезный вид гибкой методологии и разберитесь в его артефактах. Скрам работает и находит своё подтверждение на практике в крупнейших компаниях, а токсичность за годы доказала лишь свой вред. Поэтому с процессами и правилами в компании придётся считаться.

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

И снова хочется напомнить: на работе не надо молчать. У джунов распространена проблема, когда они до последнего не говорят о своих непонятках с задачей, а затем все сложности могут обнаружиться за полчаса до дедлайна. Вы не спасаете планету и не стыкуете космический корабль с МКС — право на ошибку в IT есть у каждого. Просто не стесняйтесь своевременно задавать вопросы и не откладывайте свои проблемы в долгий ящик. Так вы не подведёте себя и коллег в ответственный момент.

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

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