У блозі публікуємо колонку з DOU, яку готував Іван Довгаль, Technical Lead в компанії Innovecs. За 10 років у програмуванні він отримав досвід у сфері розробки коду, управлінні командою й проведенні технічних інтерв’ю. У матеріалі йдеться про важливі якості досвідченого програміста — яким повинен бути його майндсет, особисті та професійні якості.
Стаття буде корисною інженерам-початківцям і тим, хто хоче розвиватися у напрямку Engineering Leadership, прагне росту і переходу на вищий рівень. Кандидатам буде цікаво дізнатися, чого від них очікують на технічних співбесідах і за якими критеріями відбувається «відбір» найкращих.
⚫ Про «живий мозок» програміста або Базовий набір навичок досвідченого розробника
Є різні підходи до визначення необхідного набору навичок програміста. Вимоги відрізняються залежно від компанії, проєкту й команди, з якою працюєш. Найбільш поширене визначення, яке мені імпонує: «Досвідчений» — той, хто не лише знає теорію, але успішно працює з реальними практичними завданнями, знає і вміє знаходити рішення нестандартних задач.
Мабуть, усіх досвідчених програмістів об’єднує одна важлива риса — вміння шукати потрібну інформацію. Є ще кілька важливих якостей — це любов до програмування і бажання працювати. Якщо у людини не буде бажання працювати, то навіть значний досвід і талант можна закреслити. У роботі перетинався з тими, хто добре володів технологіями, але зовсім не хотів працювати.
Для програміста базовими навичками є хороша пам’ять, вміння концентруватися, вміння вивчати нові технології й логічне мислення. А якщо коротко, то у досвідченого програміста має бути «живий мозок», який добре працює. Без цього не підеш далі. Це саме ті важливі якості, за якими ще з дитинства можна визначити твою схильність до програмування як до майбутньої професії.
Решта ознак, які описуватиму, можна поділити умовно на дві категорії — технічні знання та персональні риси. Якщо технічні знання можна здобувати на різних тренінгах, курсах й відточити на практиці, то персональні якості (або soft skills) не так легко здобуваються, якщо не є природними для людини. У будь-якому випадку досвідчені програмісти проходять свій шлях й багато чого вчаться у цих двох напрямах.
Зрозуміло, що досвідчений програміст добре володіє технологією або кількома, з якими працює. В ідеалі він знає кілька фреймворків. Але перш ніж освоювати певну технологію, програміст здобуває знання з базової архітектури систем і мереж, структури даних і алгоритмів, системного адміністрування, вивчає загалом Computer Science. Таким шляхом йдуть і сисадміни, і DevOps. Якщо йдеться про програмування як таке, то тут важливо розуміти структури даних та алгоритми, абстракції технологій, принципи OОП.
Після вивчення певної мови програміст переходить до вивчення фреймворків й бібліотек. Це вже більш високі абстракції, які об’єднують менші. Якщо ви Frontend-розробник, то йдеться про React, Angular, Vue.
🔴 Глибоке розуміння технологій і вміння знайти найкращий підхід
Досвідченому програмісту варто знати кілька технологій й використовувати найкращі підходи. Це не поверхові знання, а відточені на практиці. Системний підхід дозволяє бачити проєкт згори, розуміти його цілісно, а не частково, відповідно тоді й обирати найкращий підхід до розробки. Іноді в розробці плутають поняття продуктивності роботи й ефективності. Можна швидко завершити роботу над проєктом, але допустити багато помилок, і на дебагінг піде більше часу, аніж на ретельний покроковий процес розробки.
Швидкість роботи — це не завжди ознака кваліфікації Senior Engineer. Натомість робота на результат — це його невід’ємна якість. Ефективність дій, рухів важить більше, ніж кількість рядків коду і швидкість. Знайти підхід до розробки проєкту, при якому якість і швидкість у балансі під силу саме досвідченому інженеру.
🔴 Вміння враховувати «користувацький досвід»
Хороша звичка програміста — зважати на користувацький досвід, тобто під час розробки думати про те, як виглядатиме програма з точку зору користувача, чи буде вона зручною і зрозумілою.
Необов’язково бути дизайнером, щоб передбачити, як працюватиме фіча. Ще буде корисно освоїти тестування свого коду, щоб уникати помилок у процесі розробки.
🔴 Слідування технічному процесу
Слідування технічному процесу можна назвати хорошою звичкою будь-якого програміста, а тим більше досвідченого. Це важливий нюанс. Перш ніж змінити перемінну чи функцію, треба перевірити, де вона використовується.
Треба заглиблюватися у технічну документацію — це допоможе уникнути дурних помилок і збереже ваш час та нерви Tech Lead. Ну, досвідчені це знають й інших навчають 🙂
🔴 Написання читабельного коду, з яким легко працювати іншим
Це вміння випливає з попереднього. У проєкті буде легко працювати усім, якщо всі дотримуються технічного процесу. Пам’ятайте, що з вашим кодом можуть працювати й інші: пишіть як для себе. Ваш “костиль” може повернутися бумерангом. Краще тестуйте й регулярно робіть рефакторинг свого коду, стежте за тим, як називаєте перемінні і функції, думайте про інших.
Важливе вміння — обрати правильну технологію для проєкту. Інколи програмісти з великим досвідом роботи наполягають на тому, аби використовували технології, до яких вони звикли, але з якими команді буде складно працювати. Натомість варто ухвалювати рішення за участю всієї команди, радитися, обговорювати та узгоджувати свої дії з іншими.
🔴 Якісний аналіз і розробка архітектури
Щоб якісно аналізувати й розумітися в архітектурі, треба знати теорію і мати достатньо практичного досвіду. Senior Engineer вміє зробити цілісний аналіз вимог й розробити архітектуру програмного забезпечення з ефективною імплементацією на різних рівнях.
При цьому він здатний знайти баланс між читабельністю програм і ефективністю розробки. Щоб уникнути проблем ще на етапі планування, досвідчений програміст знає різні технології й вміє обрати потрібну.
🔴 Вміння схематично пояснювати
Для досвідченого програміста, а особливо для Tech Lead хорошою навичкою є вміння пояснювати інформацію про принципи технології графічно за допомогою простих діаграм.
Діаграми, графіки й схеми забезпечують цілісне уявлення як про технологію, так і про проєкт. Візуалізація, системний підхід спрощує роботу усій команді. Таким чином Tech Lead передає бачення повної картини іншим.
🔴 Створення ефективного workflow
Досвідчені інженери розрізняють ефективність команди й свою власну. Щоб посилити та підвищити ефективність команди, вони вибудовують workflow або обирають нові технології, наприклад, автоматичний деплоймент.
Або ж намагаються заохочувати інших програмістів із команди більше вчитися й аналізувати свої помилки під час code review.
⚫ Про здоровий перфекціонізм, або як писати якісний код і не вмерти на роботі
Досвідчений програміст чітко усвідомлює важливість досягнення бізнес-задач і вміє дотримуватися балансу між їх реалізацією і якістю коду. Адже якщо дуже заглибитися у якість коду, то можна місяць займатися однією задачею, а можна і “до смерті” переробляти, доводячи до ідеалу весь проєкт. Але для того, щоб бізнес зростав, треба знаходити баланс, щоб зробити і якісно, і при цьому виконати вимоги кастомера.
Є такі програмісти, які фокусуються тільки на бізнес-задачах, й забивають код “костилями”. Колись я працював на одному проєкті, який через 2 роки розробки довелося повністю закрити, тому що на кожну нову фічу йшов місяць реалізації. Там неможливо було працювати. Це був «вінегрет з підходів і технологій». Ось так бажання зробити швидше призвело до сумних результатів.
Зустрічався і з програмістами, які заглиблювалися у якість коду й на одну задачу витрачали 2 місяці часу. Чесно, я дивувався, як їх тримають на роботі. У результаті задача виявилася дуже перевантаженою. Тому треба шукати баланс.
Мені подобається перфекціонізм, і я сам такий, але тут треба вмикати здоровий підхід і не перегинати. Зазвичай люди не змінюються. Ще на співбесіді я помічаю таких людей, і розумію, що з ними буде важко працювати.
🔴 Вміння працювати в команді
За замовчуванням зрозуміло, що в будь-якому проєкті цінують командних гравців. Це і про відсутність конфліктності, і про вміння брати на себе відповідальність, і про надійність, і про вміння комунікувати.
Можна мати свою думку і прислухатися до інших.
🔴 Впевненість при виконанні складних задач
Досвідчені програмісти впевнені, але не вперті. Вони не бояться завдань з викликом, бо вже досягли певного рівня експертизи, який дає можливість справлятися зі складними задачами й мають достатньо технічних знань.
Досвідчені інженери можуть планувати проєкт з різних перспектив, дають хороші рекомендації й працюють на результат від етапу розробки фреймворку до кодування. У команді таких людей цінують, з ними приємно вступати у професійні батли, завжди можна чомусь повчитися.
🔴 Постійне бажання розвиватися і знаходити потрібну інформацію
Повторюся, що досвідчені інженери в ідеалі знають кілька фреймворків і вміють працювати з кількома технологіями. А для цього треба постійно розвиватися, шукати можливості повчитися новому поза роботою. Досвідчені швидко вчаться, освоюють нові тренди, які потрібні для їхньої роботи. Деякі інженери думають, що достатньо вчитися на власних помилках. Так, на практиці здобуваєш багато знань, але треба їх поглиблювати й на основі чужого досвіду. Зараз достатньо інформації у інеті, можна багато вчитися.
Напевно, додатковою перевагою буде орієнтація у сфері, для якої ти розробляєш проєкт. Наприклад, якщо ти у Fintech-проєкті, то розуміти, яку цінність має програма з точки зору бізнесу, знати певні функціональні процеси тієї сфери.
🔴 Вміння зберігати рівновагу
Коли проєкт на стадії розробки, можуть траплятися різні непередбачувані ситуації, вилазити баги. Недосвідчених програмістів вони застають зненацька і трохи заганяють у ступор. Досвідчені інженери знають, що усе треба вирішувати без зайвих нервів, бо паніка і крики не допоможуть. Хоча, можливо, баги були допущені суто через людський фактор.
Досвідчений програміст знайде альтернативне рішення, зберігаючи врівноваженість. У спокої легше знайти нестандартне розв’язання задачі, аніж в емоціях.
🔴 Вміння ділитися знаннями й давати зворотній зв’язок
В ідеалі досвідчені програмісти діляться знаннями з іншими, беруть участь у вебінарах, конференціях, хакатонах. Одна справа, ділитися знаннями з книжки чи чужої теорії, інша справа — ділитися досвідом, своїми пережитими “болями”. Правда, не всі люблять це робити, однак нетворкінг — штука корисна.
Досвідчений програміст знає, як важливо давати фідбек щодо роботи інших. Це дає можливість зрозуміти молодшим спеціалістам, куди рости, що виправити і яких помилок не допускати.
Вчасний фідбек — це про прозорість менеджменту і про ефективну комунікацію. Добре, якщо програмісти на позиції Team Lead це розуміють і практикують.
🔴 Вміння визнавати свої помилки
Ще одна хороша якість досвідченого програміста — вміння визнавати свої помилки. Хто вміє це робити, той вміє і брати відповідальність. Помилки — це можливість взяти урок й здобути цінний досвід на майбутнє. Це не означає, що Tech Lead бере на себе вину за баги когось із команди, але вміє дати корисні інсайти під час code review, підказує, як розв’язати задачу, якщо з нею стикнулися.
Досвідчені програмісти точно не будуть кидати джуніора «під танк» і вказувати пальцем, що винен новачок. Працює вся команда, і кожен має свою зону відповідальності. Халтурить хтось один — страждає вся команда. Якщо є таке розуміння, тоді легко вибудовувати довіру й прозорі стосунки.
⚫ Про фейли, яких не може допускати Senior
Фейли бувають різні: як технічні, так і через людський фактор. Так, наприклад, якщо працівник регулярно не виходить на роботу, то це вже людський фактор.
Щодо вагомих технічних фейлів, то не стикався з такими, бо не часто працював з програмістами нижче рівня Senior. Звичайно, що можливі фейли Senior та Junior інженерів дуже відрізняються.
Я назвав би фейлом надсилати код в репу без прогонки тесту. Найкраще цей процес автоматизувати, як це є у нашій компанії. Ще один фейл — “костилювання” коду. Іноді виникає бажання зробити код швидко, але якщо цей прискорений процес погіршить якість, у майбутньому це все стане очевидним.
Є різні підходи до якості коду. Треба враховувати SOLID принципи. Якщо ти робиш поліморфну функцію, треба стежити, щоб вона не зламала ті місця, у яких вже використовується. Під час будь-яких виправлень коду маєш враховувати, до яких наслідків це призведе і як повпливає в цілому.
Фейл програміста, якщо він не дотримується техпроцесу. У моїй команді це створення pull-requests, прогін тесту на якість коду, проведення функціональних тестів, перевірка задач, які робиш самостійно. Якщо слідувати техпроцесу, створеному в компанії, то фейлів буде менше. Хоча, треба визнати, що й не у всіх компаніях є правильно налаштовані процеси, і це також може бути передумовою майбутніх фейлів.
Загалом скажу, що фейли Senior походять від ліні, а фейли Junior — від недосвідченості й неуважності. Фейли Junior найчастіше вилазять там, де ти їх не чекаєш. Робота джуніора, як така, на початку є суцільним фейлом, бо треба постійно виправляти, але на те він і джуніор.
Лінь Senior — це коли ти звик до якогось процесу, і довіряєш, думаєш, ну, потім підкоригую. Часто це не завжди добре завершується, але все ж частіше завершується краще, ніж у джуніора 🙂
⚫ Про «симулянтів», або Як відрізнити досвідченого і недосвідченого програміста
Недосвідчених програмістів можна виявити на двох етапах: по-перше, під час співбесіди, по-друге, і щонайгірше, під час роботи, якщо пропустили «симулянта».
⚫ Питання, які допомагають мені визначити досвід програміста:
- Скільки років досвіду?
- А скільки з них у роботі з конкретною технологією?
- Серія вузькоспеціалізованих питань, спрямовані на визначення глибини знань технології й фреймворку.
- Питання про базові речі володіння мовою.
Це той перший блок запитань, який допомагає визначити, наскільки людина обізнана і чи зможе працювати з нами. Якщо вже на цих питаннях розгублюється, то далі буде важче.
Буває так, що програміст має 5-річний досвід і володіє 10-ма технологіями, але коли поставиш елементарні питання з цього списку, він не може відповісти. Тоді швидше за все те ж буде з набором питань з наступного блоку.
Під час технологічних співбесід я не даю складні алгоритмічні задачі, адже співбесіда — це завжди стрес, і я не хочу його комусь поглиблювати. Якщо розробник звик працювати з певними технологіями, то міг забути, як виконувати окремі задачі, і це нормально — ідеальних людей немає. Важливо, наскільки людина орієнтується і як швидко зможе знайти рішення.
Загалом під час співбесід визначаємо як soft skills, так і hard skills. Технічний блок запитань відрізняється залежно від технології й проєкту.
⚫ Про ріст від Junior до Senior: поради з розвитку і росту
У деяких програмістів є ментори, які дають поради й спрямовують. У мене такого не було. Я вчився сам й знаходив необхідну інформацію самостійно. Хоча й отримав диплом з економічної кібернетики й вже базові речі знав, але коли читав філософію Java, зрозуміти нову абстракцію було складно.
Свого часу мені допомогли курси Java Rush — там усе легко пояснювали, і ти відразу можеш практикувати. Але це все не про фронтенд.
Це мені й допомогло стати програмістом. Решту я вивчав з офіційної технічної документації, а також шукав інформацію на безкоштовних відеокурсах. Для мене цього було достатньо.
Водночас помилково думати, що отримання диплому на курсах відкриє тобі двері в IT-компанію. Без знань цей папірець не дає ніякої користі. Тому відвідувати курси заради диплома немає сенсу.
Якоюсь мірою ти можеш отримати структуровану інформацію, але її треба запам’ятати й вона має бути базою й стартом для твого майбутнього росту. Одна з якостей доброго програміста — вміння знаходити якісну інформацію.
Вмієш це робити — все буде ок, але якщо ти очікуєш, що тобі це розжують, то помиляєшся. Я рекомендував би саморозвиватися й переглядати курси в неті. А якщо ти вже працюєш програмістом, то можеш собі й купити курси на Udemy — саме ті, які необхідні для твоєї роботи.
Що більше досвіду здобуває розробник, то більше усвідомлює важливість розвитку у напрямку Engineering Leadrship. І тут йдеться не лише про тих інженерів, які вже управляють командами, але і про розробників, які завжди на хвилі трендів, вивчають нове і комплексно розвивають свої hard i soft skills, щоб ділитися своїми знаннями і вміннями з іншими.
Джерело: DOU