Путь в ИТ: мобильный разработчик

Меня зовут Юра, мне 25 лет, и я руковожу отделом мобильной разработки в Тинькофф Бизнесе.

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

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

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

Мобильный разработчик, mobile developer, создает программы и приложения для планшетов, смартфонов и других мобильных устройств. Сейчас две самые популярные мобильные платформы — iOS и Android. Специфика мобильной разработки в том, что под понятие «мобильная» подходят обе эти системы — внешне похожие, но очень разные внутри. И в разработке тебе надо быть немного и дизайнером, и аналитиком, и бэкендером — то есть уметь связать все вместе и разбираться во всем.

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

Тем не менее для каждой платформы есть свои языки программирования: для iOS чаще всего пишут код на Swift, а для Android — на Java или Kotlin. Чтобы быть хорошим мобильным разработчиком, нужно разбираться и в языках, и в платформе, для которой программируешь.

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

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

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

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

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

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

У меня был компьютер на Windows, а у друга — Макбук, и он программировал приложения под iOS. Я ему, конечно, завидовал: у меня примерно с восьмого класса был Айфон и мне тоже хотелось написать для него приложение.

Поэтому я решил пойти по более сложному пути — начал учить Java, чтобы разрабатывать приложения под Android. Кроме того, я собирался сдавать ЕГЭ по информатике, а там был довольно свободный выбор языков программирования для развернутого решения задач во второй части.

Изучая Java, прошел интерактивный курс, оформленный в стиле «Футурамы», а остальное учил по коротким видеокурсам и стихийным роликам на «Ютубе». За редким исключением они довольно сухие — и без опыта трудно понять, как применить новые навыки. Поэтому я сам придумывал задачи, которые хотел бы решить: написать «Морской бой» или получить прогноз погоды через консоль. Как по мне, рост с таким подходом обеспечен, это лучше, чем только чтение книг или просмотр видео.

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

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

Я неплохо сдал ЕГЭ, получил около 240 баллов за три предмета и в 2014 году окончил школу. Подавал документы в три вуза, первым по приоритетности для меня был Финансовый университет в Москве, потом МАИ и затем МИСИС. В последние два меня не взяли, а в Финансовый я поступил на бюджет во вторую волну — на прикладную информатику. Совсем топовые вузы я не рассматривал, так как понимал, что баллов недостаточно, а количество университетов, куда можно подать документы, ограничено.

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

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

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

В начале первого курса я попытался попасть на курс по Android-разработке от Тинькофф Финтеха, но не прошел отбор. Через пару месяцев мы с тем самым другом, у которого был Макбук, влетели в авантюру.

Какой-то мужик нашел нас через «Авито», где мы публиковали объявления о наших услугах как разработчиков, и обратился к нам с госзаказом: надо было разработать гид по городу для одного областного министерства туризма. Мы, два восемнадцатилетних оболтуса с нулевым опытом в коммерческом программировании, конечно, согласились: 300 000 ₽ на двоих и на все полтора месяца.

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

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

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

Отдохнув, наконец перешел на iOS-разработку, как и всегда хотел. В 2017 году, на третьем курсе, я снова подался в Финтех, но уже на iOS-разработчика, потому что просто так сдаваться не собирался. Было больше мотивации, знаний, уверенности в себе, а еще было немного спокойнее, потому что я представлял, как проходит отбор. В школу я прошел.

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

В Финтехе учиться было интересно, хотя и непросто. Трехмесячный курс строился вокруг базовых iOS-тем: управления памятью, многопоточности и других. Обучение пришлось на доковидное время, поэтому мы собирались на занятия в штаб-квартире Тинькофф у станции метро «Водный стадион». Нас было человек 30, и мы знали, что кто-то попадет на собеседование по окончании учебы, а кто-то — нет. За домашние задания и разные челленджи мы получали баллы, и тех, кто набирал много, в итоге звали на собеседование.

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

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

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

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

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

Я не ответил на 10—15% вопросов. Мой будущий тимлид, один из двух интервьюеров, даже говорил второму: «Чего ты с ним возишься», — имея в виду меня. Но в итоге я получил тестовое задание — написать приложение для Тинькофф Новостей. Я сделал его в черно-желтых неоновых тонах, с анимациями, иконками. Код был не очень, но меня похвалили за то, что удалось сделать какой-никакой продукт. Думаю, мне помог опыт работы и экспериментов над собственными приложениями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот как обычно бывает, мой путь — не исключение.

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

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

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

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

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

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

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

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

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

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

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

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

Еще, когда становишься руководителем, надо много разговаривать с людьми вместо того, чтобы писать код. И если с кодом все понятно — ты написал «сделай то», и оно делает, — то с людьми нет: ты говоришь «сделай то», а получается совсем не то или вообще ничего не получается. Или получается, и ты очень радуешься.

Так начинаешь понимать: к счастью или сожалению, люди не код. И просто ищешь к каждому свой подход.