Роман Саченко, Team Lead/Back-end developer в DA-14 Software Development (https://da-14.com/) - ИТ компания которая занимается веб и мобильной разработкой используя JavaScript технологии. За время работы в IT индустрии он успел попробовать себя в роли технического ассистента, back-end разработчика, а так же тим лида. Роман умеет объяснять сложные вещи простыми словами, любит делиться опытом с коллегами и выступать перед публикой, возможно потому, что какое-то время играл в рок группе.

https://www.facebook.com/rsachenko
https://www.linkedin.com/in/rsachenko/
https://twitter.com/RSachenko

Расскажи про свой первый коммерческий опыт в ИТ
Если говорить о задачах реально коммерческих, то это был 9 класс. Самым первым был сайт для дальнобойщиков в 2004 году. Там был только HTML, даже без CSS, верстал таблицами и inline-стили. Все было выполнено в серых цветах, строго по шаблону: слева ссылки, сверху шапка, в футере копирайт «made by Roman Sachenko». Я тогда получил вроде бы 5$ или 10$ за эту работу. После сделал еще пару сайтов, а потом надоело. Хоть я и осознавал, что программирование было чем-то большим, чем просто HTML, но поскольку на тот момент были более интересные развлечения, ушел от этого.

С чего ты начинаешь рабочий день?
В основном, либо чтение статей, либо Twitter. Честно говоря, только недавно начал им пользоваться, но очень полюбил. Ты подписываешься конкретно на то, что тебе интересно, а не на своих знакомых/друзей, которые обижаются, если ты на них не подписываешься.
Как минимум раз в неделю я захожу в LinkedIn и отписываюсь людям, чтобы не игнорировать. Иногда это шаблонные ответы, иногда сам пишу. На это тоже уходит время - 30-40 минут, как правило.
А бывают такие дни, что ты сразу запрыгиваешь в работу, открываешь JIRA, смотришь задачи, распределяешь на себя и на команду.

Какое у тебя расписание дня?
Стараюсь всегда выписывать цели на день. Первый час уходит на вышеописанные вещи: чтение, самообразование, шутки. И потом начинаю идти по целям, но я не делаю step-by-step. К примеру, цели к концу дня - закончить задачу, провести code-review и ответить людям по поводу конференций. Нет четкой последовательности, потому что работаю на двух проектах и не хочу быть bus-фактором, когда моя занятость блокирует других людей. Так что, надо быть гибким, чтобы отвечать людям. Ставлю около пяти задач, так как это оптимальное количество для меня.
И в конце дня делаю анализ по целям, чтобы понять что успел/не успел и почему.

«Вот работаем с JavaScript-ом, и сколько у нас непонятных библиотек в зависимостях?»

Возможно ли взломать веб-приложение без социальной инженерии?
Да, конечно. Если подразумевать под взломом получение доступа к базе данных, повреждение файлов или банальное «положить» сервер, такое возможно. Причем часто это возможно в каких-то стартапах, когда делается быстро и допускаются базовые ошибки безопасности. Например, SQL-инъекции - проблеме больше 20 лет и до сих пор вопрос поднимается. До сих пор есть вопрос валидации форм на бекенде. Меня недавно спросили: «Зачем нужно валидировать на бекенде, если есть валидация на фронте?». В таких случаях необходимо объяснять, что можно сделать запрос через консоль или Postman. Возможно, твое приложение не является целевым для взлома, но такие моменты важно закрывать. Мало ли, кому придет в голову нагадить просто так. Вот работаем с JavaScript-ом, и сколько у нас непонятных библиотек в зависимостях? Был случай, когда один заказчик купил тему, и в рамках темы в package.json прикручивалась либа через гитхаб ссылку. Спустя немного времени у нас упал продакшн. Я захожу на эту ссылку, а там - «404». Оказалось, владельцы библиотеки просто удалили ее или перенесли в другое место.
В старых версиях Node.js много проблем с тем же буфером, утечками памяти. Как видим, даже в самой технологии у нас уже есть ошибки. Еще на некоторых ресурсах пароль генерируется, используя стандартную функцию Random. Кто-то использует сложные алгоритмы рандома, а кто-то - Math.random. А он, как известно, работает по таблице. Зная такие вещи, можно взломать приложения. Работаю над тем, чтобы сделать чек-лист перед выпуском в продакшн, тогда будет гораздо меньше уязвимостей.

Как ты оцениваешь задачи?
Только интуитивно. До этого на проектах мы использовали оценку в часах. Если это было что-то незнакомое, я умножал на 1.5. Естественно, оценка проходит через менеджера и там еще умножается на 1.2. А сейчас мы работаем по стори поинтам (Story points - Scrum). Совсем новый для меня опыт, и он требует изменения мышления. Важно не продолжать приравнивать стори поинты к часам, потому что получится то же, что и раньше, только с другим названием и дополнительной конвертацией часов в стори поинты.

Кто в твоей картине мира Trainee/Junior/Middle/Senior?
Давай тогда по каждому:

  • Trainee - это человек, который не умеет ничего. Возможно даже, у него за плечами университет, но у него нет коммерческого опыта. Он может написать скрипт, но он не знает, куда его прикрутить. Человек, которого нужно обучать и показывать, как решать задачи реального мира. Этот человек не работает на проекте, он учится. Например, Trainee не знает, как работает HTTP: что он в себя включает, что такое хедеры. Но при этом его можно обучить.
  • Junior - человек, который может выполнять реальные боевые задачи, но получает он их от тимлида или менеджера. Ему необходимо объяснить, как делать. Ты не можешь сказать: «Надо сделать аутентификацию - делай». Ты объясняешь ему алгоритм: сначала делаешь валидацию данных, потом создаешь хеш от пароля, потом пишешь в базу. И только после объяснения он делает.
  • Middle - это человек, который прошел несколько проектов от начала до конца. Проекты, которые вышли в продакшн, прошли саппорт и вышли в стабильную фазу. Он уже может участвовать в принятии архитектурных решений. На него можно выделить задачу, и он с ней справится. Еще мидл умеет делиться опытом. Джуна, возможно, еще не научит, но уже может рассказать ему, как он делал и показать решение. Мидл знает, как делать, но не знает почему именно так надо.
  • Senior - человек, который строит архитектуру. Когда заходит новый проект, синьор - это первый человек, который смотрит на то, как его сделать. Он может понять, сколько ему нужно людей для этого. Очень важно понимать, что эти «лычки» даются не только за знания и умения, но еще и в целом за предоставление сервиса клиенту. Чем звание твое выше, тем лучше ты должен понимать бизнес и уметь находить решения в условиях небольших бюджетов. Если у клиента нет большого бюджета, то, соответственно, нужно убрать какой-то функционал. Важно видеть в проекте основные и второстепенные вещи. Возможно, еще синьор участвует в пресейлах (pre-sale), но это зависит от компании.

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

«В IT меня привел интерес к автоматизации своей работы. Под программированием вижу автоматизацию бизнеса, чем оно, по сути, и является»

3 фактора, которые тебя привели тебя туда, где ты есть
Бросил универ, пошел в армию, начал употреблять алкоголь. В процессе одной из угарных посиделок я пересекся с парнем, который на тот момент работал в IT, сказал, что в компанию требуются люди. Так я устроился в техническую поддержку одного хостинга и начал писать первый код. В определенный момент ты понимаешь, что делаешь похожую работу и задумываешься об автоматизации задач. На тот момент у нас уже были люди, которые писали для себя скрипты, чтобы поправить htaccess, сгенерировать cgi-bin папку, переустановить Wordpress или письмо отправить. Меня это заинтересовало, потому что не одним и тем же занимаешься, а что-то изобретаешь. Я решил пойти в «ШАГ», его потом тоже бросил, но задачи, которые давали там, было интересно делать above and beyond - больше, чем требовали. Подумал тогда: «Зачем мне этим саппортом заниматься? Хочу в программирование!» Бросил «ШАГ», дома немного позанимался. Потом прошел на «Сode academy» курс по JavaScript. В тот момент понимал синтаксис и пришел к выводу, что надо устраиваться на работу. А в то время жил в Запорожье и нашел компании, которые нуждались в PHP либо Ruby-разработчиках. Потому, прошел базовые курсы, чтобы понимать синтаксис Ruby, и отправил резюме на Work.ua в одну из харьковских компаний. Честно сказал им, что ничего не знаю, но готов учиться.
В IT меня привел интерес к автоматизации своей работы. Под программированием вижу автоматизацию бизнеса, чем оно, по сути, и является.

Почему ты выступаешь на конференциях?
Интересно делиться знаниями. Причем всякими: научился писать код быстро - я поделюсь этим. Сделал какую-то вещь сложную для себя - поделюсь этим. Мне нравится рассказывать такие вещи людям. Причем они вроде бы меня слушают. Либо, потому что я надоедливый, либо, потому что интересно рассказываю. В любом случае, они меня слушают и задают вопросы.

Расскажи про первое выступление?
Начинал с выступлений в компании. Первый мой доклад был про Firebase. Это был доклад в стиле «3 недели поработал с технологией и рассказываешь про нее». Были штуки, которые мне в Firebase не нравились, и вместо того, чтобы написать куда-то фидбек, я решил сделать доклад, - и мне понравилось. А первое публичное выступление - «DevChallenge 11», 27 мая 2017. Выбрал тему «Security in Node.js», также захватил в доклад SQL-инъекции и все такое. Людей пришло больше, чем ожидал. Даже вопросы задавали, и я понял, что буду и дальше выступать.

«Когда ты говоришь наедине, - ты говоришь свободно, а как только ты выходишь на сцену, - ты как-будто забываешь половину слов из русского языка»

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

Функциональное или объектно-ориентированное программирование?
Не являюсь адептом ни того, ни другого, - все по ситуации. Оба подхода - это инструменты и важно знать, где что применять. К примеру, если в проекте есть роли и четкие сущности, - буду писать в ООП стиле, чтобы новому человеку было понятно, где что смотреть. А если это микросервисы, то проще писать в функциональном стиле.

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

Спустя сколько времени новый человек начинает приносить пользу на проекте?
Все зависит от опыта человека. Если позиция Junior и ему нужно объяснить, что и как работает - это занимает один-два месяца. А если уже более опытный человек, то нескольких недель достаточно, чтобы разобраться, вникнуть и полноценно «педалить» в большом проекте. Все же, еще зависит от размера проекта, документации и наличия человека, который может ответить на вопросы. Поэтому важно писать по паттернам, чтобы человек тратил меньше времени, разбираясь с архитектурой.

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

«В жизни ты никому ничего не должен и можешь делать все, что хочешь, только не мешай другим»

Девиз по жизни
«Уважай свой стол, сон, друзей, безопасность и справедливость». По поводу стола - отдельная история, касающаяся того, что нельзя ставить чашки на стол без специальной подставки. А вот справедливость - особенный пункт у меня в голове. Формировать свое отношение к людям необходимо справедливо и без предвзятости. Также справедливо необходимо общаться с людьми и оценивать их идеи и действия.
Особенно важно - справедливо принимать свои фейлы и, конечно же, «во имя справедливости» принимать решения, включая факторы, которые важны в данный момент, а не твое личное отношение.
А если хочется «похолливарить», то придерживаюсь позиции, - что в жизни ты никому ничего не должен и можешь делать все, что хочешь, только не мешай другим.

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

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

Что думаешь про постановку целей?
Надо успеть все. Я не знаю, что нужно успеть, но знаю, что пока ты живешь, нужно точечно получать удовольствие. Тоже недавно спорили и вопрос был о том, что если умрешь через месяц, то как изменится твоя жизнь. Да никак не изменится, я стараюсь получать удовольствие от жизни сейчас. Я думаю, что у постановки целей до 45, есть две стороны: ты можешь достичь и порадоваться этому достижению, но, вероятно, необходимо будет делать то, что не хочешь. И тогда вопрос: стоят ли усилия того?

«Hard skills - это твой технический фундамент»

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

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

Как прокачивать soft skills?
А вот здесь нужна помощь. Необходимо определить, для чего именно софт скиллы. Потому что для рядового разработчика достаточно одного уровня, а для тимлида/СТО - другой. Нужно найти человека, у которого софт скиллы на первом месте (например, у менеджеров), и проконсультироваться по этому вопросу. На некоторых проектах я являюсь тимлидом. И во время работы над очередным таким проектом поймал себя на мысли, что я самостоятельно делаю большинство задач, а остальное распределяю на команду. И вот это неправильная установка - подсознательно ты либо не доверяешь команде, либо геройствуешь и пытаешься вынести все сам. Но такой подход неверный, и это уже касается софт скиллов. Сейчас я практикую другой подход: сначала распределяю задачи на команду и потом на себя.

«Хочется чувствовать себя командой не только здесь - с теми, кого ты видишь, но и с клиентом»

Опиши сотрудника, с которым тебе хотелось бы работать:
С собой я бы точно не работал :) Мне нравится, когда люди в команде предлагают решения, нравится, когда люди заботятся о клиенте и знают, почему он именно так захотел; люди, понимающие целевую аудиторию клиента, интересующиеся планами клиента, потому что эти вопросы влияют на архитектуру проекта. Хочется чувствовать себя командой не только здесь - с теми, кого ты видишь, но и с клиентом. Естественно, вы никогда не будете единым целым, потому что он выпустит продукт, а ты перейдешь на другой проект. Но пока мы совместно работаем над проектом, мы - команда. С подобными людьми интересно работать

Важно ли заниматься Open Sourсe?
Для себя не вижу этого пути, но, безусловно, это важно потому, что мы в JS работаем в основном с open sourсe технологиями: Angular, Node.js. Такие люди двигают коммьюнити и развивают его.

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

Какой у тебя челлендж на данный момент?
Обогнать себя. Я попал в эту сферу довольно поздно - в 25. И ввиду этого, когда приходит кто-то моложе меня (а у человека больше опыта), ты думаешь: «Как это так получается?». Причем многие знают и умеют больше, чем ты. И ты начинаешь соревноваться, потом, конечно, понимаешь, что всех не обгонишь. Начинаешь соревноваться с собой, чтобы прогнать лень. Понял, что за 3,5 года у меня немало опыта, но важно не сбавлять темп. И пусть я буду знать меньше, чем кто-то сегодня, но больше, чем я вчера. Главное - не подводить себя.

«Не стоит делать доклад ради доклада и нужно говорить о том, о чем было бы интересно послушать тебе»

Напутственное слово людям, которые хотят научиться выступать публично
Оценивая свой опыт и свои «косяки», могу сказать, что не стоит выступать ради того, чтобы просто засветиться. Тема должна быть той, которую ты хотел бы услышать сам. Не заучивай слайды - пусть слайды будут сопровождением. Рассказывай доклад, как-будто ты с ребятами на кухне, обязательно нужно общаться с публикой и смотреть на реакцию. Если ты видишь, что они скучают, нужно добавить интерактива, и после - сделать вывод, почему получилось скучно. Резюмируя, могу добавить: не стоит делать доклад ради доклада и нужно говорить о том, о чем было бы интересно послушать тебе.