Перевод статьи «Navigating Software Engineering Career Paths».
Стоит ли углубиться в изучение одного из фронтенд-фреймворков или лучше изучить их все? Как определить, готов ли ты к позиции сеньора? Над приобретением каких навыков стоит поработать?
Эти вопросы очень популярны в такой быстро меняющейся сфере деятельности как разработка программ и, в частности, фронтенд-разработка, а ответы на них сложно найти.
Ресурсы по вопросам карьеры в сфере разработки
К счастью, есть целый ряд отличных ресурсов по вопросам карьеры: топовые компании публикуют свои «дорожные карты», на которые можно ориентироваться, оценивая свой прогресс.
Джонни Берч, дизайнер из Великобритании, собрал все эти дорожные карты в один список на progression.fyi.
Но во всем этом все равно тяжело разобраться. Ресурсов тысячи, и все немного отличаются друг от друга. В некоторых дорожных картах больше уровней, чем в других, в некоторых используются какие-то свои названия этих уровней, где-то в карьерный путь разработчика включен и менеджмент, а где-то — нет. Одни ресурсы ориентируются на дизайн, другие — на инженерию.
Но есть в этих ресурсах и много сходного, что позволяет, на мой взгляд, нарисовать какую-то общую картину. Этот пост — попытка создать дорожную карту для понимания того, так выглядит продвижение по карьерной лестнице в нашей отрасли.
Для каждого тайтла я собрал:
- набор типичных характеристик,
- набор вопросов, которые стоит себе задать, чтобы понять, вышли вы уже на этот уровень или еще нет,
- список вещей, на которых стоит сфокусироваться,
- несколько рекомендованных ресурсов.
Примечание. Эта дорожная карта не совсем полная, но я считаю, что ею в любом случае уже можно поделиться с сообществом. В частности, я не писал, на чем следует сосредоточиться разработчику на высшем уровне индивидуальной работы, а также не указывал никаких ресурсов для таких разработчиков. То же самое пропущено и относительно менеджерских позиций. Если вы занимаете одну из таких позиций и можете дополнить эту дорожную карту, — добро пожаловать в комментарии.
Основные оговорки
Несколько вещей, о которых стоит знать, читая эту статью:
- Многие опубликованные дорожные карты карьерного пути разработчика разделяют навыки по категориям (технические навыки, коммуникационные, лидерские, навыки командной работы и т. д.), и в каждой категории показывают отдельную шкалу. Я решил для простоты пользоваться одной шкалой, но вы заметите, что на разных позициях делается упор на разные группы навыков.
- Не каждый инженер непременно проходит все указанные этапы. Многие вполне счастливы, став сеньорами, и никуда дальше не продвигаются. На каждом отдельном этапе есть определенное пространство для роста (как в плане навыков, так и в плане зарплаты) в рамках текущей позиции.
- В маленьких компаниях обычно бывает меньше формальных уровней, иногда их вообще только два или три. А вот в больших корпорациях существуют более четкие градации. Но вы можете пользоваться дорожной картой из этой статьи независимо от того, какой официальный тайтл имеете на работе. Цель карты — помочь вам понять, на каком этапе карьеры вы находитесь и на чем будет полезно сосредоточиться дальше.
- Менеджмент это совершенно отдельный карьерный путь. Его не назовешь «естественным» следующим шагом. Менеджер совершенно не обязательно находится на более высоком уровне, чем инженеры. В большинстве дорожных карт указывается, что в плане зарплаты менеджер низкого уровня примерно равен ведущему инженеру или даже сеньору.
Технический путь
Разработчик-джуниор
Это первый шаг в индустрии. Обычно на такие позиции попадают сразу после университета или курсов. Все мы с этого начинали!
Характеристика
- Обычно 0-2 года опыта.
- Обычно работает над четко поставленными задачами.
- Зачастую много занимается исправлениями багов.
- Нарабатывает навыки, знакомится с рабочими процессами.
- Учится учиться.
Вопросы, которые можно задать себе на этом уровне
- Можете применять базовые знания в своей сфере деятельности? (Бэкенд разработчик — концепции информатики, базы данных, серверы; фронтенд-разработчик — HTML, CSS, доступность и т. п.).
- Умеете работать над задачами в порядке их приоритетности и доводить работу до конца?
- Активно ли вы работаете над улучшением своих навыков?
На чем стоит сфокусироваться
- Нужно работать над углублением знаний в рамках одной специализации. Например, фокусироваться на фронтенде или бэкенде, выбрать фреймворк и хорошо овладеть им.
- Нужно сосредоточиться на выработке хороших привычек. Привычка учиться, быть продуктивным каждый день, привычка составлять списки дел — все это вам пригодится в долгосрочной перспективе.
Ресурсы
Примечание: вы найдете множество специализированных ресурсов для каждой сферы деятельности. Я не буду подробно перечислять все, а лучше укажу более общие ресурсы, подходящие для всех.
- FreeCodeCamp
- JSParty #97 — learning how to learn
- Книга «Чистый код: создание, анализ и рефакторинг».
Разработчик-мидл
Это уровень между джуниором и сеньором. Во многих компаниях такая позиция называется просто «разработчик», а в стартапах это зачастую вообще единственный тайтл, так что ориентироваться только на название не стоит.
Характеристика
- Обычно 2-5 лет опыта.
- Умеет проектировать и реализовывать функционал в той сфере, где уже имеет опыт.
- Следует установленным шаблонам и соглашениям без внешнего надзора.
- Может самостоятельно отлаживать свой код.
- Принимает участие в технических дискуссиях на уровне команды.
Вопросы, которые можно задать себе на этом уровне
- Можете ли вы взяться за маленькую или среднюю фичу и реализовать ее от начала до конца практически самостоятельно?
- Встречаясь с проблемами, можете ли вы самостоятельно разобраться с ними?
- Участвуете ли вы в командных обсуждениях решений и выбора технологий?
На чем стоит сфокусироваться
- Нужно продолжить работать над своей специализацией и учиться создавать вещи от начала до конца.
- Учитесь говорить о вещах, связанных с вашей специальностью. Участвуйте в дискуссиях, дебатах, поисках лучших подходов. Можно начать писать посты для блога или выступать с речами на митапах.
- Начинайте понемногу изучать системы, с которыми взаимосвязана ваша специализация. Возможно, вам пока не нужно досконально в них разбираться, но следует знать об их существовании и о том, как они взаимодействуют с тем, что вы делаете.
Ресурсы
- Книга «Совершенный код».
- Книга «Программист-прагматик».
Разработчик-сеньор
На этом этапе вы начинаете выходить за границы областей, напрямую связанных с вашей работой. Вы осваиваете другие части технического стека и можете углубиться даже в не совсем технические темы.
Многие инженеры останавливаются на этом этапе, и это нормально. Дальнейшее продвижение предполагает, что ваша работа будет все менее связана с написанием кода.
Характеристика
- Обычно 5 и больше лет опыта.
- Начинает брать на себя обязанности техлида.
- Обычно занимается целыми сервисами или крупными компонентами.
- Выступает в роли наставника для начинающих разработчиков, дает фидбэк по результатам ревью кода.
- Занимается разработкой и поддержкой стандартов и процедур.
- Понимает, как «его» сервис/компонент связан с бизнесом в целом.
- Умеет эффективно коммуницировать с дизайнерами, менеджерами продуктов и т. д.
- Умеет рассказывать (устно и письменно) о технических решениях и концепциях и обсуждать их (написание статей в блогах, написание документации, выступления на конференциях и т. п.).
Вопросы, которые можно задать себе на этом уровне
- Занимаетесь ли вы разработкой целого сервиса или крупного компонента (работая над всеми его частями самостоятельно)?
- Вы регулярно даете фидбэк джуниорам, как по поводу ревью, так и в других случаях?
- Вы участвуете в создании стандартов (например, качества кода) и внедрении процедур (например, scrum) в вашей команде?
На чем стоит сфокусироваться
- Совершенствуйте свои навыки коммуникации, как устной, так и письменной. Вы должны уметь четко и понятно излагать свою точку зрения, как после подготовки, так и экспромтом.
- Изучайте, как работают и взаимодействуют все системы вашей программы. Вы должны не только быть экспертом в своей специализации, но и хорошо разбираться в работе всей системы в целом.
- Учитесь разговаривать с другими инженерами с глазу на глаз, давая обратную связь или советы.
- Начинайте разбираться в том, как технические решения влияют на бизнес. Каким образом ваша компания получает прибыль от программного обеспечения, которое вы разрабатываете? Какие его части важны для бизнеса, а какие не очень?
Ресурсы
- Книга «Чистая архитектура. Искусство разработки программного обеспечения».
- Статья «On Being a Senior Engineer».
Ведущий разработчик
Иногда ведущего разработчика называют техлидом. Это одна из самых сложных промежуточных позиций в индустрии, потому что, находясь на ней, вы по-прежнему крепко связаны с техническим стеком, но среди ваших прямых обязанностей внезапно оказываются вещи, сильно связанные с работой с людьми.
Характеристика
- Обычно 8 и больше лет опыта.
- Связан с техническим менеджментом проектов.
- Делегирует задачи и проекты другим разработчикам.
- Разбирается в вопросах мотивации членов команды и их карьерных целях.
- Регулярно дает фидбэк членам команды в вопросах карьерного роста, продвижения к целям, относительно того, что можно улучшить, а также благодарит и хвалит их.
- В основе лидерства ведущего разработчика лежит скорее личное влияние, чем руководящая должность.
- Проактивен в определении и устранении препятствий в работе команды.
- Обычно намного меньше пишет код. В некоторых организациях ведущий разработчик связан с кодом лишь настолько, насколько это необходимо, чтобы поддерживать свое знание кодовой базы. В других организациях ведущий разработчик пишет код, чтобы показать пример или устранить какое-то препятствие в работе.
- Разбирается с техническими проблемами, управляет рисками и общается с руководством по всем этим вопросам.
- Досконально разбирается в том, какую пользу приносит программа бизнесу и как влияет на пользователя.
Вопросы, которые можно задать себе на этом уровне
- Вы помогаете «переводить» нужды бизнеса и продукта на язык технической архитектуры для команды?
- Вы общаетесь с руководством (вне вашей команды) по поводу препятствий в работе, держите их в курсе дел?
- Вы выступаете в роли ведущего дискуссий и принимаете решения по стандартам и процедурам в команде?
- Вы регулярно даете фидбэк коллегам по команде и вы ступаете в роли наставника для них?
- Вы понимаете, какие виды задач и проектов интересны для каждого из членов вашей команды?
- Вы помогаете определять, кто в команде чем будет заниматься (давая советы или напрямую делегируя задачи)?
На чем стоит сфокусироваться
- Учитесь выступать в роли ведущего на собраниях разработчиков.
- Учитесь продуктивно работать с руководством. Старайтесь разобраться в целях бизнесменов и научиться доносить до них инженерные концепции.
- Изучайте, как архитектурные решения влияют на прибыль бизнеса. Работайте над пониманием того, когда технически долг полезен, а когда становится проблемой.
- Учитесь побуждать других учиться, расти и принимать верные решения.
- Измеряйте свой вклад результатом ваших действий, а не количеством/качеством написанного вами кода.
- Учитесь управлять своими эмоциями. Когда другие видят в вас лидера, ваши слова и действия имеют очень большое значение.
Ресурсы
- Книга «Talking with Tech Leads».
- SpeakWriteListen
Главный инженер
Это лидеры индустрии. В некоторых компаниях для них создают дополнительные уровни, но в целом именно эти люди определяют движение индустрии. На эти позиции переходят немногие разработчики, и это нормально!
Характеристика
- Обычно 12-15 и больше лет опыта.
- Определяет техническое направление всей организации.
- Находит стратегические возможности для технологического роста.
- Разрабатывает и доносит до коллектива техническую стратегию на годы вперед.
- Имеет признание в индустрии, участвует в различных обсуждениях.
- Хорошо разбирается в бизнесе и том, как разные его части влияют на общую стратегию.
- Предвидит технические проблемы, которые могут возникнуть в крупных проектах, и разрабатывает решения для них.
Вопросы, которые можно задать себе на этом уровне
- Именно вы следите за трендами в технологиях, которые могут быть важны для вашего бизнеса?
- Вы устанавливаете технологическое направление для вашей компании или организации?
- Создаете ли вы технологические дорожные карты на несколько лет вперед?
- Принимаете ли вы участие в дискуссиях о состоянии дел в отрасли?
- Ведете ли вы дискуссии о компромиссных решениях в области архитектуры и технологий и их влиянии на бизнес в рамках всей организации?
- Можете ли вы предвидеть вероятные технические проблемы в крупных проектах, когда эти проекты еще находятся на стадии планирования?
О пути менеджмента мы поговорим во второй части статьи.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]