Універсальний vs вузькопрофільний програміст. Визначаємо шлях

8 грудня 2021
Юрій Юрченко, Leader of Global People Development
Універсальний vs вузькопрофільний програміст. Визначаємо шлях
Я вже 35 років в IT, понад 20 із них — у розробці, переважно в ролі тренера, що грає. Займався всіма видами підтримки, інформаційною безпекою та побудовою процесів з обов'язковим зануренням у бізнес замовника. Викладав, був ментором, проводив тренінги, але найголовніше — брав участь у формуванні команд, які можуть зробити практично все, до того ж із задоволенням. Тому що їм подобається їхня робота та подобається працювати разом.

У DataArt я на інституційному рівні допомагаю будувати плани професійного розвитку колег, оцінювати їхні кар'єрні перспективи та добирати технології для опанування. Тому проблема протиставлення універсальних знань глибокому зануренню в технічну експертизу на вузькому напрямку через цілком зрозумілі причини мене хвилює.

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

Універсальність як вічна цінність

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

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

Відхилення у бік спеціалізації розпочалися в індустріальну епоху, особливо з виникненням конвеєрного виробництва. Один мій знайомий усе життя прикручував задню ніжку до диванів на меблевій фабриці. Було нудно, хоча моделі диванів періодично вдосконалювались. Коли підприємство закрилось, не витримавши конкуренції, йому було не дуже просто знайти роботу. Наразі насамперед такі рутинні операції підлягають роботизації, а людині залишаються творчі спеціальності. Наприклад, інформаційні технології, зокрема програмування.

Якщо подивитися на історію IT, спочатку мови програмування були схожими на ту саму палицю первісної людини. За допомогою машинних кодів і асемблера можна було показати все, на що здатна ЕОМ. Щоправда, робота за їхньою допомогою займала тривалий час, для розробника це було дуже незручно. Тому досить швидко виникли мови високого рівня на кшталт PL, REXX чи Фортран. При цьому слід пам'ятати, що мова програмування є такою самою мовою спілкування, як і будь-яка інша. Просто вона дозволяє нам комунікувати не лише один з одним (для цього вона теж годиться), а і з машинами. Тобто розширює коло наших контактів, роблячи здатність до спілкування більш універсальною.

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

Решта програмістів існують у цілком інших умовах: будь-хто, хто звернувся до сучасних технологій, буде змушений постійно вчитися. Або поглиблюючи знання в обраній спочатку спеціалізації, інструменти якої кардинально змінюватимуться (згадайте C, C++, C#, Golang), або уважно дивлячись на всі боки. Звісно, краще робити і перше, і друге.

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

Технології наразі розвиваються саме у напрямку синкретизму, щільного перетину та навіть часткового злиття найрізноманітніших напрямків. Візьмемо, наприклад, MLOps — об'єднання технологій машинного навчання й підходів до впровадження розроблених моделей у бізнес-процеси. Дуже важливо, що нова специфічна галузь потребує і нового способу організації співпраці між представниками бізнесу, математиками, ML-фахівцями та IT-інженерами. Це було б неможливим, якби всі вони не розмовляли однією мовою — тобто не опановували суміжні зі своєю основною спеціалізацією дисципліни. Чи цікаво працювати у MLOps-проекті? Гадаю, мало хто відмовиться. Чи візьмуть туди людину, не готову розширювати сфери компетенцій? Навряд, навіть якщо у своїй вузькій ніші вона давно стала блискучим професіоналом.

Варто зазначити, що це специфічна характеристика IT. Уся сучасна наука працює на стику технологій, що переплітаються, взаємодіють і доповнюють одна одну. Астрофізика, біохімія, історична географія. Археологія давно й тісно пов'язана з етнологією та генетикою. Саме одночасне використання знань із різних сфер допомагає робити нові, часом несподівані відкриття.

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

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

Я не стверджую, що кожен IT-фахівець зобов'язаний знатися на бізнесі. Проте це дуже корисно для роботи, спілкування з колегами і розуміння того, що відбувається на різних рівнях. Загалом серйозна спеціалізація почалася з виділення адміністраторів баз даних. Тоді вперше знадобилися люди, які глибоко знали специфіку написання скриптів і конфігурування СУБД різних виробників. Але така спеціалізація спрацювала погано. Тільки-но з'явилися DBA, багато розробників вирішили, що писати код можна як завгодно — прийде адміністратор і все оптимізує. Але відповідати на запитання “Чому так повільно працює SQL-запит?” усім швидко набридло. Кому цікаво розбиратися, чи це в розробника криві руки, чи DBA не вміє налаштувати сервер? Суті проблеми це не змінює.

Цю дивну ситуацію розв’язали вольовим рішенням: тепер бекенд-розробник має розуміти всі основні особливості бази даних, для якої він пише SQL-запити. Підходити до DBA стало пристойним лише з тонкими проблемами, що часто вимагають окремого дослідження, на яке просто немає часу. Адміністратори баз даних стали повертатися з конкретним розв’язання конкретної проблеми, яка могла стосуватися, наприклад, конфігурування лише на рівні файлової системи чи побудови кластерних індексів. Але щоб це запрацювало, розробникам довелося вивчити особливості діалекту конкретної мови, якою розмовляли DBA.

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

Кого можна назвати універсальним

Універсальний фахівець — не той, хто одного разу опанував ще одну незнайому технологію. Він постійно стежить за сучасними трендами та готовий інвестувати час, увагу й енергію у вивчення нового. Якщо говорити про прикладну сферу бізнесу, для різних проектів можуть знадобитися цілком різні ступені залучення та розуміння суті процесів на боці клієнта. У цьому насправді немає нічого нового. Можна згадати нашу базову освіту, скажімо, прикладну кібернетику — відповідний факультет, наприклад, у Києві закінчували дуже багато людей. Куди йдуть випускники, отримавши в дипломі кваліфікацію математика? Хтось до Антонова на авіазавод, де вивчає аеродинаміку і сопромат. Хтось — до Амосова, вивчати біологію й анатомію. Хтось — до банку, де знайомиться з платіжними системами і грошовими потоками. Завжди передбачалось: якщо ти не просто кодувальник, а саме програміст, то обов'язково маєш знати предметну сферу та постійно шукати, в який бік розвиватись з погляду технологій. Справа тут не у знанні двох, трьох, п'яти мов програмування, підходів чи методологій. Універсальність — насамперед здатність вчитися безперервно.

Наприклад, у DataArt є напрям вивчення штучного інтелекту. Це відкрита група, куди приходять люди з різних індустріальних практик і з різним професійним бекграундом, щоб обговорити, як ШІ можна було б застосувати там, де вони працюють. Навіть якщо просто зараз зі штучним інтелектом їхній напрям не пов’язаний, таке розширення знань дозволяє у перспективі “think out of the box”.

Якщо людина вибрала напрям і потрапила у великий проект, де збирається провести тривалий час, насамперед має сенс дивитися на технології, які могли б стати у пригоді в цьому проекті. Але будь-який проект рано чи пізно закінчується, і ставити собі запитання “Чим би я хотів займатися після нього?” дуже корисно.

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

Навчання — не марнування часу, а інвестиція в чистому вигляді. Саме тому завжди є ризик, що інвестиція не окупиться, але якщо не робити вкладень, розвиток точно зупиниться і на дивіденди розраховувати не доведеться. Звісно, доводиться дивитися на ринок та його тренди, а також, наскільки можливо, диверсифікувати інвестиційний пакет, щоб знизити ризики. Але життєва ситуація часто сама нагадує, в якому напрямку рухатися. Реальна свіжа історія: один з наших фронтенд-розробників нещодавно зайнявся бекендом та за три-чотири місяці отримав запрошення у проект як фулстек із значним підвищенням зарплати. Оскільки він паралельно приділяв багато часу командній роботі та приводив до ладу проект (йому було не байдуже!), ще за півроку йому запропонували стати тімлідом. Зручно, що наразі IT-фахівці є настільки затребуваними, що пропозиції знайдуть вас самі, що б ви не вивчали. Тільки не зупиняйтеся!

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

До речі, мені не подобається термін “перенавчання”, що часто використовується. Наче колишні знання кудись поділися, затерлися, і на їхнє місце записали нові. Це неправильно: для універсала експертиза щоразу розширюється, і накопичений досвід працює на майбутнє. Тому більш відповідним щодо IT буде використовувати слово “донавчання”. При цьому ніхто не заважає поглиблювати знання насамперед за основною спеціальністю: особливо круто виглядають колеги, визнані експертами у своїй галузі, які при цьому легко можуть говорити з фахівцями суміжних спеціальностей та чимало знають про їхню роботу. Нехай і не так глибоко занурені у предмет, як у випадку зі своєю основною спеціалізацією.

Перевірити себе

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

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

Широкий кругозір, вузький профіль

Я хотів би звернутися до тонкого розмежування понять “ремісник” та “майстер”. Обидва є потрібними і важливими, вони існують пліч-о-пліч та часто доповнюють роботу один одного. Ось визначення, просто взяте з інтернету, яке, на мою думку, добре відображає відмінність між ними:

Майстер — творець, він ставиться до своєї творчості з любов'ю. Його творчість приносить йому не лише радість, а й нерозв’язані питання, болісний пошук відповідей.

Ремісник — якісний виконавець, він стабільно виконує роботу, яка йому подобається, приносить задоволення, але він не творить.

Саме майстри, а не ремісники, сприяли розвитку людства в усіх сферах діяльності за всіх часів.

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

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    1 березня