Testing Stage’19: Technical | Security | Management and Approach — Early bird till 21 Dec. Hurry up!
×Закрыть

Как я работаю: Богдан Гусев, 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 Sharding — эта технология позволяет хранить данные клиентов в нескольких базах данных. На это ушло около 6 месяцев. Чтобы успевать работать над этим, мне пришлось немного перестроить все процессы — к примеру, часть оперативных задач делегировать проектному менеджеру.

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

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

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

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

Чтобы расставить приоритеты, использую концепцию об анализе и синтезе. Сначала в голове делю задачу на множество составляющих, а затем заново «пересобираю» ее. Из этого рождается более целостное понимание. Этот метод помогает и при обучении чему-то новому: я раскладываю новую технологию или метод на элементы и вычленяю те, которые реально можно будет использовать.

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

Я не стремлюсь сделать за день как можно больше задач. Делаю упор на качество и долгосрочную перспективу.





Книжки и самообразование

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

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

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

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

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

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

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

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

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

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

LinkedIn

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

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Было интересно, спасибо. А можете порекомендовать литературу, статьи или дать пару советов новоиспеченному тех лиду?

Ого, здається це вперше в цій рубриці людина зі здоровим ворк-лайф балансом, а то всі що читав сидять в офісі до 10 вечора :)
Цікаво дізнатись, коли ви брали участь в розробці для рельс, тоді суміщали онсайт роботу із розробкою для опенсорс? Можливо це розділення роботи і вільного часу прийшло якраз із досвідом, бо я мало уявляю як із цим самим графіком можна все встигати)

хотілося б послухати більше про

внедрить DataBase Sharding — эта технология позволяет хранить данные клиентов в нескольких базах данных

:)

Вот здесь мой коллега подробно рассказывает: www.youtube.com/watch?v=0IuMWlSHXIw

Спасибо, за авторам за статью и за то вдохновляете людей.
Чесно говоря, я тоже рубист и люблю писать open source проекты.
Потому мне наверное, так интересно было читать.
Успехов вам Богдан.

Мак на фото староват будет, с прорезью для CD, где-то Core2Duo CPU :)
Больше похож на талисман, чем на инструмент для работы с жадными к ресурсам тулзами.

Использовал подобный до этого года — CD дисковод менялся на optibay с запасным SSD диском, память можно было проапдейтить. Проц i5, не помню какой версии. Но охлаждение у них не было продумано — страдал видеочип (перегревался и отходил от подложки), так что пришлось менять из-за участившихся GPU panic (паяли его раз 10 — помогало на 6 месяцев максимум). Если бы не этот недостаток — работал бы на нем дальше, потому что не чувствовалось нужды в обновлении железа под задачи разработки.

Никогда не комментирую. Но тут, аж, передернуло, не поленился откоментить. Должно быть «Database Sharding», но ни в коем случае не «...Sharping».

спасибо, исправили в тексте.

Подписаться на комментарии