В блоге Яндекс Go Dev разработчики Яндекс Go делятся опытом: рассказывают о создании и развитии продуктов, работе с багами и преодолении трудностей. Эти истории и кейсы ценны с точки зрения профессиональной экспертизы, при этом рабочими задачами экспертность наших специалистов не ограничена.
Публикуем интервью с Романом Елизаровым — одним из создателей Kotlin, а теперь руководителем команды DevExperience в бизнес-группе Екома и Райдтеха Яндекса. Он рассказал о том, как начал выступать и развивать dev-сообщество и как DevRel-активности, то есть выступления на конференциях, организация митапов, написание статей и другие способы развития dev-сообщества, помогают разработчикам.
Про создание dev-to-dev продуктов и значимые достижения в этой сфере
— Рома, привет! Расскажи немного о себе. Чем ты занимался до Яндекса?
— Привет! В Яндексе я недавно, до этого 7 лет работал над языком программирования Kotlin в JetBrains, причем в последние годы руководил всем проектом. В широком смысле это dev-to-dev деятельность, то есть создание инструментов для других разработчиков.
До этого почти всю карьеру работал в B2B-компании в финтехе — разрабатывал высоконагруженные системы для брокеров, бирж и других участников рынка. В основном занимался бэкендом, немного работал с фронтендом и внутренними библиотеками — попробовал самые разные направления.
Кроме профессиональной деятельности занимаюсь спортивным программированием. Со школьной скамьи участвовал, а теперь помогаю организовывать. Мы проводим чемпионат Северной Евразии, где отбираем студенческие команды, которые будут выступать на международном финале ICPC.
— Расскажи, какое событие или вызов стали самыми запоминающимися за время твоей работы в JetBrains? Возможно, оно повлияло именно на тебя и твою мотивацию, а может изменило и IT-сферу и dev-to-dev продукты.
— Самое яркое событие и самый большой проект, в котором я участвовал, — это корутины — асинхронное программирование для Kotlin. Ими я занимался не с самого начала, до этого работал над задачами сериализации. Помог опыт в бэкенде и создании подобных систем для бизнеса. К тому же уже тогда планировали сделать Kotlin многоплатформенным языком.
Но потом так получилось, что я стал заниматься корутинами и почти 2 года посвятил этому. В результате корутины вышли в продакшен даже раньше, чем сериализация. Её мы доделали позднее вместе с командой.
Мне кажется, до сих пор это мой самый большой вклад в сферу, так как достаточно быстро корутины стали стандартными для Android. Кроме того, мы были в числе первых: до нас уже создавали корутины, но большинство языков добавили аналогичные механизмы позднее, например, C++ и Java. Мы оказались в самом начале массового взрыва интеграций инструментов асинхронного программирования в языки программирования.
— Расскажи, чем ты занимаешься сейчас в Яндексе.
— Я работаю в бизнес-группе Екома и Райдтеха, руковожу отделом Development Experience. Наша задача — улучшить опыт разработчиков: выяснить, где есть проблемы, с какими трудностями они сталкиваются, и сделать процессы приятнее через работу над внутренними инструментами и фреймворками. Глобально — сделать программистов счастливыми, так они сразу становятся более продуктивными и допускают меньше ошибок. С точки зрения бизнеса здесь 2 больших задачи:
- Уменьшить time-to-market, чтобы разработчики не тратили время впустую на инфраструктуру и могли быстро решать задачи.
- Увеличить надёжность сервисов. Для Такси и других групп критически важно, чтобы сервис не падал. Поэтому нужно снизить возможность ошибки в целом.
Про опыт в DevRel-активностях
— Когда ты начал деврелить? Помнишь ли ты, как всё началось у тебя?
— Конечно! Действительно, на тот момент не было ни DevRel-команд, ни отдельных специалистов. Моя история сильно переплетена с увлечением спортивным программированием: мы проводили соревнования, что-то рассказывали, привлекали спонсоров. На чемпионатах чувствовалась синергия между моим рассказом и компанией: я говорил о том, чем мы занимаемся, какие полезные вещи делаем, и тем самым мотивировал увлечённых специалистов присоединяться. В найме обычно два аспекта — массовый набор и подбор высококвалифицированных специалистов, которых нужно увлекать интересными технологиями. Мои выступления на соревнованиях помогали со вторым.
Потом деятельность плавно трансформировалась в выступления на конференциях. Всё это ещё не называлось DevRel-активностями — ходишь, знакомишься, делишься опытом. Интересно, что я 15 лет работал в компании, в которой был сооснователем, и когда выступал, ощущалась связь между развитием личного бренда и пользой для бизнеса.
Далее это трансформировалось в образовательную деятельность. Когда я начал преподавать, мы работали над параллельными и распределёнными системами. Я понял, что до всей теории нужно доходить самостоятельно и каждому новому сотруднику необходимо дать много вводных знаний. Поэтому стал вести специальный курс в вузе, чтобы к нам приходили специалисты, которые уже знают, как с этим работать.
Я не относился к этому как к DevRel-активности, хотя так и есть — ты неизбежно рассказываешь, где и чем занимаешься, а самые увлечённые студенты потом приходят на стажировки. Им интересна тема, они приходят уже заинтересованными и обладают нужной базой знаний.
— Как я понимаю, история твоего деврельства развивалась вместе с карьерой. Расскажи, какие ты помнишь самые яркие свои выступления. Может, это были крупные конференции или, наоборот, уникальные мероприятия?
— На самом деле выступлений было очень много, поэтому проще разбить на вехи. Сначала выступал внутри компании. Получалось хорошо, стал делиться опытом на митапах, потом на конференциях и мероприятиях побольше. Я выступал в Санкт-Петербурге, ездил в Москву и на международные мероприятия.
Самое тяжёлое — выходить из привычного порядка. Например, я привык к техническим докладам, но когда стал работать в финтехе, позвали на отраслевую конференцию. Здесь другая аудитория: больше людей со стороны бизнеса, а не технических специалистов, поэтому важно найти к ним подход. В какой-то момент меня пригласили в Москву уже в качестве соавтора Keynote-выступления — нужно было готовиться и к этому формату.
— Исходя из твоего практического опыта хочу узнать: ко всем выступлениям ты готовился сам без чьей-либо помощи?
— На самом деле было по-разному. Выступал на технических конференциях и преподавал самостоятельно. Обычно когда что-то начинаешь делать, смотришь, как это делают другие, и выбираешь для себя интересные фишки.
Потом в какой-то момент ты всё равно проходишь через тренинги — несколько раз меня приглашали на конференции и специальные мастер-классы для спикеров перед выступлениями. Вроде ты уже опытный спикер, но всё равно такие мероприятия помогают систематизировать знания.
Когда я выступал первый раз в формате Keynote, мы просто собрались с ребятами и написали сценарий. Но в следующий раз перед KotlinConf у меня был тренер, который помогал с презентацией, произношением на английском, интонацией. Потребовалось много занятий и времени, но результат стал сильно лучше. Это было особенно полезно, так как выступление собрало множество зрителей и транслировалось в интернете.
— Расскажи о процессе поиска темы выступления. Для DevRel-команды это самый трудный этап — боязнь белого листа тормозит процесс, но уже после примерной формулировки можно активно прорабатывать материал. Как ты выбираешь темы для своих выступлений?
— Надо рассказывать о том, что происходит в твоей жизни. Конечно, есть люди, которые профессионально всё время выступают на конференциях с новыми темами, но обычно у них есть набор заготовок. Разработчикам актуальнее выбирать темы, связанные с рабочим опытом: в любой деятельности есть интересные моменты, о которых можно рассказывать или шутить.
Основная сложность — найти подходящую конференцию и аудиторию. Например, мобильным разработчикам стоит выступать на мероприятиях с аудиторией мобильных разработчиков. В работе точно можно найти подходящую тему: как тестировали новый подход, искали решение, попробовали несколько версий, но ни одна не подошла. В любом рассказе главное — понимать свою аудиторию: чего она хочет, что было бы интересно узнать. Обычно людям интересно послушать про реальные случаи из жизни и задать спикеру собственные вопросы, на которые ты не получишь ответы, прочитав статью в интернете.
О пользе DevRel-деятельности для разработчиков
— Как ты считаешь, какую пользу DevRel-деятельность может принести разработчику?
— Я всегда говорю, что это полезно любым специалистам на senior-позициях, так как масштаб задач и зоны ответственности растут и объяснения и обмен знаниями с другими становятся постоянной частью работы. Опыт, который ты можешь получить во время подготовки и выступления, поможет непосредственно при выполнении задач. Поэтому DevRel-деятельность может и сформировать личный бренд, и развить полезные для работы навыки.
Кроме того, ты знакомишься с другими людьми. С одной стороны, от конкретных спецов можешь узнать информацию, которой больше нигде нет. С другой стороны, контакты полезны для будущего найма — на конференциях собираются близкие по духу люди, с которыми будет комфортно работать. В целом это работа вдолгую — ты получаешь пользу сейчас, но преимущества играют и в long run.
— Рома, а есть в твоём управленческом опыте кейсы, когда сотрудник начал развивать личный бренд и получил от этого выгоду?
— Если посмотреть топовых докладчиков на крупных конференциях, то их карьерный рост напрямую связан с выступлениями. Это не значит, что все руководители обязательно публично выступают, но если человек добился в этом успеха, то скорее всего он занимает senior-позицию и любим коллегами. Скорее всего DevRel-активности помогли ему развить коммуникационные навыки, благодаря которым получилось выстроить хорошие отношения с командой.
— Мы поговорили о выступлениях и образовательной деятельности. Расскажи, видишь ли ты пользу в других активностях, например, работе над статьями, создании опенсорсных продуктов?
— Надо понимать, что блоги и выступления часто сходятся вместе: спикеры на конференциях пишут статьи, а авторы публикаций рассказывают о своем опыте на мероприятиях.
Блоги — важный способ коммуникаций, они в том числе помогают тренировать навык излагать мысли текстом коротко, чётко и убедительно. На сегодня умение написать хороший текст на 5-10 минут чтения на какую-то цельную тему — отдельный навык. Это полезно и в работе, когда нужно быстро убедить в чём-то занятых коллег.
Блиц-опрос
— Написать статью или выступить с докладом?
— Написать статью.
— Написать статью или код?
— Определённо код.
— Решить задачку по программированию или сходить в отпуск?
— Вопрос с подвохом. Наверное, всё-таки сходить в отпуск.
— Хорошо подготовленное выступление или экспромт?
— Экспромт.
— Статья на Хабр или в собственный блог?
— В собственный блог.
— Kotlin или C++?
— Конечно, Kotlin!