Як я працюю: Олексій Трехліб, Front-end Engineer в ?ber

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

Олексій Трехліб — 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 теж отримав запрошення на онсайт, і в цей же час мені зробив офер ?ber.

Я попросив у компанії відстрочку, щоб злітати на співбесіду в Facebook. У ?ber погодилися почекати два тижні. Але я так і не встиг за цей час отримати візу у Великобританію. В результаті прийняв пропозицію Uber — сподобалося спілкування з компанією на всіх етапах інтерв'ю. І влітку минулого року ми переїхали до Нідерландів.

Під час карантину Олексій працює з дому

Роль та обов'язки

У ?ber працюю на проекті Hero . Наше завдання — розробляти систему онбординга і винагороди для місцевих підприємців, які не планують самі працювати таксистами, але готові або надати свої машини потенційним водіям, або привести знайомих водіїв і супроводити їх від етапу реєстрації на сайті до здійснення перших поїздок.

Я займаюся Frontend-частиною. Ми використовуємо Fusion.js фреймворк (створений у ?ber), у якого під капотом Node.js + React.

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

За моїм враженням, робота в продуктовій компанії (в моєму випадку ?ber) відрізняється від роботи в аутсорсингу. По-перше, тут дають більше свободи — а з нею і більше відповідальності. Ми самі вирішуємо, яку вибрати архітектуру, які технології використовувати на проекті, як вести облік завдань. Звичайно, це не абсолютна анархія: ми ведемо документацію і повинні аргументувати, чому приймаємо такі рішення. А якщо вночі «впав» код, який ми вдень написали і залили на продакшн, то саме наша відповідальність — прокинутися і як можна швидше все полагодити (прийде повідомлення одному із членів команди в залежності від графіка чергування).

По-друге, відкриті завдання. В аутсорсингу я звик, що мені ставлять конкретне завдання з технічними деталями — я сідаю і його виконую. Тут інший підхід. Наприклад, завдання звучить так: «Реалізувати можливість пошуку водіїв, пов'язаних з вашим обліковим записом користувача» — і все. Звичайно, я трохи утрирую, звичайно є деякі технічні вимоги. Але все одно постановка завдання максимально відкрита. І я сам повинен визначити, з якими командами всередині компанії зв'язатися, потім запланувати регулярні зустрічі, створити документацію і вибрати, які сервіси використовувати. Для цього потрібно вникнути не тільки технічні, але і в бізнес-вимоги до задачі. Я до сих пір перестраиваюсь на такий формат роботи.

По-третє, близький контакт із 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;
книга .

Мені подобається ідея про те, що навчання і практика — це як вдих і видих. Вивчив щось- вдихнув, застосував на практиці — видихнув. Якщо двічі вдихнути без видиху (багато теорії без практики), задихаєшся, втрачаєш інтерес. Якщо робиш багато видихів без нових вдихів (багато практики без вивчення нового і без свіжого погляду на проблему), може загальмуватися професійний розвиток.

Систематизувати вивчений матеріал допомагає написання технічних статей. Коли один раз все розпишеш, буде простіше розповідати про свій проект будь-якому слухачеві усно. У тому числі — роботодавцям на співбесідах. Посилання на опубліковані статті я збираю .

Ретроспектива та плани на майбутнє

Я ціную той шлях, який пройшов. Не можу сказати, що хотів би щось змінити або порадити собі на зорі кар'єри щось конкретне. Можливо, іноді шкодую, що мені не вистачає академічних знань з алгоритмів, структур даних, математика (лінійна алгебра, статистика і так далі), фундаментальним мов програмування. Це дозволило б проходити курси по Machine Learning не за місяць, а за два тижні — і економити час. Але ніколи не пізно це освоювати.

Початківцям розробникам рекомендую знайти «завдання-біль» і вирішити її за допомогою пет-проекту. «Завдання-біль» дасть мотивацію виділяти час на проект, а сам проект призведе до професійного зростання. На своєму досвіді переконався, що це найкращий вклад в розвиток. Без такого самоосвіти я б не потрапив в компанію рівня ?ber.

Не біда, якщо не вдається виділити на свою «пісочницю» дві години на день. Навіть одну годину або 30 хвилин — це краще, ніж нічого. Головне — займатися регулярно і не боятися експериментувати. Потроху, але щодня. Це наблизить до офер в компанію мрії або навіть допоможе знайти ідею власного стартапу.

Що стосується планів, поки продовжу розвиватися у ?ber. Хочу підвищити Seniority-level (зараз займаю Middle-позицію). У довгостроковій перспективі подумую про те, щоб розвиватися в Machine Learning. Але поки що ще не визначився до кінця, на скільки мені це цікаво. Якщо в наступні місяці або роки інтерес не згасне, буду шукати можливості для переходу в цю сферу.

Опубліковано: 10/06/20 @ 07:00
Розділ Блоги

SEO Блог