Сегодня у нас интервью c Никитой Галкиным, System Architect. Никита переписывает Node.js монолиты на микросервисы c помощью TypeScript и умеет делать счастливыми и разработчиков, и бизнес.

Как ты попал в IT?
Компьютер появился у меня в доме, когда мне было 7 лет. Это был Sinclair ZX Spectrum моего брата. Естественно, на нем я ничего не программировал, да и играть мне давали редко.
В школе у меня не было нормального преподавателя по информатике, зато были хорошие учителя математики, поэтому я отлично решал алгоритмические задачи. Когда же дело доходило до практики программирования - это был провал. Мне никто не объяснял как писать на TurboPascal, с его выделением памяти и прочей чертовщиной. Короче, я был типичный ботан-олимпиадник.
В университете так получилось, что я пошел работать со второго курса. Это была работа фин. аналитика. Она состояла из однотипных скучных задач в Excel, которые я решил автоматизировать. В этом мне помог Visual Basic.
А потом я начал играть в игры.
Летом между вторым и третьим курсом брат сделал “подлянку”.
Он показал мне Ragnarök Online (культовая многопользовательская ролевая десктоп онлайн-игра, разработанная корейской компанией GRAVITY Co., Ltd. в середине 2000 года. - примечание редактора) игра, в которую я засел недели на две. Днем работа, ночью игра. Выйдя из игрового запоя, я понял что так нельзя. Бросать игру не хотелось, потому что мой персонаж превратился в тамагочи. В этом мне помог бот написанный на perl. Благодаря ему, я быстро вошел в топ-100 игроков сервера.

«Мой путь в IT я начал не как путь программиста, который продает свои услуги, а как путь бизнесмена, который делает продукт, общается с клиентами и несет перед ними ответственность»

Спустя пару месяцев один из членов гильдии попросил, чтобы я поставил на бота его персонажа. Помню, тогда спросил его: «А когда я должен остановиться? Сначала я помогу тебе, потом другому согильдийцу, а потом вся гильда уйдет в бан?». Его ответ меня шокировал: «Вообще-то такую услугу продает <Ник>. Но ему я не доверяю, его уже несколько раз банили. А тебя нет. Давай я лучше заплачу тебе 100wmz» (Валюта WebMoney соответствующая доллару 1 к 1 - примечание редактора). Отойдя от шока, я, естественно, согласился.
shutup
Это была первая прокачка, это были первые заработанные таким образом деньги.
Мой путь в IT я начал не как путь программиста, который продает свои услуги, а как путь бизнесмена, который делает продукт, общается с клиентами и несет перед ними ответственность

Ты начал заниматься прокачкой персонажей за деньги?
Да, и не только этим. Я продавал игровую валюту, редкие вещи. Сотрудничал с реселлерами, в том числе из Китая. Это растянулось на добрых 5 лет с 2006 по 2010.
За это время я узнал игровую механику не только на уровне билдов персонажей, квестов, локаций, монстров, но и механики расчета и протоколов взаимодействия клиент-сервер. Я часто задавал вопрос: а что, если... Видимо, они не волновали корейских программистов. Поэтому я находил баги и активно их использовал. Ботовод-читер, продающий свои услуги.
Я экспериментировал не только в игре, но и в способах работы с клиентами. В какой-то момент сделал сайт, на котором в автоматическом режиме шла доставка оплаченного товара. Интерфейс сайта сделал аналогичным игре, вытащил спрайты, заказал у верстальщика верстку корзины. На бэкенде была безумная связка из PHP, MySQL с хранимыми процедурами и ботами на Perl. Этот франкенштейн работал и приносил феерические деньги, именно так я заработал на квартиру.

«Этот франкенштейн работал и приносил феерические деньги, именно так я заработал на квартиру»

В тот момент моя бото-ферма состояла из 3-х мощных компьютеров, на которых бегало 100-150 ботов. Они взаимодействовали друг с другом через шину сообщений этаким аналогом RabbitMQ.
Это сильно сформировало меня. Сейчас, решая задачу, я обдумываю несколько способов:

  • с лучшей скоростью внедрения, чтобы проверить идею
  • performance-oriented (кто его знает, как по-русски), чтобы эффективней всего использовать ресурсы
  • надежный, чтобы его не взломал другой ботовод-читер

Как ты перешел от бизнеса, связанного с игрой, к тому, чем занимаешься сейчас?
Все началось с PHP-«сайтов под ключ» сначала на WordPress, потом на Laravel. В то время в моем круге общения часто спрашивали про сайты. Я показывал примеры своих работ: сайт магазин, сайт гильдии, блог. Меня часто просили: «Сделай нам такой же».
Поэтому в какой-то момент я подумал: «Почему бы не делать сайты «под ключ»? В отличие от заказчика, я могу четко поставить задачи и проконтролировать их выполнение. Если что-то пойдет не так, то я могу просто сесть и за ночь доделать».

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

«Morning is time to update your project vision»

Cейчас я работаю как контрактор в продукте и вряд ли вернусь в аутсорсинг. У нас небольшая команда разработки, и мы полностью отвечаем за продукт. Поэтому мой рабочий день начинается с анализа метрик production-сервера и сообщений от поддержки.
Что осталось общее? В начале рабочего дня понять, что поменялось или произошло со вчера.

Какая у тебя роль в команде?
У меня в команде нет менеджеров, я общаюсь напрямую с СТО (Chief Technical Officer - технический директор - примечание редактора). У нас нет микро-менеджерского подхода «делай, как я сказал». СТО рассказывает о проблемах, которые есть у бизнеса, а уже моя роль - предложить варианты, как можем это реализовать. Обычно при выборе варианта ключевой критерий - это скорость. Сначала сделать быстро, ведь не ясно насколько эта фича нужна бизнесу. Потом, если взлетит, можно будет улучшить, чтобы работало быстро и безопасно.

Пишешь ли ты код?
Да, пишу. За последние три месяца, после перехода в продукт, в день выходит от 200 до 1500 строк кода.
Ты спросишь почему так много? Дело в том, что приходится много рефакторить, причем как свой код, так и код предшественников.

«Иногда 200 строчек кода могут давать больше ценности, чем 1500»

В чем различие между работой в продукте и в аутсорсе?
В подходах, в отношении к результату. В аутсорсе то, что результат твоей работы никак не влияет на твою жизнь, самооценку, зарплату в конце концов. Главное, делать чуть лучше, чем сосед. Причем важно делать то, что сказал заказчик. Если вдруг заказчик или менджер начинают требовать больше, то всегда можно перепрыгнуть между галерами/проектами и отсидеться на новом месте.
В продукте ты отвечаешь за конечный результат. В продукте на дейли стендапе можно услышать, что-то вроде: «У нас тормозили новые REST эндпоинты, я разобрался, что дело было в DB. Добавил новые индексы. Теперь не тормозит.»

Над какими проектами ты обычно работаешь?
В аутсорсе я выбирал проекты, где нужно было заниматься не функциональными параметрами проекта. Например, проект взлетел и теперь монолит нужно распилить на микросервисы, чтобы улучшить перфоманс и проще было добавлять новый функционал.
О подходах к разработке можно говорить долго. Об этом отлично умеет рассказывать Алименков (https://twitter.com/xpinjection - примечание редактора). На конференциях это звучит как engineering excellence.

Как ты оцениваешь задачи?
Я не оцениваю задачи, я оцениваю проблему, которую надо решить. Помогаю ее сформулировать в User Story. На самом деле, бизнес не интересуют какие-то инженерные задачи, ему интересно когда и что получат его клиенты.
Поэтому мой ответ: если я оцениваю задачу, то делаю это в днях. Если задача требует больше 5 рабочих дней, я предлагаю ее разбить на подзадачи, которые можно будет зарелизить/показать по отдельности.

Какое оптимальное количество людей в команде?
Оптимальное по какому параметру?

  • По управляемости? Команда с одним мудаком уже считается плохо управляемой. А мы все мудаки в той или иной мере.

«Команда с одним мудаком уже считается плохо управляемой»

  • По производительности? Тогда важно не количество людей, а главное – одинаковое видение.
  • По легкости коммуникации? Если тебе некомфортно выполнять работу, потому что нужно общаться с людьми, то проблема не в них, проблема в тебе.
  • По стабильности? Снова не размер команды, а процессы и дисциплина их исполнения. Это дает предсказуемость и прозрачность.

Кто в твоей картине мира Джун, Мидл, Синьор и Архитектор?

  • Junior - тот человек, которому говорят, что сделать. Это человек, которому дали лопату и сказали «копай».
  • Middle - это junior, способный задавать вопросы, ответы на которые помогут сделать результат лучше.
  • Senior - то это человек, который мало того, что в одиночку может полностью «запилить» фичу, так предложит несколько вариантов реализации.

Как определить, кем ты являешься по такой терминологии?
Если ты сделал, чтобы оно просто работало, то ты – Junior. Если оно еще и правильно работает, то ты – Middle. А уж, если ты реализуешь фичу, чтобы она работала быстро и выглядела красиво, то ты – Senior.

«Если ты реализуешь фичу, чтобы она работала быстро и выглядела красиво, то ты – Senior»

По сути, это реализация принципа итеративной разработки: «Make it run, make it right, make it fast, make it beautiful». То, на каком моменте ты останавливаешься, и определяет твою «лычку».
Если говорить про архитектора - это тот шизофреник, который думает и c точки зрения бизнеса, и с точки зрения разработки. В основном он задает вопросы, о которых ни бизнес, ни разработчики не задумываются.

Получается, что если ты не можешь сделать фичу самостоятельно, то ты не Senior?
Получается, что так.

Самое запоминающееся собеседование, которое ты проходил?
Ох, я их столько проходил. Наверное, самым запоминающимся было собеседование в конце зимы 2016-го года в Ciklum.
Предыстория. Когда я меняю проект, я воспринимаю поиск нового, как работу. Поэтому я собираю список вакансий, которые есть на рынке по моему профилю. Естественно, я прохожу собеседования только там, где я попадаю в интересующую меня зарплатную вилку. Дальше из предложений, которые ты получаешь, осталось выбрать самое интересное. Нормальная ситуация, когда за 2 недели ты проходишь 10+ собеседований и получаешь 3-4 предложения.
Как обычно, в тот день было поставлено несколько собеседований. Первое было назначено на Шулявке. Начался сильнейший снегопад. Поэтому первая часть собеседования происходила по скайпу из McDonalds. Причем по NodeJS, в частности, и JS в целом, меня собеседовали два джависта. Вопросы в лучших традициях Java школы. Мне кажется, я им понравился ответом: «Расскажи, как ты понимаешь REST?», в котором я вспомнил ту самую диссертацию (“Архитектурные стили и дизайн сетевых программных архитектур, Рой Филдинг - примечание редактора). Уже в офисе, на второй части собеседования, я понял, что тимлид смотрит не на знания, а на то, «будет с этим человеком комфортно общаться или нет? Он вообще шарит?».
А запомнилось мне это потому, что я осознал, что собеседования могут проходить по-другому. Когда ты понимаешь, что человек не проверяет твои знания - он доверяет. Умные слова знаешь, с кодом разберешься. Есть испытательный период, вот тогда и посмотрим.

«Собеседования могут проходить по-другому, когда человек не проверяет твои знания, а доверяет. Умные слова знаешь, а с кодом разберешься»

Как ты относишься к тестовые заданиям?
Не очень. Я редко на них соглашаюсь. Обычно я говорю: «Ребята, хотите, чтобы я выполнил тестовое, значит оно должно быть или оплачиваемым, или я могу выкладывать его в общий доступ». Вы не представляете, как часто гуглятся тестовые.
Что мне не нравится в тестовых, это отсутствие обратной связи. Человек потратил несколько часов, а если это новый для человека технологический стек, то и пару дней. Поэтому не дать обратную связь - это просто неуважение.
При найме на свои проекты я стараюсь избегать тестовые. Даю их только, если есть сомнения. В обязательном порядке даю развернутый ответ, для этого процесс проверки тестового у меня формализован – составлен чеклист.

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

Три книги, которые повлияли на тебя.

  1. «Игра Эндера» Орсона Скотта Карда (https://fantlab.ru/work4670). Это из подросткового, из разряда, насколько важно понимать суть вещей.
  2. Если говорить про техническую литературу, то это «Микросервисы» (https://www.amazon.co.uk/Building-Microservices-Sam-Newman/dp/1491950358). Она написана в том формате технической литературы, которую хочется перечитывать.
  3. «Факты разработчика» (https://www.amazon.com/Facts-Fallacies-Software-Engineering-Robert/dp/0321117425). Она произвела глубокое впечатление. Я часто в дискуссиях аппелирую к ней.

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

Твой день девиз по жизни?
Make dreams come true.

Любимый технический термин?
Консистентность.

Что необходимо успеть до 45?
Всё! До 45 нужно сделать хороший фундамент для следующих 45.

Как прокачивать hard skills?
Завали production и подними его.

Как прокачивать soft skills?
Любить людей и общаться с ними. Пройдите тренинги по НЛП.

«Чтобы прокачать soft skills - люби людей и общайся с ними»

Какой у тебя челлендж на данный момент?
Life balance, чтобы хватало времени на все. Например, хочу привести тело в форму, чтобы можно было бегать марафоны. Это требует серьезной дисциплины, а хочется и печеньку съесть и загулять на всю ночь вместо того, чтобы выспаться.

На что обратить внимание тем, кто начинает выступать на конференциях?
Не начинайте... Просто представьте, что вы уже выступали не раз и не два.

Поймите, выступление - это как разговор на работе на тему: «давайте перейдем на другую технологию» или дискуссия на курилке. Единственная разница в том, что вы выйдете перед аудиторией в 50 человек на митапе или 500 на конференции.

«Не начинайте, просто представьте, что вы уже выступали не раз и не два»

Смысл остается тем же - вы должны быть открыты, вы должны рассказывать свою историю, в этом случае вы будете воспринимать слайды как инструмент, чтобы донести свою мысль.

«Выходя на сцену, поймите, что вы хотите продать людям»

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

В ближайшее время на каких конференциях тебя можно будет увидеть?
Дам обновленный доклад «Как написать качественное Node.js приложение» на Morning@Lohika 4-го августа (http://morning.lohika.com/news/node-js-morninglohika) и готовлю новую тему на HighloadFWDays (https://fwdays.com/event/highload-fwdays-2018)