Привет! Я Рома, менеджер продукта в Яндекс.Практикуме, где развиваю курс «Мидл Python-разработчик». Мы делаем из начинающих разработчиков крепких мидлов с инженерным мышлением. Сегодня хочу поделиться небольшими заметками о том, над чем стоит работать, если вы джуниор, который хочет стать мидлом.

Я не разработчик, поэтому эта статья во многом отражает взгляд со стороны. Ответить на вопрос «Как джуниор Python-разработчику стать мидлом за год?» — не такая простая задача, как может показаться на первый взгляд. Здесь спряталось сразу несколько челленджей:

1. Ответить на вопрос, кто такой джуниор: определить отправную точку, базу навыков, с которой мы будем рассматривать рост.
2. Ответить на вопрос, кто такой мидл — финальная точка нашего путешествия. Конечно же, во всех компаниях мидлы разные, а нам нужно какое-то взвешенное среднее, не оторванное от реальности.
3. Ответить на вопрос, почему рассматриваем рост именно за год. Не ради красивой круглой цифры же, верно?

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

Почему в индустрии у всех разные взгляды на рост разработчика:

1. Понимание грейдов джуниор-мидл-сениор и требования к кандидатам разнятся от компании к компании, а некоторые вообще говорят, что так разработчиков делить нельзя.
2. Разные системы роста джуниор-разработчиков в разных компаниях (тут влияют не только требования по хардовым навыкам, но и корпкультура).
3. Каждый мидл или сениор рассуждает на эту тему через призму своего опыта и своего пути роста.

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

И хотя статья больше про бэкенд-разработку на Python, я сделал упор на общеприкладных скиллах, а не на умениях работать с конкретными технологиями. Реальные требования к кандидатам в плане инструментов разработки сильно различаются в зависимости от компании и задач. Поговорим про фундаментальные навыки, которые актуальны для роста в других направлениях бэкенд-разработки и разработки в целом. Так что если вы не питонист — не уходите, прочитайте до конца.

Какой ты джун

Итак, начнём закрывать наши челленджи. Первый — определиться, кто такой джуниор-разработчик и что он умеет. Давайте посмотрим, какие вообще бывают джуны.

Юнлинг

Первый этап развития начинающего разработчика — стажёр. Это ещё не полноценный джун — скорее его MVP. На этом уровне человек знает основы языка, но практики программирования у него нет. Его не нужно учить синтаксису — его нужно учить пользоваться языком, применять его в решении реальных задач. Чтобы дать стажёру задачу, нужно детально её расписать: сделай A, B и С, возьми такую технологию и используй вот этот приём.

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

Падаван

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

Давайте посмотрим на развитие этой стадии чуть подробнее.

Новичок

Разработчик, который буквально вчера принял своей первый оффер и уже жаждет влиться в команду и закрывать таски. Джун-новичок обладает достаточным набором академических знаний, чтобы выполнять простые задачи. Он умеет работать с документацией и может вытащить оттуда что-то полезное. Но знания процессов разработки больше теоретические, что приводит к ошибкам на разных стадиях написания кода. На этом этапе развития человек всё ещё учится тому, как применять язык для решения коммерческих и прикладных задач. Нормально, что он приходит к старшим коллегам и говорит: «У меня что-то ломается. Не могу это сделать. Помоги!» Ведь лучше задать вопрос, чем уйти в себя, не показать никакого результата и подвести команду.

Обыкновенный

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

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

Крепкий

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

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

Рыцарь-джедай

И вот он — заветный уровень мидла. Здесь человек превращается в самоходную боевую единицу в команде. Тимлид уверен, что, если даст задачу мидлу, она точно будет сделана.

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

А если будут проблемы, человек вовремя о них сообщит и предложит варианты решения, чтобы не выпасть из сроков.

Резюме роста

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

Представьте, что вы попали в исследовательский центр Британской Секретной службы в качестве инженера. Вашей команде нужно разработать машину для одного известного любителя коктейлей. Грейды инженеров в британской разведке такие же, как у нас в разработке: джуниор, мидл, сениор, тимлид, CTO.



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

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

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

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

И вот мы добрались до вершины — CTO или, на местный лад, Q. Он определит общие технические требования к машине, включая специфические. Он тесно общается с заказчиками — руководством Ми-6 и самим Бондом. Поэтому знает, что спорткар должен уметь превращаться в подводную лодку, чтобы миссия прошла успешно.

Мой выбор

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

Харды

Подобрались к самому интересному. Как и обещал, будет про технологии, но без конкретных названий.

Итак, на что стоит делать упор в своём развитии? Вот шесть главных аспектов.

1. Прокачивайте понимание, как работают технологии, которые вы используете
   Мидлу должны быть понятны те инструменты, которые он ежедневно использует. Джуниор-разработчику простительно просто писать код, который решает задачу, и не задумываться, как работают те или иные конструкции языка. Но если ты мидл, разработка не может быть для тебя магией.
   Важно задаваться вопросом, как работает код, который ты пишешь. Хорошо, если вы умеете объяснить принцип работы технологии или написанной программы другому человеку простыми словами.
   
   Как улучшать навык
   Возможно, вы когда-то слышали про принцип «Пять почему». Попробуйте применить его в разработке. Используете какую-то новую технологию и задайтесь вопросом, почему она подходит для решения этой задачи. Получив ответ: «Потому что она работает вот таким образом», изучите, почему она работает именно так.
   
   Скорее всего, даже три из пяти «почему» заставят вас достаточно глубоко покопаться в теме и дадут хорошее понимание исследуемого инструмента.
2. Учитесь декомпозировать задачи
   Когда начинающий разработчик получает задачу, у него есть соблазн сразу начать писать код. Из-за этого структура его решения выстраивается хаотически. Учитесь сначала продумывать ход решения в голове, строить архитектуру, а только потом кодить. Стройте связи: «Я буду решать задачу вот таким образом, потому что <причина 1>, <причина 2>. А вот здесь у меня такое техническое требование, поэтому я буду использовать <приём 1>, <приём 2>».
   
   Как улучшать навык
   
   • Учитесь выделять в задаче самое главное. Не гонитесь за идеальным решением сразу — вначале просто сделайте рабочее решение. Когда оно будет готово, ненадолго остановитесь, вы молодец. Самое время подумать, как можно улучшить это решение — сделать его более грамотным и оптимальным. Важно: что такое «рабочее» и «грамотное» решение, важно определять в самом начале, на этапе проработки задачи.
   • Выстраивайте для себя граф будущего решения с обоснованиями своих решений в ключевых точках. Это не только повышает качество вашего кода, но помогает защищать свой код и идеи перед коллегами.
   
   
3. Проходите и проводите code-review
   Первый этап — научиться правильно проходить код-ревью. Это софтовый навык: нужно уметь слушать обратную связь, не принимать критику кода как личную обиду и доставать из ревью полезные для себя вещи.
   
   А вот проводить ревью — это уже следующий уровень, который должен освоить мидл. Когда к вам попадает код другого человека, в первую очередь вы должны понять структуру программы на верхнем уровне. Отталкиваясь от этого, вы сможете подсказать человеку, что нужно исправить и улучшить.
   
   Хороший код-ревьюер не просто ищет баги в коде. Он подсказывает, как сделать решение более оптимальным, лаконичным и красивым. Он делится своим опытом и хорошими практиками, а ещё следит, чтобы код соответствовал общим принципам написания кода в команде.
   
   Как улучшать навык
   
   • Если у вас на работе нет культуры код-ревью, найдите человека уровнем выше, чем вы. Попросите его давать обратную связь по тому, что вы пишете. Иначе вы не поймёте, хорошо ли то, что вы сейчас делаете.
   • Проводите селф-ревью. Возвращайтесь к своему коду, думайте, какие есть ещё решения у задачи. Как выбрать между несколькими возможными вариантами решения. Нашли решение лучше — перепишите, проверьте свои догадки. Бывает полезно проводить селф-ревью в интерфейсе git уже после того, как вы оформили изменения в merge request. Смена обстановки поможет взглянуть на проделанную работу по-новому.
4. Подучите алгоритмы
   Да, я уже чувствую ваш скепсис. Ещё бы — человек из Яндекса не посоветовал учить алгоритмы.
   
   На самом деле алгоритмы и структуры данных полезны, потому что это очень фундаментальные вещи. В быстро меняющемся мире разработки они остаются неизменными. Мне кажется, что алгоритмы прежде всего стоит учить на прикладном уровне — понимать, в каких решениях коммерческой разработки они применяются и почему. Просто заучивать академические вещи не нужно — связывайте всё с практикой. Ваша цель — понимать причину и связь: почему и как это работает.
   
   Как улучшать навык
   
   • Самый простой путь — просто решать задачи на алгоритмы. Их много, например, на Leetcode. Если алгоритмы вам нужны в первую очередь для прохождения собеседований, это верный путь достичь своей цели. Если для общего развития, то не забывайте про связь с практикой. Просто нарешать 100 задач будет не так полезно, как глубоко обдумать практическое применение 5–10 из них.
   • Посмотрите курс Максима Бабенко «Алгоритмы и структуры данных поиска». Это правда стоит того: многие идут в ШАД именно ради курса Максима по алгоритмам.
   • Почувствуйте, что решать алгоритмические задачи может быть интересно и несложно. Вот наш разбор задачи по алгоритмам в помощь вашей мотивации.
5. Развивайте насмотренность
   Чтобы быть классным разработчиком, нужно знать, что сейчас происходит в индустрии. Чтобы принимать правильные решения в своих задачах, нужно увидеть как можно больше хороших решений других разработчиков. Хотя не только хороших решений — ошибок тоже
   
   Знаете, почему сениор может сразу написать классное решение? Потому что он за свою карьеру совершил много ошибок. Много-много раз сделал что-то неправильно и теперь знает сотню способов, как делать не надо. Начинающий разработчик, наоборот, знает только несколько способов сделать так, чтобы работало.
   
   Как улучшать навык
   
   • Не бояться совершать ошибки. Насмотренность приходит с опытом, её можно приобрести только практикой. Делайте ошибки и изучайте опыт своих коллег.
   • Пилите собственные проекты с технологиями, с которыми бы никогда не столкнулись на основной работе. Новый язык, база данных, фреймворк — всё это расширяет ваш кругозор и пополняет багаж знаний.
   • Изучайте публичные кейсы компаний, где они рассказывают о своих ошибках или, наоборот, о достижениях в решении сложных задач.
6. Учитесь писать скучный код
   Когда пишете код, думайте, насколько он будет понятен человеку, который в первый раз его увидит. Хотите внедрить нетривиальное и нестандартное решение — трижды подумайте. Я один раз услышал очень хорошую фразу, которая показывает всю ценность этого навыка. Делюсь ей с вами: «Чем скучнее и понятнее ваш код, тем меньше вероятность, что вас поднимут в час ночи и заставят его чинить».

Софты

Фуух, с хардовой частью разобрались. А что там про софты? Что это за зверь и зачем он нужен разработчику?

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

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

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

1. Будьте самостоятельны
   Ключевой навык мидл-разработчика — самостоятельный поиск информации, проведение исследований и принятие решений. Кстати, принятие решений очень важно, потому что мидл — это разработчик, которого не надо водить за ручку. Он сам должен писать решения по задаче и доказывать их другим разработчикам — на код-ревью или просто поболтав у кулера.
   
   Мидл может взять таск, где есть несколько активностей, разложить их в план и приступить к работе. Над ним нужен контроль только из серии «Как у тебя дела? Что ты делаешь сейчас?»
2. Научитесь видеть проблему бизнеса в технической задаче
   Помните, что на самом деле ваша задача — не просто написать код. Код — всего лишь инструмент. Вы как разработчик должны делать техническое решение для задачи бизнеса. Учитывайте это, когда продумываете своё решение и оцениваете его оптимальность.
   
   Иногда важно аргументировать, почему не нужно делать задачу, которую вам поставили, а не бросаться писать код. Например, если вы видите, что на реализацию текущих требований команда потратит очень много ресурсов и есть более простое и дешёвое решение. Учитесь получать информацию по задаче от нетехнических коллег и объяснять им технические ограничения.
3. Показывайте увлечённость разработкой
   Никому в команде не нужен человек, который не мотивирован делать то, чем он сейчас занимается. Учитесь рассказывать интересные истории о своей работе и достигнутых результатах. Говорите о том, почему вам интересно было заниматься тем или иным проектом.
   Грустно, когда на собеседовании задаёшь вопрос: «Расскажите, чем вы занимались на прошлой работе?», а кандидат отвечает: «Ну я решал задачки, писал код. Был Джанго, писали на нём небольшой сервис. Часто делал простые задачки с данными». Рассказывайте про свой опыт через призму того, почему у вас была мотивация его получить, и какие выводы вы для себя сделали.
   
   Если про работу сложно рассказать что-то интересное, используйте собственные проекты. «На работе решал стандартные задачи на Django, а вот в собственном проекте недавно попробовал FastAPI. Классный опыт, потому что <причина 1>, <причина 2>. По-новому взглянул на <приём в разработке 1> и <приём в разработке 2>.» Вот это уже хочется обсудить с человеком.

Саммари

1. Чётких грейдов разработчиков в индустрии нет, и это нормально: разные команды выдвигают разные требования в зависимости от своих задач.
2. Тем не менее можно выделить критерий вашего роста как разработчика — ответственность и сложность задач, которые вы можете решить самостоятельно.
3. Мидл должен быть самостоятельным разработчиком и решать большинство падающих на него задач без помощи старших разработчиков.
4. Опыт работы с конкретными технологиями часто не так ценен, как фундаментальные навыки. Если вы глубоко разбираетесь в технологиях, с которыми уже работали, и показываете способность и желание быстро изучать новые — этого часто достаточно, чтобы попасть в компанию, где ваш опыт не покрывает весь стек технологий.
5. Изучайте чужой код, пробуйте новые технологии, не бойтесь совершать ошибки. Это поможет вам развить насмотренность и профессиональный кругозор.
6. Сейчас век командной разработки, поэтому софты не менее важны, чем харды. Компании дешевле подтянуть нового сотрудника по техническим навыкам, чем вписывать в команду некомандного человека.
7. Подходите к своему развитию осознанно. Выбирайте место работы, отталкиваясь от людей, с которыми вы хотите работать, и задач, которые вас драйвят. Стройте процесс учёбы и получения новых знаний так, чтобы он приносил удовольствие. Например, мы с командой обожаем кино, поэтому построили курс вокруг разработки онлайн-кинотеатра, аналога Netflix (да, отсылки к фильмам в этой статье — не случайность). Подумайте, что может дать вдохновение вам?