Як я працюю: Богдан Гусєв, CTO Talkable

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

Богдан Гусєв — один з активних учасників Ruby-спільноти. Він брав участь у розробці фреймворку Ruby on Rails, а також написав кілька своїх бібліотек , які доступні на GitHub.

Більше 6 років Богдан працює в стартапі Talkable. Він керує командою з 20 осіб і намагається усувати всі технічні проблеми ще до того, як вони з'являться.

Про себе

Я почав вчити програмування ще в школі. Мені було цікаво, але я не виходив за межі шкільної програми. На старших курсах університету вибирав між IT і фінансами. Але з фінансами не клеїлося, ця сфера ніби виштовхуючи. І я все більше цікавився програмуванням. У той час мій сусід по кімнаті в гуртожитку працював віддалено в одній IT-компанії, і я теж приєднався до його команді. Потім було ще декілька віддалених проектів в інших компаніях: Gera-IT і Hi-Tech.

Перші два роки я програмував на Java, але пізніше захопився Ruby. Випадково прочитав на якомусь форумі, що вийшла нова версія фреймворку Ruby on Rails. І мене зацікавило, що творці цього інструменту вже вирішили багато проблем, з якими я тільки почав стикатися при розробці на Java.

Наприклад, в Java на той момент доводилося прописувати кожен SQL-запит вручну в XML-файлі з великою кількістю дублювання коду між запитами (MyBatis, тоді iBATIS). А в Rails вже був просунутий генератор SQL-запитів і засоби повторного використання фрагментів SQL в різних запитах (ActiveRecord).

У 2010 році я прийшов працювати в компанію Railsware. Спочатку мені там подобалося, але потім почали виникати розбіжності з колегами, керівниками проекту і замовником — вони стосувалися поглядів на розробку. Замовники вимагали реалізації максимальної кількості фіч за секунду і постійно змінювали бізнес-модель проекту. Це робило розробку вкрай болючою: коли речі використовуються не для того, для чого були спочатку зроблені. Я завжди вважав, що краще доводити почате до результату, чи він добрий чи поганий. А якщо настало розчарування і прийшла нова ідея — краще почати з нуля.

Тоді я замислився, що мені хотілося б працювати з більш досвідченими колегами та замовниками, які розуміють, чого хочуть, а не грають в стартап :)

Я зрозумів: щоб працювати з професіоналами, мені потрібно їм відповідати. Тоді я сам працював на середньому рівні, а хотілося чогось більшого. І я почав посилено вчитися і розвиватися. В якості майданчика для практики вибрав опенсорс. Мені завжди подобалася ідеологія ПЗ з відкритим кодом. Тим більше, майже всі інструменти, якими я користувався, розроблялися саме open-source.

Open-source та розробка фреймворку Ruby on Rails

Щоб не розмінюватися на дрібниці, я вирішив приєднатися до опенсорс-розробці самого фреймворку Ruby on Rails. Було цікаво втілити свої ідеї і отримати зворотній зв'язок про них. Я почав вивчати проблеми, які можу вирішити. Найбільше мене зацікавила тема продуктивності. Якщо ви пропонуєте щось, що прискорить роботу програми, то висока ймовірність, що ваше рішення приймуть і не будуть сперечатися, що «раніше було краще».

Я працював над системою ActiveSupport Callbacks, за два роки зумів збільшити її продуктивність більш ніж в 2 рази. Бібліотека була в жалюгідному стані: у неї часто використовувалася кодогенерация і eval. Не було жодного серйозного зміни за пару років. В цьому я побачив величезну можливість для себе: складна проблема і ніхто мені не заважав її вирішувати.

Я розробив свій підхід до поліпшення і реалізував його в бібліотеці Diffbench . Ця бібліотека дозволяє виміряти продуктивність коду, використовуючи написаний вами benchmark, до і після накладення змін. В GitHub є багато прикладів. З допомогою неї я итерировал зміни в коді ActiveSupport Callbacks, переконуючись, що продуктивність поліпшується або як мінімум не падає після кожного коміта.

Крім Diffbench, я написав ще кілька бібліотек для Ruby:

Datagrid — дозволяє швидко будувати інтерфейси админок для табличних даних.
Furi — дозволяє робити будь-які маніпуляції з URL в один рядок коду. Зазвичай у аналогів їх завжди 2-3 і не всі підтримуються.
JS-Routes — дає доступ до Ruby on Rails routes в JavaScript.
accept_values_for — засоби швидкого тестування валідації для Rspec.

Після роботи над Ruby on Rails на мене посипалися пропозиції про співпрацю — на мене виходили через мій профіль на GitHub . І вони були більш привабливі, ніж моя поточна робота. Після цього я півроку пропрацював в одній продуктовій компанії на позиції СТО, але і там була, по суті, гра в стартап.

А потім, в 2012 році, мені запропонували посаду СТО в Talkable. У компанії був серйозний технічний криза, і я прийняв виклик поліпшити продукт з точки зору технологій.

Про роль СТО в Talkable

Talkable — це американський стартап, який розробляє реферальні програми для інтернет-магазинів. Із серії «приведи друга — отримай знижку». Ми вбудовуємо наші віджети на сайт клієнта.

Коли я прийшов в Talkable, у компанії були клієнти і продажу, але не було технології, яка б дозволила ефективно здійснювати заявлений сервіс. На перших порах це був технічний пекло, але саме цього мені й хотілося. Мені належало повністю переписати продукт і при цьому зберігати його безперебійну роботу онлайн.

Пам'ятаю цікавий діалог з засновникам компанії, коли я тільки приступав до роботи:

Богдан, скільки часу знадобиться, щоб переписати продукт?
А скільки часу ви його створювали?
Приблизно два роки.
Ось стільки ж знадобиться, щоб переписати.

Так воно і вийшло, мені знадобилося два роки. Одна із самих веселих ситуацій: в проекті була функціональність, реалізована в основному на JavaScript. Дані, які приходили на Back-end, просто клалися в базу — і інтерпретувати їх без JavaScript і HTML було нереально. Щоб перевести дані у формат, зрозумілий на рівні Back-end, довелося написати мигратор даних. Він відкривав браузер, брав дані звідти і відправляв їх у базу в новому розуміється форматі, про який до змін можна було судити тільки з інтерфейсу.

Головний виклик Talkable з точки зору технологій — це гнучкість. У нас 230 клієнтів, і кожен хоче щось своє — індивідуальний інтерфейс, функції під свої потреби. І потрібно швидко налаштовувати платформу під кожні нові вимоги. Ще одне завдання — велика нагруженность платформи, так як до нас йде трафік всіх наших клієнтів.

Мої обов'язки як СТО — передбачити технічні проблеми і виправляти їх до того, як вони настануть. Кожен день сам пишу код, але все ж приблизно половина всього часу йде на менеджерські завдання. Зараз в моїй команді працює 10 Back-end розробників і 3 — Front-end. Всі знаходяться в Києві.

Я працюю в компанії вже 6 років, і мені подобається, що з роками можу бачити наслідки прийнятих мною рішень. Це мотивує працювати тут і далі.

Іноді я замислююся, що людина з таким характером, як я, повинен був стати радше хардкорним програмістом, ніж управлінцем. Але зараз я прийшов до того, що мені дуже цікавий результат будь-якого починання. І якщо в якийсь момент найбільше користі від мене буде від спілкування з людьми, а не від вирішення технічних завдань, саме цим я і займуся.

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

7:00. Прокидаюся, займаюся йогою, снідаю, займаюся домашніми справами, збираюся на роботу.

10:00. Виходжу на роботу. Йду пішки, мені подобаються ранкові прогулянки.

10:30. В офісі першим ділом перевіряю пошту, повідомлення в чатах, оповіщення від систем, які моніторять наші сервера. Дивлюся, які завдання і зустрічі заплановані на сьогодні, і думаю, як з цього скомпонувати свій робочий день.

Частина моєї роботи — розставити пріоритети, зрозуміти, що саме важливо, а що може почекати. По-перше, в стартапі завжди в кілька разів більше роботи, ніж можливостей її виконати. А по-друге, важливо виділяти саме ті справи, які будуть мати значення в довгостроковій перспективі, а не просто створять інформаційний шум сьогодні.

12:30. Проводжу стендап Back-end команди, де кожен розповідає, що зробив вчора і що планує зробити сьогодні. Це єдиний щоденний мітинг для розробників.

13:00. Рухаюся по списку своїх завдань і зустрічей. У цьому плані кожен день не схожий на попередній — все залежить від поточних пріоритетів.

Крім оперативних завдань, прагну приділяти час і стратегічним. Наприклад, нещодавно нам вдалося впровадити DataBase Sharping — ця технологія дозволяє зберігати дані в декількох базах даних. На це пішло близько 6 місяців. Щоб встигати працювати над цим, мені довелося трохи перебудувати всі процеси — наприклад, частина оперативних завдань делегувати проектному менеджеру.

18:30. Закінчую роботу. Вечір, як правило, приділяю родині.

Інструменти і продуктивність

Для розробки я вже багато років використовую Vim. Робочі листування ми ведемо в Slack, пошта Gmail. Я думаю над тим, щоб перевіряти пошту тільки у фіксований час пару раз в день, але поки так не виходить: люди очікують швидку відповідь.

Всі важливі завдання записую в паперовий блокнот. Мені подобається, що на папері не можуть «спливти» повідомлення, як це буває при роботі за комп'ютером. І від планування не відволікають ніякі зовнішні подразники.

Щоб розставити пріоритети, використовую концепцію про аналізі і синтезі. Спочатку в голові ділю завдання на безліч складових, а потім заново «пересобираю» її. З цього народжується більш цілісне розуміння. Цей метод допомагає і при навчанні чомусь новому: я розкладаю нову технологію або метод на елементи і вычленяю ті, які реально можна буде використовувати.

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

Я не прагну зробити за день якомога більше завдань. Роблю упор на якість і довгострокову перспективу.

Книжки і самоосвіта

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

До того ж, розуміння, які емоції я відчуваю щодо якого варіанту розвитку ситуації, допомагає мені правильно прийняти рішення. Раніше я ігнорував цей аспект і враховував лише об'єктивні фактори, але з часом навчилась приймати до уваги більше інформації. І саме в цьому напрямку бачу свій подальший розвиток.

Зараз почав читати «Коли неможливе можливо. Пригоди в незвичайних реальностях» Станіслава Грофа. На майбутнє планую прочитати «Людина та її символи» Карла Юнга і «Гра свідомості» Свамі Муктананда.

Але взагалі частіше читаю статті, ніж книги. На книгу потрібно більше часу, щоб повністю зануритися в текст і зрозуміти, що автор має на увазі. А вільного часу постійно не вистачає :)

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

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

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

Приміром, якщо чоловік не встиг побути підлеглим, він не зможе якісно керувати своєю командою. Але повернутися до ролі підлеглого після ролі керівника буде морально складніше, ніж якщо б спочатку планомірно рухатися по кожній сходинці.

Що стосується планів на майбутнє, поки що мені подобається працювати в Talkable. Мене приваблює можливість розвивати продукт, але при цьому немає якихось особистих кар'єрних амбіцій. Перспектива відкрити свій стартап мене не цікавить — це пекельно важко, а у мене в житті багато інтересів, крім роботи.

Думаю, було б цікаво коли-небудь приєднатися до розробників фреймворку Ruby on Rails — не як волонтер у вільний час, а як член основної команди.

Опубліковано: 26/11/18 @ 11:00
Розділ Різне

SEO Блог