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

Официально бизнес-линия называется Merchant Solutions, в ней несколько направлений: кэшбэк и рассрочки, обработка чеков и так далее. Под моим руководством сейчас порядка 70 человек, разбитых на семь команд. Сюда входят фронтенд- и бэкенд-разработчики, системные аналитики, QA-инженеры и автоматизаторы.

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

Я всегда хватался за любые возможности чему-то научиться и что-то узнать. Встретившись с программированием, понял: это то, что мне интересно и чем я хочу заниматься. Поэтому изучение Java у меня пошло быстро, увлеченно и взахлеб. Хорошие курсы по языку, трудолюбие, упорство и любовь к своему делу в итоге сформировали из меня неплохого разработчика. Главное — гнаться не за деньгами, а за интересным опытом и профессиональным ростом.

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

Мое рабочее место
Мое рабочее место

Что такое бэкенд-разработка

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

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

Самые расхожие языки бэкенд-программирования — Python, Java, Ruby, C++, C#, PHP, JavaScript, Kotlin, Swift, Golang. Я пишу преимущественно на Java — это распространенный и объектно-ориентированный язык, один из самых популярных.

Термины

API (Application Programming Interface) — инструменты для создания приложений, благодаря которым одна программа будет взаимодействовать с другой.

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

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

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

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

Microsoft Visual Basic — язык программирования, а также интегрированная среда разработки ПО от Microsoft.

А вот зарплатные вилки бэкенд-разработчиков в России:

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

Образование и первые шаги в программировании

Я из небольшого города Саяногорска в Хакасии. Он находится в 100 км от столицы республики — Абакана. В Саяногорске я родился и учился в школе, которая была слабой в плане образования. В шестом или седьмом классе, в начале 2000-х, мама отдала меня на курсы оператора ЭВМ, там мы программировали на алгоритмических визуальных языках. Строго говоря, это были не совсем языки: расставляешь фигурки, описываешь логику — и с ними начинает что-то происходить. Мне очень нравилось, я прошел курсы до конца.

Информатика в школе тоже была слабая. Уроки были построены так, что мы больше учились печатать, работать с «Вордом» и «Экселем». Но однажды учитель предложил заняться изучением Visual Basic. Я тогда написал небольшую программку: после первого же урока взял какой-то учебник, разобрался и сделал анимацию — плавающих в аквариуме рыбок, которые пускали пузырьки. Преподаватель так восхитился, что освободил меня от информатики на целый год. Потом меня с программированием долгое время ничего не связывало, максимум, что я делал на компьютере, — играл.

В 2006 году, в одиннадцатом классе, я ходил по репетиторам, чтобы хорошо сдать ЕГЭ и попасть в нормальный университет. Экзамены сдавал по трем предметам: математике, физике, русскому языку — и все сдал очень хорошо, каждый на 90 баллов или около того. По математике и физике у меня был лучший результат в школе. Поступить на бакалавриат было не особо сложно, со своими баллами я много куда проходил.

Сначала я подал документы в Абакан, но в итоге поступил в Томский политехнический университет. Комиссия вуза тогда приехала в Абакан на образовательную выставку. Университет неплохо себя разрекламировал и убедил меня поступать именно к ним. Позже я поехал в сам Томск, чтобы подать документы еще в ТУСУР и ТГУ, везде прошел на бюджет. Но в итоге выбрал автоматизацию технологических процессов и производств в томском Политехе.

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

В целом мной сильно двигало желание куда-нибудь переехать. Мне было 16 лет, и я нечасто выбирался из родного города. Разве что пару раз в Абакан — и никогда за пределы республики.

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

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

Программирования как такового у нас было мало, в основном все было на Pascal, Delphi, самостоятельно я пробовал изучать С++. По специальности мы больше занимались программированием контроллеров, что мне было интересно. Здесь необходимо оперировать сигналами и битами информации — это более низкоуровневое программирование, нежели классическая enterprise-разработка, где необходимо писать бизнес-логику, работать с базами данных.

Магистратура, куда я поступил в 2011 году в тот же университет, называлась «мехатроника и робототехника»: якобы мы должны были проектировать роботов. Там я начал заниматься наукой и участвовать в разных мероприятиях, за заслуги на этом поприще мне платили суммарную стипендию около 30 000 Р в месяц.

К тому же я получил грант. Его я выиграл, написав софт для кинематики роботов и космических аппаратов в рамках конкурса от фонда «Умник», он развивает молодежное инновационное предпринимательство.

Давали в среднем 400 000 Р на два года, сумма выплачивалась равными долями поквартально, но по факту выплатили больше — около 500 000 Р. При этом нужно было постоянно отчитываться о ходе исследования или работы, на которую тебе выделили деньги. Софт я написал в первые полгода, дальше были небольшие улучшения и применение ПО на практических задачах.

Еще я писал статьи, выступал на конференциях. Даже удалось поработать по договору: написал ПО для проектирования для компании «ИСС имени академика М. Ф. Решетнева» в Железногорске — наша кафедра у них была на подряде или субподряде.

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

График у меня был всегда очень плотный. В 06:30 я просыпался на тренировку, которая начиналась в 07:30, потом шел на пары по первой магистратуре, потом сразу на пары по второму высшему, в 10 или 11 вечера приходил домой и сразу ложился спать. Не знаю, как мне тогда удавалось не выгорать. Я занимался многим в основном потому, что не знал, что мне нравится. Если появлялась возможность что-то попробовать или изучить, просто за нее хватался.

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

Первый рабочий опыт и стажировки за рубежом

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

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

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

Промышленный объект где-то на границе Ростовской и Волгоградской областей. Там пролегает маршрут нефтепровода и стоит один из контрольных пунктов, где я налаживал нашу автоматику. Жили мы в 100 км от места, в поселке Зимовники
Промышленный объект где-то на границе Ростовской и Волгоградской областей. Там пролегает маршрут нефтепровода и стоит один из контрольных пунктов, где я налаживал нашу автоматику. Жили мы в 100 км от места, в поселке Зимовники
Рабочий день инженера в полях: с ноутбуком на коленках разбираешься, почему не работает код, который ты написал в офисе для испытательного стенда. Или заказчик пришел и требует доработок на месте — приходилось отлаживать прямо в полях
Рабочий день инженера в полях: с ноутбуком на коленках разбираешься, почему не работает код, который ты написал в офисе для испытательного стенда. Или заказчик пришел и требует доработок на месте — приходилось отлаживать прямо в полях

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

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

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

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

Еще в 2013 году, перед поступлением в аспирантуру, я поехал на стажировку в Португалию, в Новый университет Лиссабона, изучать разработку ERP- и CRM-систем. А через год, уволившись с работы по автоматизации, подал заявку на летнюю стажировку в Технический университет Дрездена уже в рамках аспирантуры.

Полезного в части академической работы в Португалии было мало, но время провели весело. В Германии к обучению относились серьезнее. Мы изучали основы низкоуровневого hardware-программирования на языке VHDL и кодили мобильных роботов на языке С. Было интересно, но практического смысла было мало: такие вещи, как правило, востребованы только в университетах. Зато я прочистил голову после напряженного рабочего года.

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

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

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

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

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

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

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

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

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

Обучение бэкенду

После того как у меня возник интерес к разработке, я смотрел разные видео по Java на «Ютубе», пробовал что-то писать, еще когда учился в университете, проходил онлайн-курс JavaRush и даже что-то на «Курсере». Но общего понимания о профессии я не имел и не знал, как туда войти.

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

Поэтому в качестве первого шага выбрал серьезное, подробное и фундаментальное обучение. В какой-то момент я ввел в Гугле «получить работу Java», наткнулся на курс getJavaJob и записался на него. Он и стал отправной точкой в мир бэкенд-разработки.

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

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

Само обучение заняло где-то девять месяцев, еще два ушло на подготовку финального проекта и поиск нового места. Онлайн-курс делился на два модуля. Система была такой: за первый модуль ты платишь фиксированную цену — 10 000 Р в месяц, а за второй отдаешь первую зарплату. То есть организаторы были заинтересованы в том, чтобы как можно быстрее и дороже трудоустроить ученика.

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

Второй модуль был более прикладным. Начался он с подробного изучения многопоточного программирования. Потом мы плавно двигались в сторону enterprise-разработки, учились работать с базами данных, популярными фреймворками Spring, Hibernate и сборщиками кода проекта, проектировать архитектуру приложения. А в самом конце деплоили приложение на бесплатный хостинг Heroku. Потом я все использовал в банковской работе.

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

Так выглядит финальный проект на курсе: необходимо разработать социальную сеть
Так выглядит финальный проект на курсе: необходимо разработать социальную сеть

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

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

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

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

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

Как я попал в Тинькофф

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

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

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

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

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

Еще Тинькофф подкупил корпоративными бонусами, например тренажерным залом и групповыми тренировками в офисе. Я обожаю спорт, а тут можно потренироваться прямо в здании и не тратить время на поездки. Фрукты я по утрам люблю: приходишь на работу — и они всегда стоят. Столовая с вкусной едой, где сотрудникам можно поесть бесплатно.

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

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

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

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

Устроившись в банк, я сразу попал на проект, где руководил собеседовавший меня сотрудник. Проект назывался и называется Тинькофф Таргет, он отвечает за кэшбэк и лояльность. Сейчас Таргет — одно из направлений развития бизнес-линии, за разработку которой я отвечаю. Конечно, были у меня и другие проекты, но Таргет тянется красной нитью через всю карьеру.

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

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

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

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

В декабре 2021 года мы привезли почти всех разработчиков в Москву
В декабре 2021 года мы привезли почти всех разработчиков в Москву

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

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

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

Типичный рабочий день, когда я был разработчиком

09:30. Пришел с утра, кофе, печеньки.

09:45. Составил план на день, прикинул задачки.

10:00. Начинаю день с код-ревью, смотрю мердж-реквесты (MR) коллег, где меня добавили в ревьюеры, оставляю комментарии.

10:30. Поправил собственный MR, выкачал актуальный код из мастер-ветки, а там уже появились конфликты: кто-то в мастер-ветке менял тот же код, что и я в своей. Решили конфликт, смерджили код. Собрал проект из исходного кода на своем компьютере, прогнал юнит-тесты — они показывают, что код работает без ошибок и в принципе работоспособен. Выгрузил свой код в удаленный Git-репозиторий.

11:00. Дейли-мит, всей командой открываем канбан-доску, проходим по доске справа налево, обсуждаем каждую задачу, на ком они, когда закончим, какие сложности.

11:15. Переключаюсь на новую задачу, она только пришла от бизнеса, пока разбираюсь с ней и прикидываю, как буду делать, возникают вопросы.

12:00. Пишу в наш канал в «Слаке», созываю встречу из трех человек — «Три амиго», это бизнес-аналитик, QA и разработчик.

12:30. Встречаемся, начинаем вытаскивать из бизнес-аналитика детали, чтобы понять, что конкретно нужно сделать. Тестировщик начинает набрасывать, как задачу правильно тестировать, что нужно проверить. После встречи ее описание увеличивается раз в десять. Еще на встрече поняли, что нужна доработка в нескольких сервисах, декомпозируем задачу на две.

13:20. Спускаюсь в нашу столовую на обед, как обычно, набираю полный поднос еды — а еще вчера собирался худеть.

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

17:00. Почти закончил реализацию задачи, даже начал отлаживать. Осталось написать тест-кейсы: на проекте используем подход test cases as code — все тестировщики и разрабы пишут тест-кейсы в коде на всех уровнях пирамиды тестирования. Скорее всего, завтра первую половину дня буду писать тест-кейсы, чтобы на задаче не возникло приемочных багов и мне не пришлось их фиксить.

17:05. Иду на кухню пить чай с коллегами, шутим, громко смеемся — немного спадают усталость и рабочее напряжение.

17:30. Пишу болванки для тест-кейсов, чтобы завтра осталось написать только мясо.

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

18:30. Увидел, что бизнес завел на вики еще один новый проект, скоро придут к нам, чтобы начать реализовывать. Читаю про проект, интересно, кто в команде будет его делать.

19:15. Спускаюсь в зал на тренировку, в зависимости от дня недели это BJJ, йога или фитнес, ходить стараюсь каждый день, но получается раза три в неделю.

21:00. После тренировки иду наверх, взял на фуд-корте еды.

23:00. Поел и посмотрел лекцию, пора домой.

Про работу руководителем и выгорание

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

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

Я не совсем понимал свою зону ответственности на старте, все было новым, непривычным. Потом осознал, что отвечаю вообще за все: за стабильность работы сервисов, процесс поставки фич на продакшен, ожидания бизнес-заказчика, мотивацию команды.

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

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

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

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

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

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

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

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

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

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

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

Тогда я открыл еще больше рабочих вакансий для разработчиков, тестировщиков и аналитиков. Мы начали набирать людей с рынка. Было довольно легко продавать наше направление на собеседованиях, среди всех открытых и предлагаемых проектов кандидаты почти всегда выбирали именно наш. Команда снова разрослась, но главное — она была к этому готова, ее архитектура свободно и легко трансформировалась под расширение.

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

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

Книги, которые мне порекомендовал прочитать мой бывший руководитель при переходе на роль тимлида
Книги, которые мне порекомендовал прочитать мой бывший руководитель при переходе на роль тимлида

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

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

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

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

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

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

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

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

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

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

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

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

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

Как расти и развиваться

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

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

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

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

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

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

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

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

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

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

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

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

Это Grafana — инструмент для мониторинга работы сервисов. У меня на работе четыре монитора, где я наблюдаю состояние наших основных сервисов в категории Mission Critical. Это значит, что у сервисов должна быть высокая доступность 24/7
Это Grafana — инструмент для мониторинга работы сервисов. У меня на работе четыре монитора, где я наблюдаю состояние наших основных сервисов в категории Mission Critical. Это значит, что у сервисов должна быть высокая доступность 24/7

Изучал DevOps- и SRE-практики, улучшал процесс поставки кода, проходил курсы проектирования архитектуры приложений под высокие нагрузки. Еще глубоко погружался в организацию процесса разработки. Site Reliability Engineering (SRE) — это набор принципов, которые позволяют создавать и эксплуатировать масштабируемые ИТ-продукты.

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

DevOps

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

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

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

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

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

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

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

Так вот, я обожаю заниматься рефакторингом, хотя многие считают его скучным и нудным. Ты просто берешь и приводишь все в порядок: представьте, что заходите в комнату, а там везде грязно, носки на люстре висят, кровать не заправлена, еда на полу разбросана. Задача — все расставить по местам. Любовь к рефакторингу у меня переросла в желание наводить порядок во всех рабочих процессах. В конечном счете благодаря этому меня и повысили до руководителя.

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

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

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

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

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

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