Роман Лютиков, Software Engineer в Attendify (https://attendify.com/). Разрабатывает UI на ClojureScript (и не только), проводит воркшопы и обучает разработке интерфейсов.

https://github.com/roman01la
https://twitter.com/roman01la
https://romanliutikov.com/

С чего начался твой путь в IT?
В университете сдал на отлично курсовую за то, что использовал тег audio на странице. Тогда это мне показалось очень крутой штукой :) Немного разобрался в верстке и WordPress, и начал брать заказы на Upwork. Со временем захотелось делать больше интерактивных штук, поэтому изучил jQuery и анимацию. Делал анимированные лендинги, открытки и прочую ерунду. Всегда удивлялся, что за это еще и платят. Сейчас немного странно вспоминать то время.
В какой-то момент подвернулась возможность сделать web-приложение. Тогда я выбрал Backbone и удачно завалил проект из-за отсутствия опыта. Спустя некоторое время получил первую работу в аутсорсе.
adobe
Расскажи про свой первый рабочий проект:
Это было в период фриланса. Не уверен, что первый проект, но по крайней мере он запомнился как один из первых. Я сделал лендинг с кучей анимаций. Выполнить это без дополнительных инструментов оказалось довольно сложно, и тогда нашел Adobe Animate. Это что-то вроде After Effects для веба, сейчас таких инструментов уже много. Кстати, с этим инструментом связана интересная история.
В то время он был экспериментальный и генерировал кучу кода, да и сейчас, наверное, тоже, но сделать более-менее сложные переходы, анимации и эффекты можно было очень быстро. В качестве эксперимента я сделал демку с системой частиц, которая сильно тормозила сгенерированную анимацию. Запостил демку на форуме разработчиков, описал проблему, и они взяли ее к себе в качестве бенчмарка производительности. Было очень круто, когда на конференции в Нью-Йорке упомянули мой вклад в развитие инструмента. Это был первый раз, когда публично похвалили мой проект.
Так вот, за лендинг тогда попросил $80 (да, это смешно), хотя сейчас понимаю, что можно было смело брать $800. Но для меня было важно получить хороший рейтинг на бирже фриланса, поэтому я почти не жалел об этом.

У тебя есть пет-проекты?
Да. Но, в основном, они все мертвые или на стадии идеи. Прямо сейчас основной пет-проект - это обучение Clojure. Когда-нибудь никогда, я оформлю это вот здесь https://learn.clojurescript.ru/, а пока что, у меня хватает времени только на проведение групповых занятий онлайн.

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

С чего ты начинаешь свой проект?
С идеи. Точнее, сначала возникает проблема, а потом уже идея ее решения. Чаще всего это дурацкие вещи, которые интересны только себе самому. Иногда выходит так, что твои, казалось бы, поделки оказываются полезными другим разработчикам. Поэтому важно сообщать миру о своих мыслях и проектах.
Когда ты технарь, сложнее всего удержаться от соблазна сразу сесть за реализацию, тут разработчики согласятся со мной. Я уже отучил себя от этого, хотя иногда, если есть свободное время, просто для фана, могу уделить пару вечеров на создание прототипа. А вдруг выйдет что-то клевое?

Как ты закладываешь риски при оценке задачи?
Когда есть задача, которой занимаюсь самостоятельно, то интуитивно знаю, что делать, что могу сделать, а на что нужно время для исследования/изучения. Думаю, что могу полагаться в этом на свой опыт.
Задачи в команде обычно обсуждаются перед началом работы. Нужно выяснить, все ли члены команды понимают что нужно сделать в рамках своих задач. Хорошо, когда люди сами задают вопросы. Бывает так, что у разработчика нет опыта решения конкретной задачи, тогда человеку нужно дать больше времени для изучения. Важно определить компетенцию разработчика. Все упирается в знает/не знает, может/не может сделать. Если разработчик думает, что может сделать все своими силами, но ты знаешь, что он ошибается, наверное, нужно направить его в правильную сторону, обсудить. Иначе разработчик просто зря потратит свое время и время компании.

«После этого начал ценить работу в команде»

Расскажи про задачу-айсберг и как ты ее решил:
Расскажу про то, почему не нужно изобретать свои велосипеды, если нет опыта. Это было в то время, когда все понемногу начинали переходить на React, а общепринятого, популярного решения типа Redux еще не было.
Тогда я подумал, что смогу сделать что-то свое, чтобы оно было более удобным для проекта. В итоге так сделал, что чуть не завалил проект. Ошибся в реализации абстракций и в определенный момент зашел в тупик. Решил проблему, обернув все это в более-менее удобный интерфейс, скрыв свой позор за слоем кода. После этого начал ценить работу в команде.

Три книги, которые тебя впечатлили и почему?
«Coders at Work» (https://www.apress.com/gp/book/9781430219484) - клевая серия интервью с известными разработчиками (Joe Armstrong, Guy Steele и др.). Очень интересно узнать об опыте и развитии карьеры таких людей.

По технической литературе я часто перечитываю книгу о функциональных структурах данных автора Криса Окасаки «Purely Functional Data Structures» (https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf). В книге описываются конкретные алгоритмы и реализации структур данных. Рекомендую.

«ВАЛИС» Филипа Киндреда Дика (https://en.wikipedia.org/wiki/VALIS) и многие другие его рассказы. Посмотрите фильм «A Scanner Darkly», по мотивам одноименной новеллы.

Известно, что разработчики страдают синдромом «самозванца», насколько это актуально для тебя?
Сейчас, по большей части, нет. Точно знаю, что все, чего добился - заслуженно. Потому что сейчас все недосыпания мне выходят боком. Считаю, что на данном этапе в жизни делаю вполне себе достойную работу, которой можно гордиться, при этом стараюсь не перерабатывать и уделять больше времени семье.

«Сегодня ты - сеньор, а завтра, на новой работе ты - джун»

Кто такие Junior, Middle, Senior, в твоей картине мира?
Все зависит от конкретного проекта и задач. Всегда найдутся более опытные разработчики. Сегодня ты - сеньор, а завтра, на новой работе ты - джун. Не смотря на это, не нужно бояться переходить в другие сферы в разработке, ведь твой опыт навсегда остается с тобой.

Т.к. в данный момент я работаю в продуктовой компании, то мое видение немного скошено в сторону требований к разработчику продукта.

Junior - это разработчик, который самостоятельно не способен понять, оценить и закончить задачу без помощи более опытного товарища. Возможно, он может подобрать библиотеки, исходя из последних трендов, но вряд ли обоснует свой выбор. Такого разработчика всегда нужно вести по проекту.

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

А Senior бывают разными. Чаще всего такой разработчик хорошо прокачан в своей и сопутствующих сферах. Например, для фронтендера это может быть бекенд, дизайн и UX. Для меня старший разработчик - это специалист, который может понять проект глобально, расставить приоритеты, определить возможные кейсы, что не покрыты спецификацией, раздать задачи и проследить за процессом разработки. Это не значит, что человек должен делать все, скорее, необходимо умение делегировать задачи и контролировать их выполнение.

Три фактора, которые привели тебя туда, где ты есть?
Жена. Она всегда поддерживает и вносит ясность в мою голову, гордится мной и это очень мотивирует.

Второй фактор - работа-хобби. Если работа - твое хобби, то ты всегда будешь мотивирован развиваться.

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

«Чтобы понять подходит ли вам разработчик, достаточно поговорить о его опыте и в процессе определить, насколько он близок вам по общению, как член команды»

Самое запоминающееся собеседование:
Всегда остаются хорошие впечатления от собеседований, на которых у тебя не просят решить дурацкие задачки. Чтобы понять подходит ли вам разработчик, достаточно поговорить о его опыте и в процессе определить, насколько он близок вам по общению, как член команды.
Самое глупое собеседование было, когда меня просто уговорили прийти на позицию Angular разработчика, в котором я ничего не понимаю. На все вопросы я отвечал: «нет, я не знаю что это» :)

Функциональное программирование или ООП
Главное, чтобы язык не был преградой в процессе решения задачи. Например, ООП в Java - это страх (для меня), потому что ты не можешь выразить решение максимально лаконично. Упоротая функциональщина в JavaScript тоже странно выглядит, потому, что это не идиоматичный стиль разработки в JS.

Твое хобби:
Не могу сказать, что на 100% - работа, потому что стараюсь больше времени уделять семье. Продал личный ноут и рабочий редко ношу домой. И то, только тогда, когда вечером запушил что-то в прод, а ночью клиенты просыпаются в США и может возникнуть какая-нибудь проблема. Вообще лучше так не делать.
Поэтому сейчас, наверное, конкретного хобби нет.

Спустя сколько времени новый человек начинает приносить пользу на проекте?
Зависит от того, как устроен процесс адаптации новых людей в компании. На верстку мы, как правило, нанимаем опытных разработчиков. Когда я пришел в компанию, то уже в первые пару дней реализовал и залил в прод небольшую фичу. Обычно в течение первой недели ты начинаешь уже что-то делать. Ребятам, которые переходят с JavaScript на ClojureScript немного сложнее, поэтому им нужно больше времени, чтобы полноценно втянуться в разработку.

Девиз по жизни:
Делай только то, что приносит тебе удовольствие.

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

«Пинок под зад от чувства ответственности приходит только за пару дней до конференции»

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

Ты часто выступаешь на конференциях, сколько у тебя выступлений или докладов?
Думаю, немного. Впервые я выступил в 2014 году на Web Standards Days (https://youtu.be/t8Td3Oq47yE?t=10295). За все время несколько раз выступил на локальных митапах и украинских конференциях. Сейчас выступаю реже, да и посещаю такие мероприятия тоже редко.
Составил список некоторых докладов для вас (https://www.youtube.com/playlist?list=PLHOTezm7WWkkHhEIOlzg0zzn2JfLH-3q4)

Ты проводил воркшоп в Голландии, расскажи об этом:
Это был воркшоп по ClojureScript. Первый такой я делал на ReactiveConf в 2017 году и собираюсь провести еще один, там же, в 2018. Сам воркшоп - введение в язык для тех, кому интересно изучить или просто попробовать что-то сделать. На Amsterdam JS было около 25 человек. Прошлись по основам языка и сделали несколько практических заданий. Все остались довольны. Если вам интересно попробовать, вот материалы из воркшопа (https://github.com/roman01la/amsterdamjs-clojurescript-workshop).

Аудитория была подготовленная?
Мне показалась, что большая часть участников - опытные разработчики, некоторые владели несколькими языками, и почему-то треть аудитории были белорусами, которые уже знали ClojureScript :)

«В Европе более фановые доклады, у нас чаще докладывают про глубоко технические темы»

Чем отличаются европейские конференции и митапы от наших?
Многим. Но с каждым годом разница все меньше. В Европе более фановые доклады, у нас чаще докладывают про глубоко технические темы. Не уверен, почему так происходит и не могу сказать, что это хорошо или плохо. На западе такие события чаще ориентированы на социализацию и знакомства. Мне кажется не техническому человеку проще интегрироваться в среду в таких условиях.
В любом случае, посещать конференции стоит по всему миру, люди везде разные и разные культуры разработки.
YGLF в Киеве по всем параметрам - лучшая конференция в Украине, да и в Европе, наверное, тоже. Такие события стимулируют приток западных докладчиков в Украину. Это клево!

Что необходимо успеть до 45?
Завести семью!
И если ты - разработчик, то понять для себя, что делать «на старости лет». Например, не вижу себя пишущим код в 40 лет, с другой стороны, я себя сейчас, в принципе, не вижу в 40 лет. Уже около 8 лет пишу код и мне все еще нравится, но сейчас понимаю, что это переходной период в моей карьере.

«Если разработчик что-то сделал не так, было бы неплохо обсудить, возможно сесть вместе и порефакторить»

Сколько «вторых» шансов необходимо давать подчиненному, который постоянно что-то ломает?
Я бы не называл это вторым шансом. Если ты ставишь задачу и ожидаешь качественного выполнения, то и сам несешь ответственность за результат. Если разработчик что-то сделал не так, было бы неплохо обсудить, возможно сесть вместе и порефакторить, или хотя бы указать на проблему и предложить решение. Нельзя давать «второй шанс», бросая человека на задачу без предварительной ретроспективы, чтобы опять получить тот же результат.

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

Самый быстрый способ прокачать хард скиллы?
Всегда работать в компаниях, где есть технические специалисты сильнее тебя. Как только тебе нечему и не от кого научиться, либо ты остаешься здесь самым «крутым чуваком», либо ты идешь дальше, и может даже за меньшие деньги, но твое развитие не останавливается. Ну, и ходить на конференции и митапы, общаться с докладчиками и участниками.

Как прокачать софт скиллы?
Быть нормальным человеком, никто не хочет работать с мудаками. Стараться ставить людей выше себя. Если тебе что-то не понравилось, можно спокойно разобраться в ситуации, задаться вопросом: «почему так произошло? Может, это Я что-то сделал не так?».

Опиши сотрудника, с которым тебе хотелось бы работать.
Открытый человек, с которым после работы можно пойти на пиво или просто отлично провести время. И которому можно прямо сказать: «Извини, конечно, но ты тут наговнокодил, давай что-то с этим сделаем» :)

Твои самые «быстрые» деньги за разработку
Работал с React Native: сделал проект, набрался опыта, провел пару докладов, меня заметили и несколько раз обращались за консультацией. За пару часов заработал хорошие деньги.

«Open Source, как криптоалгоритм, - если ни у кого нет доступа к его исходникам, скорее всего, там куча проблем»

Важен ли Open Source в контексте разработки?
Конечно! Для меня, как для фронтенд разработчика, - это основной источник готовых решений. Сейчас сделать тот же кастомный селект довольно трудоемкая задача. Я очень рад, что сообщество развивается, и у нас есть множество протестированных в бою библиотек. Open Source, как криптоалгоритм, - если ни у кого нет доступа к его исходникам, скорее всего, там куча проблем. Огромное сообщество берет на себя задачу полигона для тестирования и доработки ваших поделок.

Как стать контрибьютором в Open Source проекте

  1. Завести аккаунт на GitHub
  2. Найти репозиторий библиотеки, которая вам интересна
  3. Взять в работу существующий issue или самому создать, и написать: «Клевая библиотека, спасибо! Я могу чем-то помочь?»

Вносишь ли ты свой вклад в Open Source?
В глобальном смысле - нет. Я не сижу в обсуждениях на GitHub и не принимаю участия в формировании чего-либо. Есть свои библиотеки, которые развиваю и публикую исправления для библиотек, что использую в работе. Например, есть генератор из HTML в React компоненты.

Как ты делал генератор?
На прошлой работе дизайнеры сами верстали (все бы дизайнеры так делали) в статический HTML. Это было немного проблематично потому, что верстку нужно было перегонять руками в React компоненты. В итоге я написал инструмент, который автоматизирует этот процесс. Тогда я еще шутил, что теперь джунам будет нечего делать.
Сейчас у меня это самый популярный проект. Немного забавно, что делал много, как мне кажется, клевых технических штук, но конвертировать HTML в React оказалось самой необходимой штукой для людей. Из этого можно сделать вывод, что практическое применение важнее всего остального, пусть даже вы не гордитесь реализацией.
Ссылка на генератор: http://roman01la.github.io/html-to-react-components/.

«Самый «простой» способ что-то изучить - подать заявку на конференцию или митап»

Напутственное слово людям, которые хотят начать выступать?
Развиваться, изучать новое, делиться этим с сообществом. Самый «простой» способ что-то изучить - подать заявку на конференцию или митап. Это будет мотивировать вас изучить тему досконально. Не нужно рассказывать о том, что тебе не интересно, ведь сразу заметно из зала. Захватывающий доклад всегда исходит от докладчика, который увлечен этой темой.