Яндекс для разработчиков

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

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

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

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, читают конспекты на Хабре — вне зависимости от того, согласны ли они с точкой зрения докладчика. А когда собеседник меня знает, у него и отношение чуть лучше. Я для него уже плюс-минус знакомый человек, хоть лично и не общались.

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

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

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

— Рома, у твоей группы интересное название. В чем заключается ваша работа?

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

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

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

— Даже в наше время беспилотный автомобиль — это редкость и что-то не совсем понятное.

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

— Вы уже выпускали полноценные автопилотники на дороги?

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

— Какие есть особенности разработки в работе над беспилотным автомобилем?

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

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

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

Вот, допустим, что значит «пропустить пешехода безопасно»? Человек понимает это интуитивно, не задумываясь о деталях, например, «в скольки метрах мне нужно остановиться». А машину нужно всему этому научить. И мы выдвигаем гипотезы, проверяем их, проводим эксперименты. Пытаемся решать задачи, которые никто в мире решать не умеет.

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

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

— Как считаешь, вы с этим справляетесь?

— Да, мы справляемся. Хотя мы занимаемся проектом около двух лет и это только начало, так что ещё многое предстоит сделать. Мы, конечно, работаем над тем, чтобы проект развивался как можно быстрее, но нужно объективно оценивать сложность задачи. Мы уверенно продвигаемся в этом направлении, с упором на безопасность, конечно же.

— Где планируется применять технологию беспилотного автомобиля?

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

— Где территориально находится ваша команда?

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

— Рома, расскажи о том, как ты попал в Яндекс и чем занимался здесь до беспилотников?

— Я в Яндексе уже восьмой год. В школе и университете я занимался олимпиадным программированием: ездил на международные олимпиады, брал там серебряные медали. У нас в Минске сформировался некий круг людей, которые занимались, и до сих пор занимаются, соревнованиями. И однажды, в 2011 году, когда Яндекс решил открыть офис в Минске, нас пригласили на собеседования. Так большинство из нас составило первый набор сотрудников минского Яндекса. Там были и не только ребята-олимпиадники, но нас всё-таки было большинство.

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

— Тебе нравится быть руководителем?

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

— Как ты считаешь, что в себе стоит развивать разработчику, чтобы стать успешным в своей области?

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

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

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

— Должно быть, работать над таким проектом как беспилотный автомобиль — это очень интересно.

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

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

— Что ещё ты хотел бы сказать нашим читателям?

— Хочется сказать: не нужно ставить себе рамки и думать: «я никогда не смогу заняться подобными вещами».

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

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

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

Мы впервые проводим встречу «Яндекс изнутри», которая не будет посвящена разработке.

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

Участников ждут доклады и воркшоп от топ-менеджеров Яндекса. Поторопитесь заполнить заявку и получить приглашение: events.yandex.ru/events/meetings/19-fev-2019/.

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