Хочеш дізнатися, як отримати роботу? Бери участь у Career Bootcamp

час читання: 6 хв

«Лінь — моя суперсила»: 5 якостей ідеального Software Engineer

Що робити, щоб тебе не замінили роботи? Чому важливо бути допитливим, але не закопуватись? Навіщо пробувати та помилятися, але думати, що робиш? Software Engineer Віталій Вишневський ділиться неоціненним досвідом та своїм знанням про Engineering Culture.

Software Engineer Віталій Вишневський

— Я — Software Engineer до нутра кісток, — представляється Віталій, — В професії вже майже 23 роки. Більшість часу працював інженером, а останні п'ять років — Delivery Manager і Product Owner. Зараз разом із колегами ми створюємо продукт у межах ініціативи EngX. Продовжую програмувати, пишу код.

Хто такий Software Engineer

— Хто такий Software Engineer сьогодні? Це той, хто займається інженерною діяльністю в нашій галузі, а саме створенням та підтримкою функціонування програмного забезпечення. Бізнес-аналітики, розробники, тестувальники, DevOps — усі, кого ви можете побачити на командному мітингу, всі Software Engineers з різною спеціалізацією, — розповідає Віталій, — У сучасного інженера має бути розвинене водночас інженерне мислення (Engineering Thinking) та agile-мислення (Agile Thinking). Ми працюємо з технологіями, що швидко змінюються, складними бізнес-процесами і різноманітними способами взаємодії, тому agile-мислення потрібне нам для того, щоб бути ефективними в роботі, а інженерне — щоб бути результативними.

Є два терміни, які, на мою думку, багато хто неправильно перекладає і сприймає. Це Agile та Full Stack Developer.

Agile

— Насправді Agile перекладається як «спритний», а не «гнучкий» (Flexible). Agile — це про адаптацію до зовнішніх і внутрішніх умов, що постійно змінюються. Я можу уявити ментальну помилку перекладача, який переклав Agile Methodology як Гнучка Методологія. Слово «гнучкий» асоціюється зі зміною форми та податливістю, тобто з адаптацією через зміну свого внутрішнього стану під впливом зовнішніх умов. У той час як слово «спритний» асоціюється зі швидкістю та напрямом руху, з адаптацією через реакцію на зовнішні умови, через зміну швидкості та напрямку свого руху. І слово «спритний» набагато більше відповідає поняттю Agile і тому, що від нього чекає бізнес. Нам, інженерам, не потрібно викручуватися і прогинатися лише з тією метою, щоб рухатися вперед, як було заплановано місяць чи роки тому. Наше завдання бути зібраними та готовими у будь-який момент змінити напрямок та швидкість руху, щоб відповідати новим вимогам ринку, де працює наше програмне забезпечення. А це означає, що у нас не повинно бути зайвого «жиру та хвостів», що заважали б нам бути спритними. Я маю на увазі технічний борг, погану якість коду, відсутність юніт-тестів тощо.

Full-Stack Developer

— А ось Full-Stack Developer'ом у нас прийнято вважати розробника, який може і Back-End, і Front-End. Замовники ж Full-Stack розуміють це як повний цикл розробки: від збору вимог до релізу. Тобто розробник повинен знати та вміти:

  • Збирати та прояснювати вимоги, брати активну участь у цьому процесі, взаємодіяти з бізнес-аналітиком;
  • Взаємодіяти з UX-дизайнером, щоб розуміти UX та реалізувати його відповідно до задуму;
  • Розбиратися в архітектурі застосунка та дотримуватися код-стандартів, що було закладено архітектором;
  • Писати та рев'юїти код, щоб він відповідав архітектурі та стандартам якості, прийнятим на проєкті, працювати в парах з іншими розробниками, щоб знизити кількість помилок, а відповідно і загальний час розробки програми;
  • Тестувати свій код і те, як він інтегрується в додаток, створювати юніт та автотести, активно взаємодіяти з командою тестування;
  • Створювати білд-скрипти та взаємодіяти з DevOps під час розгортання додатка.я

— Робота Software Engineer зроблена тоді, коли додаток потрапить у продакшн, буде працювати без помилок і принесе користь кінцевому споживачеві. Full-Stack Developer — це Software Engineer, який робить все від початку та до кінця — від вимог до постачання. Він бере участь у всіх етапах процесу створення програмного забезпечення, — підсумовує Віталій.

Так, наприклад, розробник, який створює свій pet-проєкт, зазвичай робить все сам: від збору вимог до розгортання/постачання продукту. Просто у великих компаніях та великих проєктах ці функції виконує не одна людина, а різні інженери з різними спеціалізаціями. Але розбиратися та брати участь у всіх сферах виробництва кінцевого продукту треба обов'язково.

Дізнайся більше про спеціалізації

Якими якостями має володіти Software Engineer

— Ми в ініціативі EngX (Engineering Excellence) довго думали, які якості має мати ідеальний Software Engineer і дійшли наступних висновків.

Інженери мають:

  1. Бути допитливими.
    Це означає дивитися на світ навколо себе, не замикатися, не залишатися в якомусь обмеженому потоці, цікавитися, брати участь у різних активностях крім проєкту, ходити на різні хакатони, мітапи з нових технологій. Хакатони в цьому випадку краще, на них можна попрактикуватися в написанні коду.
  2. Мати почуття міри.
    Допитлива людина може зациклитися на абстрактних речах і заглибитись у надмірне покращення. Інженеру дуже важливо не абстрагуватися від продукту та зовнішнього світу. Потрібно думати про користувачів, про те, який у результаті продукт виходить і коли вони його отримають. Не всі завдання можна зробити абстрактно, та й не потрібно. Професія розробника — це не просто писати код та давати тестувальникам роботу. Турбота про результат, усвідомлення свого внеску в світ — ось якими принципами має керуватися інженер. Інженер взаємодіє з рештою команди, щоб його зміни були інтегровані в загальну систему і працювали як слід, були вчасними.
    Щоб вони були вчасними — означає робити усе необхідне, аби задовольнити вимогу, і щоб решта учасників команди теж встигли виконати свою роботу. Але не забуваємо про якість коду, яка дуже сильно впливає на майбутню «вчасну» розробку. І раннє виявлення багів: що раніше ми виявимо проблему, то менше часу на її вирішення буде витрачено; уважно читаємо специфікацію та вказуємо на помилки в ній.
  3. Вміти працювати у команді.
    Джуніори часто не можуть потрапити на роботу у великі компанії саме тому, що вони не мають досвіду роботи в команді. У таких компаніях ніхто не працює поодинці, все робиться командою. І найсумніше, що більшість онлайн-курсів та менторських програм не надають такого досвіду. Здебільшого вони спрямовані на індивідуальну роботу, індивідуальне вивчення матеріалу та індивідуальну практику в написанні коду. Знань про те, як зібрати вимоги, як зробити дизайн додатка, як його протестувати, як його встановити на сервер або якимось іншим чином створити дистрибутив — не дають. А цього не вистачає, і це треба десь брати. Звичайно, фахівців можна навчати, але навчання ускладнюється тим, що неминуче буде багато помилок, проєкт може затягнутися, а це ризики. Плюс потрібно знайти людину, яка розповідатиме і показуватиме, як правильно робити, а це ресурс. Добре, якщо така людина є. Тоді джуніори і навіть мідли досить швидко вливаються в роботу і починають справлятися. Але найчастіше це не так.
    У мене в EPAM був досвід створення project-лабораторії, в межах якої я зібрав студентів-джуніорів у дві команди, і ми робили два невеликі проєкти. Я виступав у ролі Product Owner та ментора, навчав їх як команду, де є повний цикл розробки. Я показав їм, що робота над проєктом не пов'язана просто з написанням коду, а пов'язана з багатьма речами: опрацюванням вимог, тестуванням, розгортанням. Після трьох місяців роботи над проєктами хлопці сказали, що здобули хороший досвід і у них залишилося розуміння, як їм працювати в команді.
  4. Бути лінивим.
    Ви, напевно, чули вираз «Лінь — двигун прогресу». Це саме так. Я називаю її своєю суперсилою. Це, звичайно, не означає, що я нічого не роблю. Лінь має бути такою, щоб, докладаючи мінімуму зусиль, отримувати максимальний результат. Наприклад, є якась рутинна дія. Ок, я її зроблю один раз, але наступного разу я придумаю якийсь простий спосіб, щоб ця дія у мене забирала менше часу та сил. Якщо робити все щоразу в лоба — коли тобі дали завдання, ти одразу пішов його робити — це недобре. Потрібно подумати, «полінуватися» робити одразу, знайти просте гарне рішення, яке принесе більше користі та займе менше часу та зусиль. Загалом інженер має більше думати — менше робити.
  5. І не «тупити».
    Ця характеристика трохи конфліктує із попередньою властивістю. На заході є такий вираз fast try — fast fail. Це означає, що краще швидше спробувати щось зробити, переконатися, що це не працює, і відмовитися від плану. Нам складно це прийняти. Нас вчили не помилятися. Але насправді помилятися нормально, на помилках люди вчаться. Якщо боятися помилятися, то ми довго думатимемо, вивірятимемо і все одно не уникнемо падіння.

— У хорошому інженері мають бути якості, які суперечать одна одній. Бути захопленим своєю справою і знати міру, бути лінивим і не «тупити». Але важливо знаходити баланс між ними та правильно їх використовувати. Не потрібно все відразу робити в лоб, найпряміший шлях не завжди найшвидший, можна вигоріти від непосильних зусиль. Але без помилок не набиратимешся досвіду, який так потрібен, — резюмує Віталій.

Звісно, не слід забувати і про soft skills. Вони потрібні всім людям на будь-яких посадах. Джуніорам — для успішної роботи в команді, зрілішим фахівцям їх потрібно розвивати, щоб далі рухатися кар'єрними сходами.

Що почитати

— І наостанок залишу список із чотирьох книг хорошого інженера:

Хочеш поговорити про інженерну культуру? Запрошуємо в Discord Anywhere Club.

Го в Discord