КПД разработчика. Как успевать жить, работать и эволюционировать. Часть 1
Каждый из нас по-своему находит тот самый work-life balance. Или не находит. В серии статей мы спрашиваем разработчиков со впечатляющим бэкграундом, как они успевали и успевают жить, работать и эволюционировать.
Первое интервью — с Денисом Аникиным из Райффайзен привело к неожиданным выводам. Читайте историю о том, что успешный разработчик не всегда проходит правильный путь: ВУЗ-стажировка-джун-мидл-сеньор/тимлид. Посмотрите, какие принципы помогают соблюдать баланс техдолга и разработки. И узнайте, каким вопросом не стоит себя истощать, если хотите быть счастливым человеком.
![Денис Аникин на онлайн-митапе Райффайзен Денис Аникин на онлайн-митапе Райффайзен](https://habrastorage.org/getpro/habr/upload_files/b42/687/47a/b4268747aac653075989e3aeba4b9183.png)
Привет, Денис! Мы побывали на твоем сайте и знаем, что ты не ограничиваешься ролью бекенд или фронтенд разработчика в команде. Перечисли все роли, в которых ты работаешь, да и живешь в постоянном режиме
Я стараюсь заниматься fullstack разработкой, потому что мне очень нравится делать и бек и фронт. А ещё я думаю, что очень печально, что вокруг все обесценивают fullstack'ов и тиражируют миф об их некомпетентности и/или невозможности работы в такой роли. Быть fullstack возможно, если тебе интересно. Никто не требует от тебя быть во всех ролях principal 10/10. А ещё я часто смотрю на новых разработчиков, и часто люди спокойно умудряются осваивать и по 2-3 стека, если увлечены.
Да и сам fullstack подход даёт много бонусов. Например, ты «собственной кожей» чувствуешь как твой продукт общается с клиентом и какую нагрузку на какие endpoint'ы лучше не класть. И для этого не нужно быть двумя людьми. Поэтому, роль fullstack — это круто. Но если вам не нравится или вы чувствуете, что не тянете — это тоже ок. Fullstack — не повод для гордости и не повод для того, чтобы себя чувствовать некомпетентным разработчиком. Это ещё один вариант самореализации в IT.
Кроме fullstack я ещё занимаюсь DevOps направлением: написал несколько версий конвейера для команды, пишу хелмчарты, занимаюсь развитием метрик и мониторинга (day1/day2 активности), делаю slack автоматизации, сборочные конвейеры для python- сообщества (мы собираем свои базовые докер образы).
Основная моя роль — тимлид/ техлид в команде. У нас крутой оунер и классная команда. Выполняю обычный набор задач лида: общаюсь с людьми, двигаю тикеты, балансирую задачи, включаюсь в процессы когда нужно, сам разрабатываю, помогаю технике двигаться в нужном направлении, словом.
![Удаленка как началась, так и осталась. И общение переместилось в онлайн Удаленка как началась, так и осталась. И общение переместилось в онлайн](https://habrastorage.org/getpro/habr/upload_files/c8c/010/4ff/c8c0104ff11a49166b0d6b141daa2df3.jpeg)
В банке принята горизонтальная структура, поэтому большинство решений мы принимаем совместно: и задачи декомпозируем, и оцениваем, и стек выбираем, и архитектуру проектируем, продумываем тоже командно. Это отлично, так как, во-первых, у нас нет «самого умного единственно правильного дяди/тети». Во-вторых, сильно снижается вероятность напридумывать бреда: вокруг все внимательно следят и всегда скорректируют. В-третьих, все чувствуют ответственность за продукт. Благодаря этому у нас ультрасвежий стек, неплохие технологии, много интересных технологических решений и хороший аптайм. А ещё я стараюсь верить, что в команде классный климат и людям интересно и комфортно, но это не мне оценивать, т.к. я могу быть субъективен. Но моих коллег всегда можно спросить, если захотите :)
Ещё я занимаю роль community lead в Python Community. В банке существуют так называемые community. В некоторых местах их называют гильдиями или профессиями. В нашем случае это такая горизонтальная структура, которая не противоречит заветам Scrum (самостоятельные кросс-функциональные команды) и помогает объединяться вокруг технологий и не только.
У сообществ есть дополнительные роли: community lead (CL) и senior community lead (SCL). Вот я — CL, это роль part-time, в дополнение к основной. Основной принцип — горизонтальное лидерство. Конечно нотки вертикальности тоже проскакивают, без этого пока не умеем жить, но целевая модель все-таки горизонтальная. Мы помогаем, а не командуем.
Эта роль включает в себя разные активности: я с коллегами сейчас собеседую людей в банк (у нас техническими собеседованиями занимается community), я провожу «вантуваны» с людьми из сообщества, иногда пишу индивидуальные планы развития.
Не могу сказать, что я в этом преуспеваю: однажды я начертил карту развития fullstack разработчика, чтобы помогать новичкам, но, кажется, всё что я сделал — распугал ей всех людей.
Также я занимаюсь разными техническими активностями (поддерживаю базовые образы для сообщества, например), иногда пишу что-то в Slack, пытаюсь помогать разрешать конфликты, изредка провожу ассессменты.
Ну и самая ресурсоёмкая деятельность, которая очень меня увлекает — это митапы. Внутри банка мы уже провели +/- 12 закрытых и недавно выложили на youtube один открытый. Митапы — всегда вызов. Нужно находить интересные и не заезженные темы, рассказывать свой опыт. Это бывает очень, очень непросто. Но мы с коллегами стараемся каждый месяц находить темы для встреч и нам ещё очень помогает, что банк выделяет сообществам ресурсы devrel специалиста. Наш devrel, Лена, очень здорово нам помогает развивать сообщество.
На митапах весело: приходит много людей, задают острые вопросы, всегда рождается много новых тем. Единственный существенный минус: испытываешь стыд, когда смотришь себя в записи — находится всегда миллион вещей, которые неправильно сказаны, могли быть выразительнее, менее пискляво сказаны, а уж «эканья» и «аканья» совсем добивают.
Опиши свой путь в разработке? Ты пришел из верстки и фронтенда к бэкенду и далее, или как-то по-другому?
Наверное, можно сказать, что я шёл от фронтенда.
Моя первая работа была — эникейщик/верстальщик в 2005 году. Меня взяли с улицы жутким оболтусом в команду eTeam (некоторые люди оттуда сейчас очень известны в digital среде). Я делал всякую работу типа подключения клавиатур, установки windows и пр. Помню, однажды записал 700 промо флешек, а оказалось, что презентация там ну совсем немного неправильная. И пришлось ещё раз 700 флешек записывать :)
Кроме этой деятельности мне доверяли верстку сайтов, набивание контента. Работник из меня был не очень, но мой руководитель, Роман, мучался со мной, но всё-таки тащил вперёд. Хочу ему сказать за это запоздалое спасибо. Это он дал мне путь в индустрию.
В 2005 году через боль, слезы, табличную вёрстку, флоаты и ie 5.5 мне удалось сверстать свой первый сайт, и вот с тех пор я встал на путь типичного работника веб студии — делал сайты под ключ. Сначала «накликивал» в cms, потом что-то стал разрабатывать на очень популярном тогда в вебе PHP, совмещал и работу над контентом и верстку, и «программирование» бекенда.
Дальше мой путь пролегал через несколько веб-студий, в которых были только дизайнеры и разработчики. Поэтому приходилось делать вообще всё, кроме дизайна: настраивали сервера, занимались настройкой dns, программировали бекенды, заливали контент, верстали всё, дорисовывали что-то, запускали в продакшн, иногда и контент приходилось писать. В тех веб-студиях бюджетов не было ни на что, маржинальность низкая, отсюда и такой профиль.
Параллельно я учился в вузе и безостановочно фрилансил, довольно часто срывая дедлайны, увы. Я медленно учусь: мне пришлось потратить лет 10, чтобы понять, что во фриланс я больше ни ногой.
![](https://habrastorage.org/getpro/habr/upload_files/3b8/af8/99f/3b8af899f992939b9b52815684d7bf13.png)
В итоге я более-менее сносно освоил PHP, фронтовый стек (на тот момент на базе jquery), linux и многие другие базовые навыки для разработчиков. Сверстал десятки, если не сотни сайтов.
В Python же я «шагнул» где-то в 2010/2011 годах. Сменить стек на тот момент казалось очень сложным делом. Во-первых, php разработчиков нередко не уважали за то, что описано в статье «Фрактал плохого дизайна»; во-вторых, смена стека многими трактовалась как старт с нуля, да и «вообще, как так можно-то?»
Сейчас с этим стало попроще, но тогда мне пришлось пройти множество унижений на собеседованиях и массу отказов.Но в итоге все получилось. Кстати, многие коллеги до сих пор негативно относятся к php, а я напротив, хорошо. В конце концов, я на нём вырос :)
Дальше у меня было много мест работы: я работал над биллингом виртуального оператора сотовой связи, лет 6 проработал на медиа рынке (новости), часто совмещал несколько мест работы, занимался всегда веб-разработкой на python, иногда что-то писал на php.
В 2020 году с JavaScript я наконец-то перешёл на TypeScript. Мне очень помогло то, что в Python я уже проникся идеей gradual typing, поэтому Typescript я принял относительно легко и с пониманием.
Наверное, из-за того, что мой путь пролегал окольными маршрутами, я до сих пор верю в fullstack подход, для меня он всегда был естественным.
Для общего представления: на каких языках ты пишешь? Какой стек используешь настолько часто, что можешь без подготовки толкнуть по нему часовую лекцию?
Я пишу на Python и TypeScript, верстаю фронтенды на стандартной связке html/css/пре(пост)процессор уже лет 15, сейчас перешел на react, mobx, styled components. Изредка пишу на Go и совсем уже редко на PHP.
Моё субъективное мнение такое: Python, TypeScript и go сейчас могут покрыть процентов 99 запросов рынка.
Лекцию, наверное, мог бы толкнуть о python, но я себя никогда не представлял в роли лектора, мне не очень комфортно в такой роли. Я скорее мог бы рассказать свою субъективную позицию, одну из. Кстати говоря, в этом году как раз буду на одной конференции выступать с таким докладом про Python.
Если бы ты мог выбрать самый любимый язык программирования, что бы это было? И почему именно Python?
Ха :) не оставили пространства для манёвра!
Мои соображения здесь таковы: python «поедает» рынок, захватывает все большую долю, а ещё он элегантен, эстетичен и лаконичен. В python внедрено много кусков ФП, gradual typing, сейчас интегрируют jit. Python хорош своей невероятной гибкостью, интроспекцией, довольно крутой асинхронностью, потрясающими решениями, такими как pytest, fastapi, огромным сообществом.
Конечно же у Python есть и минусы: он медленный в cpu bound задачах; он «обманчиво» прост (Григорий Петров об этом будет делать доклад в этом году). У Python не самая лучшая репутация, которую не пнул только ленивый: язык для новичков, второй лучший, сойдет для прототипов на джанге и пр. У него треды подходят не для cpu bound, а для i/o bound из-за GIL; у него динамическая строгая утиная типизация и на этот счёт существуют мемы и тонна критики.
Так же у Python очень эклектичный дизайн самого языка и многим это очень не нравится. В интернете почему-то считается правильным фокусироваться на одной парадигме, а не поддерживать много разных. Аргументация такой позиции довольно размыта и строится скорее на метафорах, чем на чём-то рациональном.
Я неплохо знаю о сильных и слабых сторонах Python. Мне нравится его инфраструктура, нравится его идеология, нравится его сообщество. Приятно быть с умными людьми в одной среде.
![](https://habrastorage.org/getpro/habr/upload_files/40f/8c5/9af/40f8c59afb0ef3f91972804d050ba117.png)
Сколько, обычно, длится твой рабочий день?
В пандемийно-удаленном формате я стал больше работать. Обычно просыпаюсь в 10:00-10:30, в 11 у нас дейли, а потом — в зависимости от календаря. Если он чистый и нет долгов или чего-то “горящего”, работаю до 21-23, если есть — до упора, пока не надоест.
Обычно календарь выглядит как встреча-встреча-встреча-встреча-собеседование-встреча, поэтому приходится часов до 18-20 заканчивать встречи и потом еще какое-то время «работать». Я всё ещё ощущаю на себе стигму шутки «не хочешь работать — собери совещание».
Иногда бывает, что заканчиваю за полночь, ибо увлекаюсь.
Вообще, я конечно же не рекомендую никому перерабатывать. И читатели статьи справедливо скажут: «Ну вот ты же перерабатываешь, а другим не советуешь». Это правда так, но я не хочу быть рекламой переработок. Индустрия вышла из времен, когда это почиталось и сейчас переработки в основном не в почете. Для меня же сидеть лишнее время — скорее стиль жизни, мой личный выбор. В конце концов, правильно отделять то, что произносится от личности произносящего. Если курильщик скажет, что курить вредно, то это не сделает его утверждение ложным.
![](https://habrastorage.org/getpro/habr/upload_files/bd4/369/6f6/bd43696f6a5cea0985c334c3cb5df3b9.jpg)
Ты написал на сайте, что стараешься соблюдать приоритеты и баланс техдолга и разработки. Есть какие-то принципы, которыми ты при этом руководствуешься?
Оунер нашей команды Илья, да и сама команда, меня этому учат и я, кажется, нащупываю какой-то идеальный путь. Принципы озвучены до нас:
бизнес инкремент от команды должен быть обязательно и стабильно;
планировать спринт надо без перегрузки;
техдолг нужно не забывать делать постоянно, иначе вас ждет материализация шутки про дженгу;
под техдолг нужно закладывать какой-то процент ваших усилий (в зависимости от договоренностей, обычно процентов 10-20);
идеальная команда — это не та, которая горы сворачивает на сверхусилиях, а та которая стабильно приносит результат.
Расскажи про практику “everything as code”. Как и где её применять, чтобы поменять “больно” на “хорошо”?
Это концепция, которая сейчас набирает популярность в мире и в названии уже заспойлерено самое интересное: в IT индустрии всё хотят перевести в код.
С помощью этого мы получаем воспроизводимость, прозрачность и унификацию.
С инфраструктурой у нас есть +/- консенсус — kubernetes & helm. Вы можете все ваши сервера, энжинксы, базы данных, mq, прокси, промежуточные сервисы, мониторинг, алертинг, ваши основные микро- и прочие сервисы — всё это описать ямлами и жить счастливо.
Но, кажется, что сейчас уже все зашло так далеко, что уже все предприятия целиком уезжают в git репозитории. Почти всё сейчас уже описывается кодом, а то, что не описывается, туда стремится.
Идеологически я поддерживаю мир в этом.
Поэтому, чтобы было хорошо, опиши всё кодом и положи в VCS (если можешь).
Твой ТОП-3 инструментов, которые существенно повышают качество и/или скорость разработки
Slack
Gitlab (но от процесса code review в нём я страдаю)
VScode
![](https://habrastorage.org/getpro/habr/upload_files/869/426/912/869426912adb0b1a01429b0380d0d4dc.jpeg)
А какие инструменты не оправдали твоих ожиданий?
Напомню, что это моё личное мнение, в котором я не претендую на объективность. Atlassian стек и Elastic стек.
Тулы из этих двух стеков меня пугают и напрягают.
Начнём с Atlassian. Интерфейс Jira — отдельная песня. Не проходит ни одной встречи, чтобы мы не кричали «да блин, джира». Скорость работы, удобство — всё вызывает массу нареканий.
Bamboo — это мой личный кошмар. Это овеществленное программирование мышкой, на каждый чих надо пайплайны копировать, а когда тебе их нужно пару десятков, то можно сесть и тихо плакать. Или соорудить, как мы, 4 уровня мета-бамбу-спеков и сходить с ума. Я сейчас ловлю въетнамские флешбеки от одного слова: перед глазами летят вертолеты и бомбят джава спеками.
Confluence — неправильная википедия. Средство для написания статей, в котором нельзя читать статьи. У него банально нельзя ширину по дефолту зафиксировать, тексты растягиваются на широкоэкранных мониторах в строчку. Причём вспомним Notion — он решает визуальные проблемы конфлюенса, но не решает экзестенциальные: всё все равно превращается в зомби-свалку, до которой никому нет дела.
Elastic стек хорош своей криптованностью.
В Kibana разобраться — это не два байта переслать. Запросы писать больно, скорость так себе, колонки нельзя конфигурировать (мне пришлось ради этого написать браузерный экстеншн). APM вообще меня напугал недавно: на темной теме все слилось в одно пятно, шрифты банально не адаптированы. Да и сами трейсы рассматривать сложно и неприятно. Конфигурация filebeat — образец неконститентности и не очень подробной документации.
Ты нашел свой work-life balance? И как он выглядит?
В моем случае work-work balance. Я скучный и не очень интересный человек в личной жизни. Мой баланс — много работать, потому что мне нравится жить в IT, меня это увлекает. Я получаю большое удовольствие от жизни таким образом.
Иногда я путешествую, вижусь с друзьями и развлекаюсь. Но, как знают мои коллеги, я честно говорю: все самое интересное давно не в сказочных рассветах за горами, а в интернете. Вы можете целую жизнь прожить здесь, если захотите.
В общем, баланс — там где вам хорошо, комфортно, и там где есть что-то, что вас интересует, мотивирует.
Свой баланс и счастье я нашел, всем желаю найти своё.
![](https://habrastorage.org/getpro/habr/upload_files/de5/a55/6bd/de5a556bd029d521c0304b2ed46db3bd.jpg)
Дай свой совет: Как разработчику успевать жить, работать и эволюционировать?
Мой совет — не сильно истощайте себя этим вопросом.
Текущее положение мира — культ сверхуспеха. Куда бы ты не шел, вокруг идеальное абсолютно всё. Всегда рядом сын и дочь маминой подруги, идеальные профессионалы, семейные люди, идеальные лица, фигуры, жизнь и даже небо.
В этой ужасной, шизоидной атмосфере очень легко включиться в спринт без всякой надежды на успех и никогда не стать тем отфотошопленным человеком с обложек Instagram, а потом и вообще поделиться на ноль. На каждого сеньора найдется 16-летний принципал, на лида — 15-летний СТО, на дорогой BMW — ещё более дорогой (и ещё более без поворотников) BMW.
Увы, невозможно преуспеть во всём, просто нет столько временных ресурсов у обычного человека.
Мне кажется, важно помнить, что мы просто люди и важно делать то, что делает нас счастливыми.
Придётся самому понять, что нравится, чем хочется заниматься и чему отдать приоритет. Иногда личная жизнь — и есть эволюция, а иногда эволюция решить 1340 задачу на литкоде.
В общем, выглядит так, словно я сбежал от ответа. Я правда считаю, что без рефлексирования этого топика невозможно дать ответ. Если и дать его, он будет вредный. А я хотел бы читателям как минимум не навредить, как максимум — принести пользу.
Спасибо Денису за честные и прямые ответы на вопросы. Мы продолжим писать истории разработчиков о поиске своего пути и баланса в жизни, и надеемся, что они кого-то из вас вдохновят или приведут к полезным выводам.
А с Денисом Аникиным можно пообщаться лично. Он будет выступать на PyCon Russia 5-6 сентября с темой "FastAPI как основной framework для python бэкендов".
Присоединяйтесь также к чату PyCon в Телеграм.