Встигнути все: горизонтальний VS вертикальний розвиток програміста

Джерело: Codeguida.com

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

У компанії 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 стає єдиною можливістю для розвитку. Коли? Як зрозуміти, що ви вже сильні в чомусь одному? Дайте собі відповідь: ви вже можете розв’язати будь-яке завдання без гуглу, а колеги звертаються до вас по допомогу? Тоді це воно!

 

Зв'язатися з нами

Схожі публікації

Компанія AMC Bridge розширює співробітництво з ком'юніті програмістів

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

трав. 25, 2017
Хмарна платформа для 3D-принтерів. Історія одного проєкту

Команда AMC Bridge розробила концепцію хмарної платформи для виробника перших у світі гібридних 3D-принтерів — компанії Rize Inc. 

лист. 03, 2020
Як запрограмувати робота, і до чого тут Lego
Джерело: DOU.ua


Усім привіт! Я Вероніка Демедецька, Tech Expert & Senior Software Engineer у компанії AMC Bridge, кандидат технічних наук. Працюю в ІТ 11 років і маю досвід роботи із 3D-графікою, CAD-розробкою та робототехнікою. У цій статті я покроково і з власного досвіду розповім, як розробити симулятор промислових роботів. Тому, якщо ви працюєте або хотіли б працювати у цій галузі, моя стаття стане у пригоді.

січ. 26, 2021
Top