Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Коли коду недостатньо: чому важливо інвестувати в знання свого домену

Всім привіт, мене звуть Олександр Вітер і я працюю Senior Software Engineer у компанії SoftServe. За майже 10 років в ІТ я встиг попрацювати у таких напрямках й доменах як: важке машинобудування/металообробка (manufacturing), онлайн-освіта (edtech), медична статистика (healthcare), навігаційні карти для автомобілів (automotive) та деяких інших. Поточний проєкт відноситься до telecommunication домену, проте поки що тут не відбулося нічого, що б значно виходило за рамки звичайної інженерної роботи, тому про нього історій не буде.

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

1. Welcome to the real world, Neo. Історія про відмінність абстрактного світу програмування та реального світу заводу

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

Мені пощастило потрапити у відділ, який займався написанням програм для обробки деталей на станках з ЧПУ (числове програмне управління, також відомі як CNC machines — computer numerical control) у колектив інженерів-програмістів.

У той час цей відділ досить активно зростав, а також той період припав на час отримання дипломів студентами, тому керівник відділу досить активно «хантив» молодих спеціалістів без досвіду, але зі свіжими теоретичними знаннями. Як експеримент (сюрприз-сюрприз, інженери люблять ставити експерименти :)), керівник відділу, окрім декількох інженерів з профільною освітою, які вміли і код писати, і розуміли, як що влаштовано у машинобудуванні, також найняв одного хлопця з класичною ІТ-освітою.

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

Іншими словами (можливо, це буде боляче чути ІТ-спільноті) висновок був такий: зробити з інженера —> програміста простіше, ніж з програміста зробити інженера.

Що ж передувало цьому? Ось декілька прикладів.

Перш за все, люди, які сконцентровані лише на коді і трохи відірвані від реального світу, досить швидко звикають, що будь-який запуск програми призведе до одного й того ж фінального результату — що перший, що мільйонний. Тобто: print(3+3) завжди виведе на екран 6, як у відомому кадрі з серіалу Rick & Morty.

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

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

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

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

У більш-менш непоганому випадку (коли зламався лише інструмент, але із заготовкою все окей) іноді ставалося таке, що оператор не міг знайти точну копію втраченого інструменту і доводилося брати інструмент з іншими характеристиками — з іншого матеріалу або з іншими розмірами.

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

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

Серед інших важливих факторів, які також дещо ускладнювали порозуміння між моїм колегою та операторами станків, була його віра в те, що програма може працювати майже 100% часу без зупинок (як це зазвичай відбувається з класичними ІТ-проєктами та production серверами). Це впливало на його оцінку того, скільки деталей за робочу зміну може бути виготовлено за його програмами. Він не враховував такі важливі речі, як:

  • потенційне ламання інструменту (що іноді трапляється навіть у хороших умовах, бо ніщо матеріальне не вічне);
  • необхідність призупиняти обробку через перегрівання обладнання чи інструменту/ заготовки;
  • час, який потрібен оператору, щоб зняти оброблену деталь, віднести її інженеру з контролю якості, повернутися до станка, встановити нову заготовку і запустити програму ще раз.

Як ми можемо побачити, корінь всіх цих проблемних ситуацій був один — ігнорування домену і надмірна концентрація лише на software-складовій процесу.

2. «Якщо ти не можеш пояснити щось 8-річній дитині, значить і сам не дуже добре розбираєшся у темі»

Працюючи на заводі, я почав вивчати інші мови програмування, які не були мені безпосередньо необхідні в роботі, але могли б розширити світогляд — Java, JavaScript, Python. Одним зі способів вивчення синтаксису мов я обрав розв’язування задач для програмістів на сайтах типу всім відомого LeetCode.

І от в якийсь момент мені на електронну пошту прийшов лист від одного з сайтів, на яких я активно розв’язував задачі. У листі йшлося про те, що їхній стартап розширює команду і шукає людей зі знанням JavaScript та/або Python.

Long story short — я успішно пройшов співбесіду і почав у них працювати як Python Developer. Окрім звичайних задач для розробника, додатково у мої обов’язки входило щось типу створення контенту, а саме — придумування нових задач і додавання їх на сайт.

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

По-перше, на відміну від мого друга, який хоч і вчився на іншій спеціальності, але також вивчав програмування в університеті і розумів базові концепції, на сайті з задачами для програмістів були люди різного рівня, в тому числі і нульового. Тому пояснювати треба було абсолютно все, починаючи з того, що таке змінна, цикл, як між собою об’єднуються строки та чому у Python «3» + 3 призведе до помилки.

По-друге, пояснювати треба було текстом, а саме — описом самої задачі та коментарями, які відкривалися в процесі написання коду рішення, якщо людина десь застрягала і не знала куди рухатися далі в імплементації алгоритму.

І по-третє, треба було бути трошки пророком та частково «відкотитися» до того рівня, коли ще сам був початківцем, щоб уявити, які питання і проблеми можуть виникнути у людей, які ще не знають всього того, що знаєш ти. Доводилося ставити собі такі філософські питання як:

  • «Краще подавати матеріал у тій же послідовності, в якій ти сам його засвоював, чи якось перегрупувати?»,
  • «Скільки задач треба створити на кожну з концепцій, щоб з однієї сторони цього було достатньо для засвоєння, а з іншої — не набридло своєю монотонністю?» й т.п.

Не зовсім типова історія, бо якщо розглядати суто обов’язки Python-розробника, то нічого незвичного у сайті не було — вебчастосунок як вебзастосунок. Але саме друга частина робочих обов’язків, де треба було через задачі вчити інших людей програмуванню, дуже сильно допомогла поглянути на програмування з іншого боку. А також через декілька років здобуті навички знадобилися, коли я почав викладати Python підліткам. Принципи залишилися більш-менш тими ж, тільки було додано трохи мемів і гумору, щоб не робити подачу матеріалу надто сухою і беземоційною.

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

Інша ж крайність — надто довго товктися на одному місці, не бачачи, що учні вже переросли тему і готові рухатися далі.

3. Лікар, математик і програміст заходять у бар...

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

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

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

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

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

Цікавим побічним ефектом від занурення паралельно у ці дві сфери (медицина й статистика), а також робота в колективі людей таких різних професій, було те, що на фінальних місяцях роботи над проєктом я часто ставав умовним фасилітатором/ медіатором між медичною та математичною частинами колективу. Бо математики не хотіли глибоко занурюватися у медицину, а лікарі — у математику.

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

4. Run boy run. Історія про те, що можна працювати в automotive і не мати автівки

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

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

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

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

В принципі, саме для розробки ніяких специфічних доменних знань не знадобилося освоювати. Чого не можна сказати про етап тестування і релізу. Звичайно, у тестуванні були деякі схожі моменти, якщо порівнювати з використанням Google Maps як пішохід.

Але все ж таки я дізнався й багато нового — наприклад, щодо встановлення навігаційних карт на бортовий комп’ютер автомобіля, або про програмну симуляцію їзди по маршрутах. Щодо релізу — цей етап вимагав бути супер-мега-гіпер уважним, щоб, наприклад, не проґавити слово Amerika у фразі North Amerika (правильно — America), яке могло б потрапити на сотні тисяч автівок і призвести до певних репутаційних втрат.

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

***

На завершення хочеться сказати, що я досить рідко коли працював чистим розробником без додаткових обов’язків. Зазвичай це була цікава суміш напрямків, наприклад:

  • програміст + інженер з металообробки;
  • програміст + автор контенту;
  • програміст + викладач;
  • програміст + тестувальник + реліз-інженер.

Можливо саме це вплинуло на те, що я вважаю дуже важливим занурюватися у домен того проєкту, над яким працюєш, а не просто «закривати таски на борді». Хто зна, можливо у людей які пишуть код і нічого окрім коду, зовсім інша ситуація та погляд на речі.

У будь-якому разі, якою б не була ваша ситуація і точка зору — з цікавістю почитаю про ваш досвід у коментарях.

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

совет: углубляйся в домен чтобы открыть потом свой бизнес и торговать экспертизой. всю жизнь код писать не будешь — физически не сможешь да и скилы быстро устареют.

Дуже сподобалось: «взяли програміста заради експерименту». Мені здається ви невмієте проводити експерименти:
-) для того щоб підтвердити теорію потрібно провести декілька експериментів, щоб гарантувати що результат не був випадковістю або збігом таких
-) взяли програміста без досвіду — звучить як нонсенс, HR тому й хантять «програмістів з досвідом» бо це означає що люди не просто освоїли програмування а мають досвід застосування цих знань до реальних потреб виробництва (і тут немає значення чи це сфера ІТ чи суміжні)
-) загально відомий факт що програмісти люблять все «переускладнювати», а ваш «екземпляр» робив все навпаки :)

я працюю Senior Software Engineer у компанії SoftServe. За майже 10 років в ІТ я встиг попрацювати у таких напрямках й доменах як: важке машинобудування/металообробка (manufacturing), онлайн-освіта (edtech), медична статистика (healthcare), навігаційні карти для автомобілів (automotive)

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

іноді присвячував свій позаробочий час, щоб розібратися у тій чи іншій медичній або статистичній темі.

Тобто за 10 років розуму не прибавилось, працюєш задурно як і студентом.

Тому коли одна частина команди хотіла щось пояснити іншій, але не могла — кликали мене як «перекладача» з «людської мови на людську», але у принципово різних сферах :)

Тобто своєї роботи тобі не достатньо, ще треба працювати і як BА/РО (які на медичних проектах точно є).

По темі, якщо ти НЕ кваліфікований програміст то знання домейну (або фулл стек, скрам мастерство, та інші скіли в суміжних спеціальностях) це те що дозволить отримати роботу (з середньою ЗП).
Але краще стати кваліфікованим програмістом (чи BA, PO і т.п.) бо тільки тоді ти станеш експертом. І не будеш працювати як принеси, подай, зроби деплой, чи попрацюй «перекладачем» як тут

я часто ставав умовним фасилітатором/ медіатором між медичною та математичною частинами колективу

ІМХО, стаття це хороший приклад як не треба робити кар’єру, бо ще рік-два(якщо не вже) і в тебе тех і тім лідами будуть люди з меншим досвідом, суттєво більшою ЗП і меншими затратами в часі на роботу.

Гарна стаття! Дякую що поділився досвідом.

І правда, часто чуваки які гівнокодять і знають домен ціняться більше, ніж абстрактні сіньори які ніфіга не розуміють в сфері

можна працювати в automotive і не мати автівки

Був колись у витоків автомотіва Alexandre Darracq, він за свою карʼєру:
— Заснував власну компанію Automobiles Darracq France
— Став партнером братів Opel після чого в них бізнес пішов нормально
— Заснував ALFA, відома нині як Alfa Romeo
При цьому чувак не водив і навіть не любив їздити взагалі:)

Підписатись на коментарі