Как я работаю: Богдан Гусев, CTO Talkable
[В рубрике «Как я работаю» мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]
Богдан Гусев — один из активных участников Ruby-сообщества. Он участвовал в разработке фреймворка Ruby on Rails, а также написал несколько своих библиотек, которые доступны на GitHub.
Более 6 лет Богдан работает в стартапе Talkable. Он управляет командой из 20 человек и старается устранять все технические проблемы еще до того, как они появятся.
О себе
Я начал учить программирование еще в школе. Мне было интересно, но я не выходил за пределы школьной программы. На старших курсах университета выбирал между IT и финансами. Но с финансами не клеилось, эта сфера как-будто выталкивала. И я все больше интересовался программированием. В то время мой сосед по комнате в общежитии работал удаленно в одной IT-компании, и я тоже присоединился к его команде. Затем было еще несколько удаленных проектов в других компаниях: Gera-IT и Hi-Tech.
Первые два года я программировал на Java, но позже увлекся Ruby. Случайно прочитал на каком-то форуме, что вышла новая версия фреймворка Ruby on Rails. И меня заинтересовало, что создатели этого инструмента уже решили многие проблемы, с которыми я только начал сталкиваться при разработке на Java.
Например, в Java на тот момент приходилось прописывать каждый SQL-запрос вручную в
В 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 — не как волонтер в свободное время, а как член основной команды.
