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

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

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

1. Придумать продуктовую фичу и оценить её эффект (фантазия + пользовательская аналитика).
2. Создать MVP (код + аналитика качества).
3. Превратить MVP в боевую систему, где можно запускать А/Б-тесты (инфраструктура + код + аналитика производительности / инфраструктуры).
4. Провести А/Б-эксперимент (аналитика + принятие решения).
5. Либо улучшать фичу дальше, либо выкатывать.

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

Я считаю, что да, только это фулстек в другой области.

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

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

Пока нет комментариев

Зачем выступать с докладами на митапах и конференциях?

Для участников мероприятий цели очевидны — узнать что-то новое от спикеров и пообщаться. А зачем, в свою очередь, спикерам делиться собственным опытом? За последние полтора года разработчица Лена Волжина сделала пять докладов на разные темы: от софт-скиллов до машинного обучения и архитектуры, и планирует продолжать развиваться в роли докладчика. О том, чем полезны публичные выступления и с чего начать будущему спикеру, — читайте в истории Лены.

(Лена работает в Яндекс.Погоде, занимается проведением экспериментов для улучшения моделей машинного обучения и их поддержкой на бэкенде.)

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

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

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

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

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

Не стоит забывать и про пользу для личного бренда. Хотя это самый эфемерный пункт, меня часто узнают в профильных сообществах, потому что где-то видели моё выступление. На крупных мероприятиях я чувствую себя увереннее, стало проще подходить к другим докладчикам. Ещё я веду индекс своих докладов на гитхабе: github.com/LenaVolzhina/about.me

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

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

Пока нет комментариев

Везде поголовно Node.js

Азат Разетдинов — один из первых фронтендеров Яндекса. Он устроился в компанию ещё в 2007-м, восемь лет делал Карты и другие геосервисы, три года посвятил персональным сервисам, включая Почту и Диск, а теперь руководит фронтендом Яндекс.Недвижимости. Азат объяснил нам, куда пропали верстальщики, когда разработчику интерфейсов стоит заглядывать в бэкенд и зачем на самом деле нужны были доклады про библиотеку MobX.

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

— Азат, ты очень давно в профессии. Что в ней поменялось с середины 2000-х?

До Яндекса я был не фронтендером, а fullstack-разработчиком. В Яндексе меня спросили, чьих ты будешь — бэкендер или фронтендер? Это подводка к тому, как выглядел мир тогда. В Яндексе были не только фронтендеры, но и отдельные верстальщики — потому что люди часто пользовались старыми браузерами. Масштабные знания о том, как верстать под старые браузеры, редко помещались в одну голову со знаниями программирования и JavaScript, со сложными штуками.

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

Второе — тогда JavaScript почти не использовался на сервере. Были попытки c разными движками, которые работали вне браузера, но не было внутренних инструментов для работы с серверным кодом. Сейчас везде поголовно Node.js, так называемый фронтбэк — JavaScript сильно шагнул в серверную часть. Отсюда высокие требования к разработчику интерфейсов. Если ты что-то ломаешь в браузере, ты ломаешь у одного клиента. Это не так страшно, человек просто нажмёт F5, и у него снова все заработает.

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

Третье мажорное изменение — рост количества инструментария и самих технологий. Когда я начинал, достаточно было знать HTML, CSS, JS, и всё — тебя могли взять на работу. Иногда требовался Flash и прочее. Теперь Flash не нужен, но появилось многих других, околоразработческих штук. Я говорю не только о фреймворках поверх JS — React, Redux и т. п. Моя жена и несколько ее друзей сейчас осваивают профессию веб-разработчика. Конечно, они начинают с HTML-CSS, но в любом следующем курсе на них обрушиваются системы сборки, всякие БЭМы, препроцессоры, постпроцессоры, Docker, GitHub. Они говорят: неужели все это надо знать? Да, надо. Фронтенд — это множество маленьких технологий.

— Ты сказал, что Node.js сейчас везде. Но считается, что ничего по-настоящему серьёзного на нём написать нельзя.

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

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

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

— Поговорим о твоём докладе на YaTalks. Актуальна ли идеология монорепозитория для небольших компаний?

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

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

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

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

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

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

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

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

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

— Раньше ты часто рассказывал на конференциях про библиотеку MobX, которая, тем не менее, так и не победила Redux...

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

Пока нет комментариев