Меня зовут Константин, последние 6 лет я профессионально занимаюсь разработкой. К сожалению (а может быть и к счастью) у меня нет фундаментального образования по computer-science. Я решил сменить профессию после 30, поменяв предметную область с фондового рынка на программирование. И я прекрасно помню этот период времени, когда хватался любую полезную информацию в поисках куда и как двигаться дальше. 

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

Итак, приступим.

Прохожу мимо фулл-стек позиций

Ещё в недавнем прошлом разработка приложений была гораздо проще: бэкенд и фронтенд приложения разрабатывались как часть одного монолитного процесса, а задачам по инфраструктуре и её автоматизации уделялось минимум внимания. Одни и те же разработчики часто писали код как для клиентской, так и для серверной части приложения. Также часто практиковалась методика, при которой логика приложения описывалась непосредственно в базе данных с использованием pl-sql процедур, в то время как серверная часть выполняла роль всего лишь промежуточного слоя, отвечая за служебные функции.

Но уже лет 5 назад, когда я только начинал карьеру, мне стало понятно, что это путь в никуда. Появились CI/CD, масштабирование приложений, микросервисная архитектура — было понятно, что фулл-стеки просто не смогут все это тянуть в одиночку. Конечно, бизнес хочет уникального специалиста, который может всё — и сеть поднять, и сайт сверстать. Но чем дальше, тем им становится тяжелее.

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

В современном мире разработки инженер-программист уже не может физически успевать быть выдающимся специалистом одновременно во фронтенд и бэкенд разработке. Специализация стала жизненной необходимостью. Например, на моем текущем проекте в Альфа Мобайле у нас есть 4 разных специализации: бекенд, веб (JS), андроид и iOS-разработчики. Каждый пишет на своем языке, использует свои фреймворки и технологии, которые часто не пересекаются. Как это всё совмещать в одном человеке — непонятно. И если такие специалисты есть, то они должны быть элитой разработки? Ведь так?

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

А платят там не то чтобы хорошо — наблюдается тенденция к тому, что оплата труда таких специалистов чуть ниже. Крупные проекты и серьезные компании уже давно пришли к пониманию, что разделение обязанностей — залог качественного конечного продукта и ключ к более быстрой и эффективной разработке. А если ориентироваться на реальные цифры, то по данным исследований Хабра в первой половине 2023 года зарплаты разработчиков с более узкой специализацией были от 5%(фронтенд) до 29% (мобайл) больше, чем у фулл-стеков.

Делаю упор только на одной специализации

Единственный плюс фулл-стек позиции — это начало карьеры.

В это время можно понять, что ближе по душе и выбрать специализацию и ЯП с минимальными потерями по времени. Например, на своем первом проекте я писал клиентскую часть для web на JavaScript, а серверную на Java. У меня была возможность сравнить эти 2 языка и экосистемы, которые их окружают. Так как мой предыдущий опыт был связан с анализом данных и разработкой алгоритмов для построения торговых систем, бэк мне показался ближе. Java привлекла своей статической типизацией и объектно ориентированностью. Структура приложения на ней всегда имела строгий порядок. А во фронтэнде я так и не смог подружиться с CSS, который активно используется для верстки сайтов.

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

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

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

Стартапы, как стартовая площадка

По моему опыту, в стартапе обычно из-за молодости компании отсутствуют чётко выстроенные процессы.

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

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

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

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

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

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

• Так как ресурсы были очень ограничены, мы не писали тесты на 90% функционала, только на критические сервисы. Ручным тестирование часто не удавалось покрыть все кейсы и мы узнавали о существовании проблемы от саппорта на проде. Иногда это случалось уже после рабочего дня и приходилось в срочном порядке фиксить проблему.

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

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

А куда идти после стартапа? Выбор только — в большой бизнес. Но не все большие компании одинаково полезны. Я бы выделил на рынке труда две большие категории организации: 

• аутсорсинговые, разрабатывающие ПО на заказ;

• продуктовые, которые сами создают продукты и распространяют их.

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

Работая в такой компании в команде выдающихся разработчиков, вы сможете быстрее развивать свои навыки и компетенции до необходимого уровня. Например, в Альфа-Банке, мы с командой уделяем 20% рабочего времени на решение технических задач. В этом направлении улучшаем наш кластер, состоящий из более чем 300 микросервисов, активно обновляем зависимости, переходим на современные и эффективные технологии. Крупные задачи, которые мы успешно реализовали благодаря усилиям команды Альфа Мобайла за последний год:

• Перевели всю систему кеширования с Hazelcast на Redis.

• Обновили микросервисы на языке Java до версии 17.

• Обновили все стартеры для Spring Boot до версии 3.

• Перевели кластер с Mesos Marathon на Kubernetes.

• Постепенно переходим с языка Java на Kotlin и реактивный стек для старых микросервисов.

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

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

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

И раз уж заговорили про Kubernetes...

Изучаю DevOps и осваиваю автоматизацию

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

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

О том, что инфраструктурой могут рулить сами разработчики я узнал в Альфа Мобайле. Сначала чувствовал некоторую неуверенность в своих силах, однако со временем освоил этот функционал. Изучал принципы работы Kubernetes, пробовал Ansible. Управление этими инструментами, по большей части, декларативное с использованием yaml, который хорошо знаком из Spring. Когда начал понимать эти инструменты, то глубоко погрузился в инфраструктуру и поучаствовал в проектах выше, что было крайне интересно. Дошло до того, что сейчас я вообще смотрю в сторону сертификации по направлению архитектуры и DevOps:)

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

Получаю сертификаты

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

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

Но и без работы в аутсорсинговых компаниях сертификаты могут значительно улучшить знания в конкретной области. Например, сейчас я остановился на сертификатах от Oracle — OCA и OCP. Они самые популярные и известные среди Java-разработчиков, поэтому материалов для подготовки вагон: начиная с книг и заканчивая тренажерами, приближенными к реальному экзамену.

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

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

• Помогают уверенно отвечать на вопросы работодателей на интервью. 

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

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

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

Развиваю софт-скиллы

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

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

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

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

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

Разное

Учу английский.

Без него никуда.

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

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

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

Я занимаюсь на italki.com с носителями языка для прокачки разговорного английского и стараюсь читать книги для пополнения словарного запаса. Учить язык с носителем — лучший вариант, если планировать проходить интервью на английском, это даст наилучший эффект даже с низкой базы. Другие методы для этого будут в разы хуже по эффективности.

Применяю ИИ.

Я активно использую chatGPT для написания тестов и генерации данных для них, использую для переписывания функционала с одной концепции на другую (Java Reactive на kotlin coroutines), прошу сгенерировать код описания сложной логики в первом приближении. Также вопросы, ответы на которые раньше часто приходилось искать на stackoverflow.com, теперь решаются быстрее и в одном месте.

Веду здоровый образ жизни.

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

• Стараюсь меньше сидеть в соцсетях, на Ютубе, новости вообще не читаю (думскролинг — зло).

• Не курю и почти не пью.

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

• Сон по расписанию — 7-8 часов. Все АСАПы — завтра.

• Пишу план на день и стараюсь соблюдать режим дня — работа и отдых отдельно.

• Работа — не главное. Главное — близкие, общение с которыми помогает сохранить психическое равновесие после работы.

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

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

Как это помогает в карьере? Не считая самооценки, меньше прокрастинирую — больше успеваю — лучше резюме.

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