Сергей Важенин о рабочем процессе, наставничестве и честности

Сергей Важенин в команде «Метеора» 5 лет. За это время он поучаствовал в ключевых проектах компании, включая нашу собственную ERP и стал наставником для начинающих разработчиков. Что интересного было за эти 5 лет, зачем нужна стажировка и где искать честность в коде — в этом интервью.

Где ты учился?

Окончил Новосибирский колледж электроники и вычислительной техники по специальности «Вычислительные машины, комплексы, системы и сети». После — поступил в СибГУТИ на «Программное обеспечение средств вычислительной техники и автоматизированных систем».

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

К окончанию учебы я уже решил, что буду развиваться в веб-разработке и поэтому вторая специальность — ПО.

Как ты пришел в «Метеор»?

Первый рабочий день состоялся 4 июня 2013 года. 31 мая я прошел собеседование, а 3 июня ребята заценили мое тестовое задание и пригласили на работу. На тот момент мой опыт ограничивался проектами «для себя». Тем не менее, уже тогда я понимал, каким будет будущее место работы, и вакансии отбирал по отсутствию привязки к популярным CMS, и по уклону в сторону backend.

Что ты ценишь в «Метеоре»?

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

В работе я ценю разнообразие проектов, как по их сути, так и по технической сложности и уклону в сторону backend или frontend. В моем представлении работать годами над одним и тем же проектом — та еще безысходность.

Ценю, что здесь если нормально работаешь, то к тебе никто не лезет, не капает на мозги, не задает глупых вопросов. Сам решаешь, когда принести свое бренное тело на работу, какую задачу сделать вперед... Главное — итоговый результат. А еще я очень люблю наш фреймворк, да.

Чем он хорош?

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

Что для тебя «интересный проект»?

Это проект:

  1. Смысл и оправданность существования которого я в состоянии понять.
  2. В котором остальные участники процесса понимают, что и зачем они делают, как это будет работать и готовы идти на компромисс между желаемым и необходимым для технической надежности, простоты, расширяемости.
  3. В котором, как ни странно, я имею шанс проявить себя с лучшей стороны — сделать быстро, качественно, надежно.

Расскажи об интересных проектах из реализованных?

Чисто в плане сути проекта можно назвать «Maze» — легко встраиваемый сервис для интернет-магазинов, дающий покупателям скидку за пост в социальной сети о покупке. Нажимаешь пару кнопок, на стене появляется пост, а в магазине тебя уже ждет скидка. А если сделать репост чужой такой записи, то дается еще скидка. Идея — 10 из 10, жаль, что проект не дожил до релиза.

А еще там в админке реализованы графики по статистике о количестве постов, популярных товарах, возрасте и географическом положении покупателей.

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

Сейчас ты проводишь стажировку. Расскажи немного об этом: как оно, что сложно, что интересно, зачем вообще?

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

Два месяца стажировки — достаточное время, чтобы разглядеть в человеке неспособность к работе. А в позитивном случае — показать нашу CMS, научить писать код аккуратно и продуманно, и подвести человека к работе над «боевыми» проектами уже более-менее подготовленным.

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

Самое сложное в этом процессе — начать взаимодействие с незнакомым человеком и объяснить те вещи, которые за годы работы для меня стали супер-очевидными. Самое интересное — когда твое «детище» делает что-то самостоятельно, да это что-то еще и работает. Прям как растить ребенка и наблюдать за его первыми шагами. :)

Миссия «Метеора» звучит как стремление делать больше интересных проектов и оставаться честными. Что это значит для тебя?

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

В моем понимании сделать что-то плохо и, зная это, оставить так — нечестно по отношению к проекту.

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

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

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

Новый комментарий