Июнь 10

Как я работаю: Алексей Трехлеб, Front-end Engineer в Uber

[В рубрике «Как я работаю» мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]

Алексей Трехлеб — Front-end разработчик в Uber, год назад переехал в Амстердам. За 13 лет работы в IT он создал более 50 веб-проектов, 2 стартапа и 10 опенсорс-проектов.

Два его проекта на GitHub — JavaScript Algorithms и Homemade Machine Learning Algorithms — получали статус «The most trending repository of the day» и суммарно набрали более 84 тыс. «звездочек», а ссылки на репозитории трижды попадали в топ-30 на главной странице HackerNews.

Также Алексей пишет технические статьи. У него есть несколько материалов на DOU: статьи о своих репозиториях для изучения Python и Machine Learning и заметка об экспериментах с машинным обучением на TensorFlow.

О себе

Компьютер у меня появился только на втором курсе университета, поэтому сейчас я даже немного завидую молодежи, которая творит чудеса по программированию уже в школе. Я родом из Харькова, учился в ХНУРЭ на факультете электронных аппаратов. Заинтересовался IT, когда одногруппник показал, как с помощью технологии Flash создать анимацию. Например, рисуешь круг в 1-м кадре и квадрат в 100-м, а программа сама рассчитывает промежуточные кадры и плавно превращает круг в квадрат. И это можно было встроить в браузер. Мне сразу же захотелось разобраться и поэкспериментировать с тем, как это работает.

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

В 2007 году я окончил вуз и переехал в Киев. Там устроился Full-stack веб-разработчиком в студии Tochka. Это была первая серьезная работа: мы делали полноценные сайты, используя PHP, MySQL, JavaScript.

Примерно через год подумал, что было бы интересно работать не в компании, а самостоятельно. И открыл свою веб-студию, с юношеским максимализмом назвал ее Siteprom — «Министерство сайтостроения Украины» :) Сначала работал сам, потом ко мне присоединился товарищ. Позже мы начали сотрудничать с двумя внешними дизайнерами, они помогали с макетами для сайтов и принтов. По меркам Украины у нас были интересные клиенты: молокозаводы, мебельные фабрики, автосалоны, дизайнеры одежды. Во многих проектах я одновременно был и Full-stack разработчиком, и дизайнером, и менеджером проектов. За три года такая нагрузка утомила, да и времени на профессиональное развитие почти не оставалось.

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

В 2015 году я по семейным обстоятельствам переехал во Львов. Еще когда только обсуждали с будущей женой возможность переезда, получил интересное предложение от львовского EPAM — это помогло принять решение. Сначала работал с PHP/Drupal-стеком на Senior-позиции, постепенно дорос до Lead.

Позже перешел на JavaScript. Хотелось немного сменить обстановку и двигаться из Back-end в сторону Full-stack. И на тот момент в компании было больше проектов с открытыми JavaScript-вакансиями, чем с позициями на РНР. Поэтому, как только в компании подвернулся подходящий проект по мобильной разработке (React Native), я воспользовался случаем. В карьерном плане это был своего рода «дауншифтинг»: от задач лида я вернулся к задачам программиста. В общей сложности проработал в EPAM 4,5 года, пока не решился на релокацию в Европу.

Мне давно хотелось поработать в большой продуктовой компании за границей, причем с продуктом, который мне нравится и которым сам с удовольствием пользуюсь. У меня были собеседования с Google — с релокацией в Цюрих и Варшаву, с Amazon — в Ахен, с Facebook — в Лондон и с Uber — в Амстердам. С Google, к сожалению, не сложилось: в один город не подошел по стеку, а во второй — не прошел этап собеседования, когда нужно было решать задачки во время видеозвонка. В Amazon летал на онсайт-интервью. В Facebook тоже получил приглашение на онсайт, и в это же время мне сделал офер Uber.

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

Во время карантина Алексей работает из дома

Роль и обязанности

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

Я занимаюсь Frontend-частью. Мы используем Fusion.js фреймворк (создан в Uber), у которого под капотом Node.js + React.

В моей команде 12 человек. Среди них — люди из 11 стран. Помимо нидерландцев, это уроженцы США, Мексики, Коста-Рики, Германии, Испании, Португалии, Турции, Израиля, России. Работать в таком международном коллективе очень интересно: у всех разный бэкграунд, менталитет, культура, шутки. Но, с другой стороны, вписаться в такую команду было немного сложнее, чем в «обычную» украинскую. Возможно, я где-то «перетаскивал» свои привычки, вроде излишней прямоты и микроменеджмента (который у нас в порядке вещей). Но со временем научился подстраиваться.

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

Во-вторых, открытые задачи. В аутсорсинге я привык, что мне ставят конкретное задание с техническими деталями — я сажусь и его выполняю. Здесь другой подход. Например, задача звучит так: «Реализовать возможность поиска водителей, связанных с аккаунтом пользователя» — и все. Конечно, я немного утрирую, обычно есть некоторые технические требования. Но все равно постановка задачи максимально открытая. И я сам должен определить, с какими командами внутри компании связаться, затем запланировать регулярные встречи, создать документацию и выбрать, какие сервисы использовать. Для этого нужно вникнуть не только в технические, но и в бизнес-требования к задаче. Я до сих пор перестраиваюсь на такой формат работы.

В-третьих, близкий контакт с Product Owner’ами. Они сидят бок о бок с нами, и благодаря этому мы понимаем задачи проекта. Нет дистанции, когда владельцы-идеологи продукта и бизнес-аналитики компании на одной волне, а техническая команда — на другой.

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

И, в-пятых, открытость компании перед сотрудниками. Каждую неделю руководство организовывает так называемые Global All Hands встречи. На них говорят о важных для компании новостях, планах, приоритетах, трудностях, финансовых отчетах и так далее. Также каждый сотрудник может задать интересующие вопросы непосредственно топ-менеджерам. Это дает чувство открытости и принадлежности к компании.

Типичный рабочий день

6:30. Просыпаюсь, два часа посвящаю самообразованию и своим IT-проектам — не рабочим, а именно для души. Для меня лучший способ изучать новые технологии — чередовать теорию с практикой. Как только прошел новый курс, сразу стараюсь что-то сделать руками, пробую, экспериментирую. Например, сейчас учу Machine Learning и создал проект, посвященный интерактивным экспериментам на TensorFlow.

8:30. Душ, завтрак, бытовые вопросы. До карантина примерно в 9:30 выезжал на велосипеде в офис. Но сейчас мы работаем из дома, так что полчаса на дорогу удается сэкономить.

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

11:00. Перехожу к работе над задачами текущего спринта. Например: «Отобразить список документов водителя, которые находятся на стадии проверки».

11:30. Проводим с командой ежедневный стендап. Обсуждаем, кто что сделал вчера и какие планы на сегодня. А Product Оwner’ы делятся с нами более глобальными новостями и изменениями, связанными с видением проекта, бизнес-задачами, приоритетами и дальнейшими планами.

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

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

В среднем работаю 35-40 часов в неделю. Контроля за часами работы нет — все основывается на доверии.

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

Инструменты и продуктивность

Рабочую продуктивность я связываю с закрытием Jira-тикетов. Мы с командой планируем спринт, выбираем и оцениваем задачи. И если, к примеру, за половину спринта успеваем сделать 50%, то считаю такую работу продуктивной.

Моя главная «рабочая лошадка» — MacBook. Код пишу в WebStorm. Для коммуникаций используем Slack, Gmail и Zoom, с документами работаем через Google Drive.

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

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

Также мы используем сервис Clockwise. Он подключается к Google-календарю и так комбинирует митинги, чтобы у тебя было больше неразрывного времени. К примеру, если одна встреча стоит на 13:00, потом час свободного времени, затем — еще одна встреча на 15:00, то программа постарается поставить их подряд. Конечно, для митингов с большим количеством участников не получится подобрать время, идеальное для всех. Но для встреч 1 на 1 — вполне.

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

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

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

При этом главный двигатель продуктивности — это страсть, интерес. Тогда не возникает вопроса, как встать в 6 утра (или выделить время вечером — кому как удобнее). Сама задача «подрывает» с постели и подстегивает начать работу или учебу. К тому же такой подход не дает выгореть: даже если на работе приходится заниматься скучной задачей, у меня есть своя отдушина.

Если подытожить, и в рабочих, и в пет-проектах 80% моей продуктивности основана на интересе к задачам. Остальные 20% можно «подогнать» todo-листами, удобным креслом, режимом и так далее. Но без интереса ничего не получится.

Пет-проекты и самообразование

Как я уже упоминал, в плане самообучения ключевую роль играют пет-проекты. У меня нет профильного фундаментального образования, и благодаря такой «песочнице» я наверстываю упущенное. В свободное время от работы, отпусков и переездов время создал 2 стартапа и 10 опенсорс-проектов.

Лучше всего, если удается найти собственную «задачу-боль» — тогда появляется мотивация как можно скорее ее решить. Например, я изучал Библию, и мне было интересно узнать значения некоторых слов в оригинале (на греческом или древнееврейском) и сравнить привычный синодальный текст с другими переводами — на том же английском. Также хотелось иметь возможность по клику на стих видеть параллельные места (стихи) на ту же тематику и сгруппировать их в свои собственные категории.

В интернете нетрудно найти разные переводы, но не было удобных инструментов для их сравнения. Тогда я создал сайт allbible.info: там можно кликнуть на стих и увидеть несколько доступных переводов, включая значения слов на греческом и иврите. Каждый день на сайт заходит примерно 5 тыс. человек — приятно осознавать, что проект оказался интересным не только мне, но и решает «задачи-боли» других людей.

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

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

Однако я все равно многому научился. Понял, что не следует «вылизывать» код до совершенства. Уже при готовности на 80% можно и нужно «щупать» рынок и проверять, нравится ли проект пользователям. Излишний перфекционизм иногда равен прокрастинации.

Идеи для опенсорс-проектов тоже черпаю из собственной «боли». Например, когда готовился к собеседованиям в Google, Amazon и Facebook, нужно было разобраться с алгоритмами. Компании FAANG делают акцент на этой теме, а у меня по таким вопросам был сплошной пробел. И я собрал в отдельном репозитории структуры всех популярных алгоритмов на JavaScript, чтобы было удобно их повторять перед интервью. Проект оказался полезным не только для меня: он уже набрал 70 тыс. «звезд» на GitHub.

Среди других моих проектов на GitHub:

Learn Python — «песочница» и шпаргалка для изучения Python. Коллекция Python-скриптов разбита на категории и содержит примеры кода с объяснениями.
Nano Neuron — 7 простых JavaScript-функций, которые дают понимания, как машины могут в принципе чему-то обучаться.
Homemade Machine Learning — примеры популярных алгоритмов машинного обучения на Python с объяснением математических моделей, которые за ними стоят.
Interactive Machine Learning Experiments — интерактивные эксперименты с машинным обучением. Каждый эксперимент имеет демостраничку, что позволяет «поиграться» с ним в браузере, а также Jupyter-ноутбук, который объясняет процесс тренировки модели.
usePosition Hook — JavaScript NPM библиотека React Hook для отслеживания географического положения браузера пользователя.
COVID-19 Dashboard — панель, которая показывает динамику распространения коронавируса по странам.

Знакомство с новыми темами обычно начинаю с помощью онлайн-курсов. Последний год в свободное от работы время изучаю Machine Learning и могу порекомендовать отличные вводные материалы на Coursera:

Machine Learning — базовые знания и математика;
Deep Learning (несколько курсов в одном пакете) — Python- и Jupyter-ноутбуки, а также Convolutional Neural Networks и Recurrent Neural Networks.

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

курс Introduction to Deep Learning;
специализация TensorFlow in Practice;
специализация TensorFlow: Data and Deployment;
подборка The Best Resources I Used to Teach Myself Machine Learning;
курс Deep Learning Nanodegree Program;
курс Machine Learning Engineer Nanodegree Program;
Trello-доска студента магистратуры по AI;
Deep Learning Papers Reading Roadmap на GitHub;
книга Dive into Deep Learning.

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

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

Ретроспектива и планы на будущее

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

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

Не беда, если не получается выделить на свою «песочницу» два часа в день. Даже один час или 30 минут — это лучше, чем ничего. Главное — заниматься регулярно и не бояться экспериментировать. По чуть-чуть, но каждый день. Это приблизит к оферу в компанию мечты или даже поможет нащупать идею собственного стартапа.

Что касается планов, пока продолжу развиваться в Uber. Хочу повысить Seniority-level (сейчас занимаю Middle-позицию). В долгосрочной перспективе подумываю о том, чтобы развиваться в Machine Learning. Но пока что еще не определился до конца, на сколько мне это интересно. Если в следующие месяцы или годы интерес не угаснет, буду искать возможности для перехода в эту сферу.