Как Младший Разработчик Python Может За Год Стать Средним Разработчиком?

Привет! Я Рома, продакт-менеджер Яндекс.

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

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

Я не разработчик, поэтому данная статья во многом отражает взгляд стороннего наблюдателя.

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

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

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

3. Ответьте на вопрос, почему мы рассматриваем рост за год. Не ради красивой круглой цифры, правда?

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

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

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

2. Разные системы роста младших разработчиков в разных компаниях (на это влияют не только требования к хардскиллам, но и корпоративная культура).

3. Каждый средний или старший обсуждает эту тему через призму своего опыта и своего пути роста.

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

И хотя статья больше посвящена бэкенд-разработке на Python, я сосредоточился на общих навыках применения, а не на умении работать с конкретными технологиями.

Реальные требования к кандидатам в плане инструментов разработки сильно различаются в зависимости от компании и задач.

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

Так что если вы не питонист, не уходите, дочитайте до конца.

Какой ты джун?

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

Юньлин

Это еще не полноценный июнь – скорее он MVP .

На этом уровне человек знает основы языка, но не имеет практики программирования.

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

Чтобы дать стажеру задание, нужно его подробно описать: сделать А, Б и С, взять эту технологию и использовать эту технику.

Стажеры обычно не работают над задачами, важными для проекта.

Их бросают, например, из-за технического долга.

Если они ошибутся, компания не потеряет деньги.

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

Приобретение опыта по ходу дела.

Падаван

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

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

Новичок

У новичка Джун достаточно академических знаний для выполнения простых задач.

Он умеет работать с документацией и может извлечь из нее что-то полезное.

Но знание процессов разработки носит скорее теоретический характер, что приводит к ошибкам на разных этапах кодирования.

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

Это нормально, что он приходит к своим старшим коллегам и говорит: «Что-то сломалось.

Я не могу этого сделать.

Помощь! Ведь лучше задать вопрос, чем замкнуться в себе, не показать никакого результата и подвести команду.

Обычный

В этом вам также помогут старшие товарищи.

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

Вы начинаете понимать, какие проблемы можно преодолеть самостоятельно.

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

Здесь должно появиться: «Я пробовал то и это, но не получилось.

Нам нужна помощь, чтобы понять, почему это происходит и где еще искать решение».

Сильный

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

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

Например, выпускник сильного технического вуза.

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

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

Здесь человек превращается в самоходную боевую единицу в команде.

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

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

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

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

Он также может брать на себя исследовательские задания — например, изучить, как работает какая-то технология и можно ли ее использовать в проекте.

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

Обзор роста

И это относится не только к младшим стадиям развития, но и к ступеням развития вообще.

Представьте, что вы работаете инженером в исследовательском центре британской секретной службы.

Вашей команде необходимо разработать машину для одного известный любитель коктейлей .

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

Джуниор в этой машине будет делать что-то маленькое и некритическое в рамках всего проекта.

Например, ему дадут сделать аудиоплеер.

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

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

Но есть и польза от выполнения задачи.

Работа тяжелая, напряженная, и иногда спецагент может отдохнуть под любимую группу.

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

Например, это может быть система выброса нежелательных пассажиров из автомобиля.

Задача важная — в нужный момент такая функция может спасти жизнь нашему спецагенту.

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

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

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

Эту часть возьмет на себя старший.

Руководитель группы возьмет на себя ответственность за развитие какого-то значимого направления машиностроения.

Система катапультирования является одной из боевых функций машины.

Но есть еще ракеты, пулеметы в фарах или даже боевые лазеры.

Вам нужно подумать о том, как все системы будут взаимодействовать друг с другом.

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

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

И вот мы достигли вершины – CTO или, по-местному, вопрос .

Он определит общие технические требования к машине, в том числе и конкретные.

Он тесно общается с заказчиками – руководством Ми-6 и самим Бондом.

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

Мой выбор

Во-первых, это действительно хороший темп роста для разработчика.

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

Ключевое слово — рассмотреть.

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

Харды

Как и было обещано, речь пойдет о технологиях, но без конкретных названий.

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

1. Улучшите понимание того, как работают используемые вами технологии.

   Средний должен понимать инструменты, которые он использует каждый день.

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

   Но если вы игрок среднего звена, развитие может не быть для вас волшебством.

   Важно спросить себя, как работает код, который вы пишете.

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

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

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

   Когда вы получите ответ: «Потому что это работает так», изучите, почему это работает именно так.

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

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

   Из-за этого структура его решения построена хаотично.

   Научитесь сначала продумывать решение в голове, строить архитектуру и только потом кодировать.

   Наладьте связи: «Я решу проблему таким образом, потому что , .

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

   ” Как улучшить навык

   • Научитесь выделять самое важное в задаче.

     Не гонитесь за идеальным решением сразу — просто сначала придумайте работающее решение.

     Когда все будет готово, остановитесь на минутку, у вас отлично получается.

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

     Важно: что такое «рабочее» и «грамотное» решение, важно определить в самом начале, на этапе проработки проблемы.

   • Постройте для себя график будущих решений с обоснованиями ваших решений в ключевых точках.

     Это не только улучшает качество вашего кода, но и помогает защитить свой код и идеи перед коллегами.

3. Идите вперед и проведите код-ревью Первый этап — научиться правильно проходить проверку кода.

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

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

   Когда вы получаете чужой код, первое, что вам нужно сделать, это понять структуру верхнего уровня программы.

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

   Хороший рецензент кода не просто ищет ошибки в коде.

   Он подсказывает, как сделать решение более оптимальным, лаконичным и красивым.

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

   Как улучшить навык

   • Если у вас на работе нет культуры проверки кода, найдите кого-нибудь на более высоком уровне, чем вы.

     Попросите его дать отзыв о том, что вы пишете.

     Иначе вы не поймете, хорошо ли то, что вы сейчас делаете.

   • Проведите самоанализ.

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

     Как выбрать между несколькими возможными решениями.

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

     Может быть полезно провести самопроверку в интерфейсе git после того, как вы отправили изменения в мерж-реквест. Смена обстановки поможет по-новому взглянуть на проделанную работу.

4. Тренируйте свои алгоритмы Да, я уже чувствую ваш скептицизм.

   Конечно, человек из Яндекса не советовал изучать алгоритмы.

   На самом деле алгоритмы и структуры данных полезны, потому что это очень фундаментальные вещи.

   В быстро меняющемся мире развития они остаются постоянными.

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

   Не нужно просто заучивать академические вещи – соединяйте все с практикой.

   Ваша цель — понять причину и связь: почему и как это работает. Как улучшить навык

   • Самый простой способ — просто решить алгоритмические задачи.

     Их много, например, на Литкод .

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

     Если для общего развития, то не забывайте о связи с практикой.

     Просто решить 100 задач будет не так полезно, как глубоко задуматься о практическом применении 5–10 из них.

   • Смотрите курс Максима Бабенко» Алгоритмы поиска и структуры данных «Оно того стоит: многие идут в ШАД специально на курс Максима по алгоритмам.

   • Узнайте, как решение алгоритмических задач может быть увлекательным и простым.

     Здесь наш анализ проблемы в соответствии с алгоритмами, чтобы помочь вашей мотивации.

5. Развивать наблюдательность.

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

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

   Хотя не только хорошие решения, но и ошибки Знаете, почему старший может сразу написать отличное решение? Потому что за свою карьеру он совершил много ошибок.

   Он много-много раз делал что-то не так и теперь знает сотню способов не делать этого.

   Начинающий разработчик, наоборот, знает лишь несколько способов заставить это работать.

   Как улучшить навык

   • Не бойтесь совершать ошибки.

     Наблюдение приходит с опытом; его можно приобрести только практикой.

     Делайте ошибки и учитесь на опыте своих коллег.

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

     Новый язык, база данных, фреймворк — все это расширяет ваш кругозор и расширяет базу знаний.

   • Изучите публичные кейсы компаний, где они рассказывают о своих ошибках или, наоборот, о своих достижениях в решении сложных задач.

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

   Если вы хотите реализовать нетривиальное и нестандартное решение, подумайте трижды.

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

   Делюсь с вами: «Чем скучнее и понятнее ваш код, тем меньше вероятность, что вас разбудят в час ночи и заставят его исправлять».

Программное обеспечение

А что насчет программного обеспечения? Что это за зверь и зачем он нужен разработчику? Лови ответы.

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

Отсутствие программного обеспечения может свести на нет всю вашу гениальность в разработке.

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

Чтобы вывести на рынок хорошие технические решения и сделать это в необходимые сроки, сил одного человека уже недостаточно.

В долгосрочной перспективе команда разработчиков всегда превзойдет гения-одиночку.

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

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

Мы, наверное, все слышали об умении общаться.

Какие еще мягкие навыки могут понадобиться в развитии?

1. Быть независимым Ключевой навык мидл-разработчика — самостоятельно искать информацию, проводить исследования и принимать решения.

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

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

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

   Ему нужен контроль только из серии «Как дела? Что ты сейчас делаешь?"

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

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

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

   Научитесь получать информацию о задаче от нетехнических коллег и объяснять им технические ограничения.

3. Проявляйте стремление к развитию Никому в команде не нужен человек, у которого нет мотивации делать то, что он делает сейчас.

   Научитесь рассказывать интересные истории о своей работе и достигнутых результатах.

   Расскажите, почему вам было интересно заняться тем или иным проектом.

   Грустно, когда на собеседовании задаешь вопрос: «Расскажи, чем ты занимался на прошлой работеЭ», а кандидат отвечает: «Ну, я решал задачи, писал код. Был Django, на нем написали небольшой сервис.

   Я часто решал простые задачи с данными».

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

   Если сложно рассказать что-то интересное о своей работе, используйте собственные проекты.

   «На работе я решал стандартные задачи на Django, но в своем проекте недавно попробовал FastAPI. Крутой опыт, потому что , .

   Я взглянул свежим взглядом на и ».

   Это то, что я хочу обсудить с человеком.

Краткое содержание

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

2. Однако можно выделить критерий вашего роста как разработчика – ответственность и сложность задач, которые вы можете решить самостоятельно.

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

4. Опыт работы с конкретными технологиями часто не так ценен, как фундаментальные навыки.

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

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

   Это поможет вам развить наблюдательность и профессиональный кругозор.

6. Сейчас эпоха командной разработки, поэтому программное обеспечение не менее важно, чем «железо».

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

7. Подходите к своему развитию осознанно.

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

   Например, я и моя команда любим кино, поэтому курс мы построили вокруг разработки онлайн-кинотеатра, аналога Netflix (да, упоминания фильмов в этой статье не случайны).

   Подумайте, что может подарить вам вдохновение?

• Компьютерное Наследие Сша: Марк I

  19 Oct, 24

• Adobe Выходит На Рынок Офисного Программного Обеспечения

  19 Oct, 24

• По Следам Интеллекта 2

  19 Oct, 24

• Дуть Или Не Дуть?

  19 Oct, 24

• Заблуждения Аналитиков

  19 Oct, 24

• Носимые Устройства? Да, Если Только Внутри Себя

  19 Oct, 24

• Краткая История Javascript. Часть 1

  19 Oct, 24

• Ntdll!Ldrhotpatchroutine И Обход Dep/Aslr (Ms13-063)

  19 Oct, 24

• Мониторинг Rabbitmq В Zabbix И Скрытые Возможности Ключа Zabbix

  19 Oct, 24

• Миллион Zune Будет Продан К Июню

  19 Oct, 24