Іван, Lead Software Engineer в TeamVoy. Іван є учасником програмного комітету LvivCSS, активіст львівського коммюніті, любить ходити в гори.

https://www.facebook.com/ivan.lavriv
https://www.linkedin.com/in/ivan-lavriv-a31645170/

Про свій перший досвід в IT
Це був інтернет-магазин для одного мого знайомого ще на моєму першому курсі навчання. Отримав за нього 680 грн. Хоча досвід і був у 2009-2010 рр., добре пам’ятаю. Написано було дуже криво на PHP, зараз, мабуть, вже сайт не працює, але певний час точно працював. З некомерційного досвіду згадую ще в школі олімпіаду, де я програмував на Pascal, задачки розв’язував.

Чому ти обрав IT, це був свідомий вибір?
Якось так сталося, що спочатку в школі подобалися гуманітарні науки: історія та географія. Але вчителька з інформатики змогла пробудити зацікавленість до програмування. Потім в університет я вступив на факультет електроніки та паралельно щось пробував кодити. А на другому десь курсі вже пішов працювати.

Що входить у твої обов’язки як Tech Lead?
Code review, управління тасками, вирішення різноманітних питань між клієнтом та командою, менторю команди. В мене три команди: 2, 5 і 3 відповідно людей.

Про організацію свого робочого часу:
Намагаюся в першій половині дня більше кодити, менеджерську частину виконую у другій половині дня. А взагалі, можу й міняти місцями порядок виконання — але найскладнішу роботу виконую, фокусуючись та виділяючи якусь чітку половину дня.

«В моїх командах спеціаліст проходить «драбину» доступу до інфраструктури: через умовних півроку може бути доступ до деплою, через ще деякий час — до code review»

Що для тебе означає поняття «Full Stack» спеціаліст?
Це для мене спеціаліст повного циклу розробки: від того, щоб написати front-end, до версії продукту, коли він повністю готовий для користувача. Тобто, такий розробник може й кнопку намалювати і DevOps задачі виконати.
Це не залежить від років досвіду, звісно, а від фактичного досвіду. Наприклад, в моїх командах спеціаліст проходить «драбину» доступу до інфраструктури: через умовних півроку може бути доступ до деплою, через ще деякий час — до code review.

«Якщо людина досвідчена, то вона одразу має свободу в команді»

Розкажи про ці підходи у твоїх командах детальніше:
Якщо людина досвідчена, то вона одразу має свободу в команді. Але якщо в команді є новачки, то вони перший місяць проходять жорсткий code review, без мене нічого не мержиться. Наступним етапом може бути, що вони один одному перевіряють код та ставлять один одному апрув, а мержу все одно я. Потім вони зможуть вже самі деплоїти те, що замержили. Таким чином намагаюсь мотивувати, щоб всі розуміли, як працює наша інфраструктура.

«При вивченні нової технології намагаюся одразу спробувати її на практиці»

Який, з твоєї точки зору, повинен бути підхід до вивчення нових технологій?
Перш за все, починаю писати на цій технології, щоб її одразу спробувати на практиці. Опускаю в такому разі бест практики і якісь вузькі ідіоматичні речі, тут важливо помацати все. Можу не все одразу розуміти, але це дає мені можливість водночас порівнювати ці знання з тими, що маю, та сприймати швидше інформацію. Потім вже поглиблено вивчаю тему через документацію, статті та тому подібне.

«Треба було приділяти більше уваги якості коду»

Чи можеш ти поділитися, так би мовити, твоєю fail-story, з якої ти здобув урок?
Був у свій час фронтенд лідом, команда писала доволі велику систему для бухгалтерського обліку на AngularJS. Це був мій перший такого роду досвід. В моїй команді були люди, які працювали у Львові, а деякі — на Шрі-Ланці. Зараз розумію, що забагато витрачав часу на менторінг команди, та мало уваги приділяв архітектурі проекту. У результаті проект завалився. Треба було приділяти більше уваги якості коду.

Що для тебе якісний код?
Можу виділити наступні моменти:

  • Код має бути читабельним.
  • Мати не дуже великі структурні одиниці (класи, функції). В мене в команді, наприклад, правило, щоб клас не мав понад сто ліній коду.
  • Далі, це доменність, не зовсім DDD (Прим. Domain-Driven Design), але завжди можна внести елементи, які структурують твою аплікацію відносно твого домену. Так тоді буде простіше підтримувати спільну мову між менеджментом та командою, тому що завжди буде спільна доменна мова.
  • Спільний код. У своїй команді ми такий виносимо в окремі модулі, які використовуємо на різних проектах.
  • Уніфікація.
  • Можливість автоматизувати те, що ти робиш. Щоб не робити зайву роботу і концентруватися на бізнес задачах більше, ніж на інфраструктурних та тому подібне.

«Найголовніше — це розуміти, що у людей поряд є не тільки робота»

Як ти вирішуєш конфлікти в команді?
Коли формую команду, намагаюся на співбесіди залучати інших учасників, щоб рішення було більш колективним та уникнути прийняття на роботу людей, що не підходять. Якщо вже і виникнув конфлікт, витягую учасників на особисті розмови, щоб розібрати ситуацію та пояснити, якщо хтось неправий або допомогти. І для ліда найголовніше — це розуміти, що у людей поряд є не тільки робота, потрібно прислухатися до них. Те, що в них є поза роботою, може як раз і впливати на те, як вони її виконують.

Які твої поради тим, хто намагається знайти свою першу роботу в IT?
Пишіть код. Особисто я, виділяю людей, які вже мають pet-projects, ніж просто володіють теорією і хочуть знайти роботу. Також віддаю перевагу тим кандидатам, які володіють загальними знаннями більш глибоко, ніж вивчили лише одну технологію. Тому що, підтягнути по другому питанню набагато легше, ніж пояснювати фундаментальні речі, яких іноді забагато. До мідлів, звісно, трішки інші підходи.

«У мідлів намагаюся з’ясувати особистий вплив на проект, виявити проблеми, які були вирішені саме ними»

Що запитуєш на співбесідах зі спеціалістами рівня Middle?
Універсальним залишається те, що я цікавлюсь їх загальними знаннями. Та, окрім технічної частини, запитую стосовно їх персонального досвіду по проектах, в яких вони брали участь. Намагаюся з’ясувати особистий вплив на проект, виявити проблеми, які були вирішені саме ними. Бо, на жаль, бувають випадки, коли люди працюють в компаніях, де посади номінальні та зовсім не означають досвід.

«Вважаю, що коли ти зовсім занурюєшся в роботу, — це, по суті, егоїзм»

Які три книжки ти можеш виділити, що мали вплив на тебе?
Можу виділити точно дві наразі:
«Clean Code» Роберта Мартіна та
«Программист-прагматик. Путь от подмастерья к мастеру» від Енді Ханта та Дейва Томаса. Цю книгу я рекомендую, оскільки в нашій професії люди часто забувають, що є щось ще, окрім роботи. Треба мати баланс між роботою та особистим життям. Вважаю, що коли ти зовсім занурюєшся в роботу, — це, по суті, егоїзм.

Як учасник програмного комітету, які ознаки цікавої доповіді для конференції ти можеш виділити?
Можна відокремити ключові моменти, які мають бути обов’язково в доповіді: це проблема, демонстрація декількох її рішень, твоє рішення проблеми, розв’язання проблеми, про яке ви ще не чули. Ще це може бути яскраве захоплення якоюсь конкретною технологію, де людина багато чого досягла та хоче її «продати». Або щось, над чим працює на проекті і можна поділитися з аудиторією, і цього ще ніхто досі не пробував. Тобто можливостей зробити свою доповідь цікавою багато.

«Беручи щось корисне зі спільноти (а я багато беру), намагаюсь також і повернути»

Яка твоя мотивація виступати на конференціях?
В якійсь мірі роблю собі ім’я. Це також для мене певний альтруїзм. Тобто, беручи щось корисне зі спільноти (а я багато беру), намагаюсь також і повернути. І це знайомства, дуже багато класних людей я зустрів, виступаючи на конференціях.