Чи можна бути профі в чомусь одному, коли працюєш із різними технологіями? Правильної відповіді немає, але є досвід розробників, які спробували це на собі.
У компанії AMC Bridge команди працюють над проєктами інженерної галузі. Це означає, що спеціалістам потрібно добре розумітись і на програмуванні, і водночас на математичних дисциплінах. Таких фахівців не надто багато, тому вони є універсальними й час від часу змінюють стек і навчаються чогось геть нового. Чи підвищує це попит на них і які плюси та мінуси має така мультитехнологічність? Про це читайте нижче.
Олег Сподинець
Software Developer. 6 років в AMC Bridge, 14 років у розробці. Дніпро
Коли я потрапив в AMC Bridge, то працював із С++ у проєкті, де ми розробляли користувацький інтерфейс. Він мав зв'язати між собою плагіни графічних редакторів, що працювали з геометрією.
Через рік у цьому проєкті запустили підпроєкт, пов'язаний із пристроями віртуальної реальності. На мене це звалилось, як сніг на голову! По-перше, я став тімлідером, а, по-друге, почав роботу з новою для себе технологією — VR. Зазвичай в AMC Bridge тімлідери проходять research-проєкти, я ж одразу потрапив у клієнтський. Для мене це було, ніби навчатись плавати на глибині.
Про проєкт
Раніше автовиробники створювали прототипи у реальну величину (спочатку з глини, потім із пластику). Тепер для цього є віртуальна реальність. Наше завдання — зробити так, аби дизайнери могли швидко проаналізувати концепт-дизайн автомобіля. Для цього потрібно передати дані кузова машини у плагін і показати його в шоломі. Щоб можна було обійти авто і, просто натискаючи на пульт, змінити колір фарби, відчинити-зачинити двері тощо. Тут треба було експериментувати з самим проєктом. Плюс був прототип від клієнта, щоб проводити тестування.
Для роботи над таким проєктом ми переїхали у кабінет, у якому міг би поміститись автомобіль в реальну величину. Ми змонтували у кутах кімнати базові станції, виконали початкові налаштування і почали експериментувати.
Супротив та допитливість
Спочатку в мене був якийсь супротив до такої зміни, але інтерес переміг. Вважаю, що тільки такі виклики розвивають та роблять нас сильнішими. І, як з'ясувалось, такий екстрим дає великий позитив: він відкриває додаткові резерви, коли починаєш засвоювати інформацію швидше.
Так, перший місяць був нелегкий. Що таке VR? Як працює трекінг шолома в кіберпросторі? Як побудувати користувацький інтерфейс? На відміну від звичайного, цей має +1 вимір та додає більше проблем.
Коли ми починали перші експерименти, то зрозуміли, чому наш код повинен давати не менше ніж 90 кадрів на секунду і що таке motion sickness. І як може стати фізично зле, коли ти у шоломі, а щось починає глючити, чи горизонт раптово завалює... Але мене дуже надихала галузь, бо вона межує з розвагами та іграми. Зізнаюсь, перші дні ми від душі досліджували VR не з технічного боку, а з емоційного, тому просто веселились.
Нашим завданням було зробити прототип проєкту на браузері, а потім на ігровому рушії. До того я не працював із тривимірною графікою, шейдерами. Тому я просто відкривав урок з OpenGL і починав вивчати. Інформації було і є багато, тому потрібно просто її шукати та застосовувати.
Якщо щось не вдавалось, то це зачіпало, але з іншого боку — спонукало продовжувати. А ще мотивувала відповідальність, тому що я вперше безпосередньо спілкувався з замовником та ухвалював архітектурні рішення.
Горизонтальний чи вертикальний розвиток?
Я переконаний, що в якійсь одній галузі професіоналу не має бути рівних. До нього мають приходити по консультацію. Водночас важливо спробувати себе в суміжних галузях, щоб набиратись нового досвіду.
За ці три роки різкого перемикання на VR я дуже багато отримав. Це була цікава робота, де ми створювали нову архітектуру, писали рішення з нуля і багато придумували. Це було схоже на лабораторію зі свободою творчості та експериментів. Цінний досвід. Тепер, коли я дивлюсь на архітектуру інших проєктів, я розумію їх набагато краще.
Звучить банально, але вихід із зони комфорту — це зростання. І тепер я відкритий до нових пропозицій, які навчать мене чогось нового. Це класно — працювати у проєкті, де все зрозуміло, налагоджено, прораховано. Але на все свій час.
Роман Каманцев
Software Developer. 13 років в AMC Bridge та розробці. Дніпро
У моїй кар'єрі було дуже багато переходів між технологіями. Спочатку працював на C# та ASP.NET, потім на Java, після чого знову повернувся на C#, де було багато Desktop-розробок. Також працював як DevOps у проєкті, де практично не було програмування — слідкував за серверами та деплоїв.
Останній перехід відбувся, коли мені запропонували перейти у вебпроєкт, пов'язаний із мейлінгом. Майже весь клієнтський код був на JavaScript, але я ніколи з цією мовою не працював, тому багато чого не знав. Досі пам'ятаю, як я десь тиждень шукав зайву кому в коді.
Це було непросто, і я пройшов усі стадії — від заперечення до прийняття. Я розумів, що з цієї ситуації є два виходи: дійти до моменту, коли мені почне вдаватись, або кинути. Я обрав перше. Хоча тоді JS не була такою крутою мовою, як зараз (ще не існувало бібліотек рівня Angular чи React, середовища розробки не дуже добре підтримували JS, невелика кількість бібліотек та браузери тоді могли набагато менше), але матеріалу все одно було достатньо. Тому я просто вивчав її крок за кроком.
У всіх мовах все одне й те ж
При переході важливо розуміти, що ви не зможете одразу видавати результат. Звісно, у всіх це відбувається по-різному, але, за моїми спостереженнями, самостійна робота починається не раніше ніж за 2 тижні.
Інший момент, з яким я стикнувся, пов'язаний із самою мовою JS. Тут, на відміну від C# та Visual Studio, неможливо було дебажити й зрозуміти, де помилка: пропустив кому, а помилка проявляється в бібліотеці в іншому місці! І тоді не було способів швидко це знайти, треба було шукати емпірично.
Втім, після кількох перемикань розумієш, що у всіх мовах все одне й те ж: зазвичай дуже схожий синтаксис, просто різні обмеження. Принципи розробки також універсальні для всіх технологій. І людина з досвідом легко може між ними маневрувати. Крім того, з часом розрізняєш загальні принципи розробки, як-от keep it simple, не повторювати себе тощо. Так і виходить, що на самі технології інколи витрачаєш лише 20% зусиль і часу.
Звісно, це також залежить від завдань. Пофіксити щось, маючи мінімальну базу, можна швидко. Якщо ж ви .NET-розробник і вам потрібно з нуля розробити вебпроєкт, це займе багато часу.
Для мене перехід на JS був правильним. Це дало великий бонус для подальшої роботи на Full Stack, хоча він в AMC Bridge і містить здебільшого бекенд.
Горизонтальний чи вертикальний розвиток?
Не скажу однозначно. Якщо програміст заточений на одне, тоді він може впоратись із будь-якими завданнями і дуже добре. Нехай тільки у своїй технології, але ґрунтовно. Водночас універсальний програміст може самостійно вирішувати багато загальних питань у широкому діапазоні. Якщо ж трапляються специфічні завдання (скажу зі свого досвіду, що це буває не так часто), то він завжди може звернутись по консультацію до вузькопрофільного розробника.
Набагато важливішим, як на мене, є вичерпні знання, наприклад, математичних дисциплін. У новій технології можна розібратись за місяць. Натомість у геометрії, тригонометрії чи вищій математиці так швидко не розберешся.
Павло Біденко
Project Manager в AMC Bridge, 10 років у розробці. Дніпро
Я працював на .NET, коли нам з колегою запропонували перейти на JavaScript — працювати над вебзастосунком для візуалізації. Там не було готових рішень, а це означало, що все треба було вивчати з нуля. Було багато помилок та проблем. Я думав, що вмію писати на C#, .NET, а мова JS ніби простіша. Але з'ясувалось, що це не так. Після першого критичного фідбеку довелось все переробити й таки відкрити літературу.
Читайте інструкції на старті
Так буває, що коли ми щось купуємо, то рідко читаємо інструкції. Ми найчастіше робимо, і лише коли щось не вдається або зламалось, відкриваємо user guide. Так і в програмуванні: знаходиш готове рішення на Stack Overflow, реалізуєш, і лише коли воно не працює, береш книгу. Коли я перечитав книги про JS, все пішло набагато краще. А щоб розібратись у чомусь добре, потрібно прочитати не одну книгу. Лише так можна отримати глибоку теоретичну базу.
Інвестуйте у знання. Особливо, коли йдеться про вивчення нової мови програмування. Також не нехтуйте досвідом колег, котрі вже пройшли цей шлях. Це допоможе вам мінімізувати кількість набитих ґуль.
Щоб не писати «костилі», потрібно мати в арсеналі різні інструменти
Мова повинна допомагати писати код, а не створювати обмеження. Тому, щоб не писати «костилі» і не вигадувати велосипеди, потрібно мати в арсеналі різні інструменти. Якщо ви завжди робите на Java те, що забирає багато часу, то можете і не знати, що це ж, але з меншими зусиллями, можна зробити, наприклад, за допомогою JS.
Я радий, що у мене був цей досвід. І рекомендую усім вивчати принципово не схожі мови. Наприклад, .NET, C#, Java — це майже те саме, тому особливо не дає переваг для розвитку. Але якщо ви вивчаєте C# та низькорівневу C++; C# та JS або Scala або щось із функціонального програмування та ООП, тоді бачите різні підходи. Щонайменше варто орієнтуватись в основних концепціях різних мов та фреймворків. Тоді у вас буде можливість обирати під кожне конкретне завдання конкретний розв'язок, навіть якщо він з іншого інструменту.
Нова мова допомагає побачити вашу основну мову збоку
Немає можливості запропонувати у проєкт новий інструмент чи технології? Тоді спробуйте щось нове у вільний час. Це обов'язково треба робити, щоб підтримувати свою ринкову вартість. Підпишіться на тематичні розсилки або Twitter топових експертів. Так ви будете в курсі всіх новин і не витратите багато часу: можна читати блоги трьох-чотирьох людей. Коли я вивчаю щось нове, то завжди зберігаю свої напрацювання в теку. Можливо, я не зможу використати їх у теперішньому проєкті. Але раптом зможу у наступному.
Чому я вважаю, що це важливо? По-перше, нова мова допомагає подивитись на свою основну мову збоку: зрозумівши, як працюють принципи, наприклад, у JS, отримаєте більш ґрунтовне розуміння C#. Завжди можна додати фішку з однієї мови в іншу. Окрім того, такі Full Stack-програмісти легше отримують лідерські позиції, бо вони можуть запропонувати оптимальні рішення, а замовникам саме це і потрібно.
Горизонтальний чи вертикальний розвиток?
Ми з колегами часто сперечаємось: краще бути потрохи скрізь, чи дуже добре розбиратись в чомусь одному. Я думаю, що чим ти сильніший в чомусь одному і чим ширше охоплюєш інші технології — тим краще. Широкий світогляд (або T-shaped-розвиток) дає багато можливостей, бо такий фахівець може дати раду там, де не розберуться I-shaped-фахівці.
В якийсь момент саме T-shaped стає єдиною можливістю для розвитку. Коли? Як зрозуміти, що ви вже сильні в чомусь одному? Дайте собі відповідь: ви вже можете розв'язати будь-яке завдання без гуглу, а колеги звертаються до вас по допомогу? Тоді це воно!
Ще немає коментарів