«Embedded-спеціалісти і в 60 років заробляють великі гроші». Розмова з Associate QA Manager Вікторією Таранюк, яка викладає у КПІ

Сфера embedded-розробок — одна з тих галузей IT, де не зросла конкуренція за вакансії під час повномасштабної війни. Ба більше, за даними DOU, у липні 2022 року кількість пропозицій на цю посаду була найбільшою з січня 2021 року — 60. При цьому відгукнувся на роботу лише один фахівець.

Вікторія Таранюк — Associate Engineering Manager у компанії GlobalLogic — працює у сфері вбудованих систем вже 12 років. За цей час спеціалістці доводилося кілька разів працювати на проєктах, не пов’язаних з embedded-розробкою, та кожного разу Вікторія планувала нарешті повернутися до завдань в улюбленій сфері. Про те, який зараз рівень embedded-проєктів в Україні, як навчати студентів цієї спеціальності та які перспективи індустрії — читайте у матеріалі.

Думала, що це нудно, а насправді знайшла справу мрії. Про те, як опинилася в embedded-розробці

Я потрапила в embedded-розробку 2011 року у GlobalLogic. На той час я мала знання з комп’ютерних мереж (навчання за програмою CCNA), досвід роботи системною адміністраторкою, бізнес-аналітикинею і тестувальницею. Цього багажу вистачило для того, щоб мене взяли в embedded-тестування одразу на позицію Middle QA Engineer. Спеціалістів було мало, і всіх доводилося навчати. Я тоді всіляко переймала досвід команди.

Насправді мені здавалося, що тестування — це досить нудна професія, але щойно почала заглиблюватися у вбудовані системи, то переглянула своє ставлення. Я працювала на проєкті з розробки Wi-Fi чипа. Розробка нових SoC для Wi-Fi загалом є дуже цікавою. Тестування передбачало всі процеси й підходи для виходу чипа на ринок. Наша команда з восьми людей багато працювала з обладнанням таким, як аналізатори спектра, вивчали фізичні характеристики хвиль, інтеграцію чипа з операційною системою Linux, тестування драйверів і об’єднання пристроїв у мережі. Тож до здобуття практичного досвіду важко було зрозуміти, що саме на мене чекало. А зрештою я була вражена та захоплена.

Це була пригода тривалістю вісім років. Наша команда проводила тестування на всіх рівнях. За цей період ми працювали з різною функціональністю, будували лабораторію для тестування (для цього зняли 3-поверховий будинок), літали до замовника в Ізраїль, на демонстрацію в Тайвань і на сертифікацію пристрою в США.

Ми досліджували, як зростає компанія, як з’являються ринки, як на нього виходить наш пристрій. З командою починали проєкт з 10 тисяч чипів, а закінчували вже 50 мільйонами. Я досить швидко доросла до QA manager і почала навчати людей, адже нам потрібні були фахівці. Цей проєкт вирізнявся тим, що за вісім років я здобула досвід різної роботи: технічної, менеджерської, менторської.

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

Коли я почала викладати в GlobalLogic Education, то давала студентам практичні знання, щоб вони одразу могли працювати. У програмі було основне, що треба знати: мережі, тестування, операційні системи. Людина швидко здобувала досвід на практиці, а далі, якщо їй чогось бракувало з теорії, могла довчити самостійно. Такий підхід був гарний тим, що спеціаліст одразу занурювався у роботу й отримував результат — фактично за три місяці підготовки. За найкращих часів — до пандемії та великої війни — з одного курсу компанія могла взяти на роботу 13 людей.

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

Набір на курс закрився за шість хвилин. Про C/Embedded GL BaseCamp для студентів

Отож моя менторська програма лягла в основу програми QA Embedded Basecamp, яку нині викладають у КПІ. Основна ідея співпраці полягала у тому, щоб побудувати місток між компаніями й університетом, аби світовий досвід ставав якомога раніше доступним для студентів. Ми часто приходили до університетів і розповідали про наше бачення співпраці та можливості GlobalLogic Education. Так виникла ідея спільного проєкту PoC «Smart City» зі студентами та викладачами ФІОТ. Це IoT-проєкт, що об’єднує різну міську інфраструктуру в єдину систему.

Певні проєкти студентів доїхали на CES у Лас-Вегас і брали участь у хакатоні, це було досить захопливо. Крім того, декілька студентів стали колегами в компанії GlobalLogic, а один вступив в аспірантуру і досі продовжує з нами співпрацювати на рівні університету.

Nvidia і Renesas r-car, фото з навчання на PoC Smart City

Цей проєкт започаткував співпрацю між GlobalLogic та університетом, тож п’ять років тому компанія та КПІ підписали угоду. Усе почалося з того, що QA Embedded GL BaseCamp почали викладати як навчальну дисципліну на ФІОТ. Курс розширив навчальні програми з підготовки студентів з Linux, комп’ютерних мереж і започаткував дисципліну «Технології тестування (QA) вбудованих систем». Програма стала популярною серед студентів і останній набір закрився дуже швидко — за шість хвилин зареєструвалися близько 120 людей.

Ми були приємні вражені, адже на початку в групі було 30 осіб.

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

Цей досвід сприяв створенню сертифікатної програми «Інженерія вбудованих систем та Інтернет речей» на ФІОТ, у якій Globallogic бере участь. У сфері розробки вбудованих систем студенти працюють з контролерами, зокрема Globallogic StarterKit, а також іншим устаткуванням, яке компанія передала університету. На лабораторних роботах з контролерами студенти опановують сім лабораторних за темами:

1. Hello World — знайомство з МК та IDE;

2. LEDs, Buttons, Interrupts — GPIO ports usage (порти вводу/виводу).

3. Timers — система тактування МК, таймери, ШІМ-режим, генерація заданих сигналів.

4. ADC — робота з АЦП. Під’єднання зовнішнього потенціометра.

5. Communication interface USART — керування світлодіодами за допомогою ПК (зв’язок за RS232 com port).

6. Communication interface I2C — керування зовнішнім Stereo DAC. Генерація мелодії.

7. Communication interface SPI — керування зовнішнім акселерометром. Детекція кута нахилу плати в просторі.

У межах частини з тестування ми разом створюємо вбудований пристрій, збираємо з вихідного коду Linux, у нас виходить мережевий сніфер як SUT (System Under Test). Спочатку налаштовуємо оточення з вимогами до мережі, а потім працюємо з пристроєм. Студенти можуть отримати до нього віддалений доступ чи взяти особисто під дипломну роботу. Частина робиться на симуляторі. Вони пишуть тест-кейси, розписують дефекти.

Загалом у сертифікатну програму входить п’ять дисциплін:

  • Технології програмування C/Embedded
  • Технології програмування на ПЛІС (FPGA)
  • Управління ІТ інфраструктурними проєктами
  • Тестування та контроль якості(QA) вбудованих систем
  • Технології розроблення вбудованих систем IoT

Для проєктної роботи у нас є мініпроєкт, написаний на Python — «Технології розумного міста». Студенти вчаться збирати дані з пристрою або сенсору на кшталт акселерометра, здійснювати обмін даними, зберігання та відображення. Також студенти використовують такі інструменти, як Jira, CI/CD pipeline, синтаксичний аналізатор коду та автоматичні тести. Усе це вони роблять у командах, пробують описати архітектуру, розписати завдання на імплементацію, розбити їх у Jira. Студенти у групах роблять спільний проєкт і домовляються один з одним щодо деталей.

Програма є трішки адаптованою для того, щоб її могли закінчити студенти з різною спеціалізацією та рівнем підготовки. Однак зауважу, що рівень студентів досить високий. Тож ті, хто добре розібрався з матеріалом, готові працювати на комерційних проєктах інтернами. Ми з колегою з GlobalLogic, який теж викладає в інституті, зійшлися на думці, що після такої підготовки приблизно 10 студентів можна наймати як трейні в компанії розробниками та 15 тестувальниками. Однак тут все залежить від кількості вакансій для інтернів, адже їх може бути 2–3 на конкретний момент. Але ми знаємо, що багато наших студентів успішно влаштовуються на ринку.

«Робота зі студентами — це мій волонтерський внесок у майбутнє України». Про викладання у КПІ

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

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

До дисциплін залучені викладачі з факультету. З проєктної роботи я викладаю тільки частину, що стосується комерційного досвіду та Scrum. Теоретичну частину про технології та інструменти викладають працівники вишу. Ми також залучили до викладання лекцій аспірантів кафедри, які працюють в ІТ-компаніях і є спеціалістами в різних технологіях. Наприклад, DevOps, синтаксичний аналізатор коду, автоматизація тестування, Git, Jira — це теми, які викладають аспіранти. Цього року долучився досвідчений програміст з GlobalLogic, який викладає embedded-програмування.

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

«Вбудовані системи вивчають майбутні інженери, які будуть розробляти дрони, піднімати промисловість України»

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

Хочу, аби всі зрозуміли: така взаємодія не завжди виснажувальна. Я витрачаю лише 1,5 години на тиждень для лекцій і окремо ще можу консультувати студентів з дипломних робіт. Мої дисципліни — тестування та проєктна робота — розписані за семестрами, тож це не забирає багато часу. Щоб ділитися знаннями, не треба кидати основну роботу.

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

Програма гнучка, вона може охоплювати різні дисципліни. На проєктну діяльність ми збираємо студентів з різних доменів і пропонуємо їм зробити розумне місто. Тому вони можуть самі обрати, додати у систему додатковий сенсор, чи пристрій, чи підсилити Back-end або Front-end.

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

Більшість — гнучкі, але дехто відстоює академічний підхід. Про співпрацю з викладачами

Я дуже задоволена співпрацею з викладачами вишу. Є хибна думка, що в університеті все застаріле і ніхто тут нічого не хоче розвивати. Я з цим не погоджуюся.

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

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

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

Лише універу не вистачить. Про те, що embedded-розробку треба вивчати додатково

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

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

Де почерпнути додаткову інформацію:

  1. Я б дуже хотіла, щоб у нас стали популярними пет-проєкти і студенти не боялися створювати маленькі прототипи, власні проєкти. Отримав знання — одразу пробуй з ними щось зробити. Це спосіб мислення. Пет-проєкт допоможе зрозуміти сильні та слабкі сторони. З ним варто підійти до знайомого інженера і попросити поділитися фідбеком — де є помилки, що треба дотягнути. На щастя, у нашій країні радо діляться знаннями. Вам обов’язково допоможуть. Потім цей проєкт можна буде додати до портфоліо чи вписати у резюме.
  2. Є хороші курси з embedded-розробки на Udemy. Вони досить якісні та прикладні.
  3. Курси від компаній. Такі курси спеціально створені для підготовки спеціалістів. Тому, якщо ви вже пройшли попередні етапи, сміливо реєструйтеся на курси у компанії.

Тобто ідеальна формула така: технічна освіта — власний пет-проєкт — відгук від знайомого програміста — курси на Udemy — вступні курси від компанії.

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

Конкуренція тут набагато нижча. Про затребуваність і плюси спеціалізації

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

У embedded є один великий плюс — мова C/C++ значно не змінюється, фундамент з електроніки залишається таким самим. Наприклад, Java постійно змінюється, вебтехнології також модифікуються, з’являються нові фреймворки. Водночас мова С, яку переважно використовують в embedded-розробках, залишається майже незмінною з 1972 року. Крім того, спеціалістів з вбудованих технологій важко замінити. У нас є розробники, яким по 60 років, і вони досі заробляють великі гроші. Конкуренція тут набагато нижча. Компаніям важко вийти з українського ринку, бо вони не можуть так швидко замінити команди.

Негативного впливу не було, почали розвиватися нові напрями. Про вплив війни на embedded-розробку

Ця професія більш надійна та стабільна, крім того, вона значно менше за інші постраждала через повномасштабну війну. Embedded-розробка постійно підлаштовується під актуальні потреби, тож під час війни збільшилася кількість оборонної промисловості.

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

Залежно від того, яка промисловість є нагальною, трансформується й embedded. Якщо у нас сплеск аграрної промисловості й дрони поливають поля, то буде embedded під аграрну промисловість. Якщо у нас сплеск оборонної промисловості, то й embedded під оборонку.

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

Дехто обурюється, що на старті мало платять. Про зарплату і рівень embedded-розробок в Україні

Деякі люди обурюються, що стартова зарплата в embedded-розробці низька. Мовляв: «Я маю стільки всього вчити, щоб піти на 400 доларів, які можна отримувати в іншій сфері, де не треба стільки всього вчити». Це неправильна логіка. На початку зарплата низька, бо спеціаліст-початківець є збитковим для компанії, на ньому ніхто не заробляє. Я б назвала цю оплату стипендією, заохоченням для того, щоб у вас почали вкладатися. Компанія вірить у вас, бачить потенціал і пів року плідно співпрацює з очікуваннями, що далі ви почнете приносити прибуток. Потім зарплата спеціалістів швидко зростає, і стелі у ній немає. Бувають дуже дорогі спеціалісти. Навіть в Україні є інженерні зарплати по $8000 на місяць, хоча це швидше виняток.

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

Хтось вважає, що це складна професія, і не помиляється. У embedded є сфери, які не всім під силу. До них треба мати хист і дуже багато знань.

Мене тішить, що в Україні добрий рівень embedded-розробок. Він ставатиме тільки кращим, адже у нас з’явився ще військовий напрям. Українських інженерів активно забирають у Кремнієву долину — там уже багато знайомих. Хоча багато хто свідомо обирає залишатися в Україні, щоб вкладатися у перемогу.

Перспективи у сфері безмежні. Вони будуть і на нашому ринку, і на міжнародному.

За 12 років роботи у сфері у мене ніколи не було думок змінити вбудовані технології на якусь іншу ІТ-професію. Навпаки, бувало, що компанія просила взяти інші проєкти, не пов’язані з embedded (Cloud, UI). Я працювала над ними, але завжди сумувала за вбудованими системами. Мені завжди їх бракує, коли працюю на іншому домені.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось21
До обраногоВ обраному13
LinkedIn



60 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Саме так, ти на межі між SW та HW, при потребі спускаєшся вниз(HW) або піднімаєшся вверх(SW), щоб все працювало синхронно і як треба.

Німецька залізниця наймає спеціалістів з MS-DOS та Windows 3.11 для підтримки роботи дисплеїв машиніста у поїздах hi-tech.ua/...​eїv-mashinista-u-poїzdah

Ось реальний приклад затребуваності спеціалістів пенсійного віку в Embedded-розробці, бо молодим немає сенсу подібне вивчати, ... і це головна відмінність Embedded-розробки від веб/мобайл, що є і буде багато легасі, яке потрібно десятиліттями підтримувати.

Але за таке не платять великі гроші ні в Німеччині, ні в Україні, просто зп вище середньої, ... а те, ще пані Вікторія бачила в GlobalLogic розробників віком 60+ років, які отримують великі по українським міркам гроші, то їхня головна затребуваність та конкурентність — це те, що вони мають кращі знання в електроніці, радіофізиці та ін. в порівнянні із молодими спеціалістами.

Я перепрошую, чи не думаєте ви, що цією статтею ви внесли компанію та учбовий заклад до списку цілей ворога?

Оообоже.......а ви не думаєте що пишучи тут начеб-то розумні речі також стаєте ціллю ворога ?

Emdedded-спеціалісти і в 60 років заробляють великі гроші

Опечатка. EmBedded

Дякую, що помітили. Вже виправили помилку.

Я скопіпастив «Emdedded» та декілька разів зробив таку помилку в каменті нижче🤦🏻‍♂️
Прошу також в повідомленні виправити та видалити потім даний коментар🙃

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

Але варто зауважити, що embedded-розробка не для всіх, бо потрібна технічна освіта та інтерес до інжинірингу в певному домені, тому тут не зайде реклама курсів та інша агітація, як за умовну професію front-end розробника, куди поріг входу низький і багато історій світчу від людей без технічного бекграунду.

П.С. «Embedded-спеціалісти і в 60 років заробляють великі гроші» — це якийсь ірраціональний заголовок статті від DOU, незрозуміло чому такий був фокус саме на вікові обираючи із всього написаного, ... також варто враховувати, що embedded-розробка має відношення до розробки ПЗ для найстаріших доменів, тому очевидна наявіність вікових спеціалістів, а нинішні розробники у віці 30+, що працють в «молодих» веб/мобайл доменах, в віці 60 років також будуть мати схожі можливості.

Якось пропустив, ці сертифікаційні програми доступні для не студентів?

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

Можна якось отримати доступ до цього курсу: QA Embedded GL BaseCamp ?
Також які ресурси ви можете порекомендувати для вивчення теми embedded QA ?
Або загалом щось фундаментальне для embedded/network теми ?

Embedded дуже-дуже різний. Тут і розробка застосунків (Application Engineering), розробка драйверів, бібліотек, автоматизоване тестування.
Корисний ресурс і діаграма, що корисно знати тут для новачків:
github.com/...​edded-Engineering-Roadmap

Не ходіть в ембед. Ембед- це біль..

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

Це не те, що б біль, але справді не для всіх.

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

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

Бажаючих займатись низькорівневим ембеддедом типу обв’язки Ардуїно модулями насправді значно більше, ніж реального попиту на ринку праці і за це платять дуже мало, а у високорівневого ембеддеду хронічна проблема з HR — він дозрів і перезрів необхідність поділу на піддомени, але від кандидатів досі типово вимагати широти стеку від аналогової схемотехніки і фізики, до С++20 з веб-бекендом чи тулкітами для десктопних/мобільних додатків, більш-менш стандартизовані тільки розробники під Linux kernel.

Конкретно ризики

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

Бажаючих займатись

фігнею типу

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

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

У високорівневому ембеддеді, на щастя, вендори вже не осилюють власні екосистеми і вже працюють нормальні практики і інструменти, але все одно то тут, то там доводиться збирати яким-небудь wind river-овським компілятором фірмварь для secure boot і підкидати у людську білд-систему.

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

Тому це не мінус, а на мій погляд, суттєвий плюс для професійного росту.

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

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

Практично кожен вендор мікроконтролерів намагається напарити свою власну IDE і свої унікальні конфігуратори мишкою периферії,

На мій погляд, це має вплив тільки на початковіх етапах становлення проекту.

Весь сучасний технологічний стек, від квантової механіки і фізики напівпровідників, до кінцевої задачі користувача чи технологічного процесу на заводі, навіть після профільної вищої освіти вдасться покрити лише оглядово

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

Сам не працював

А я 8 років Control & Automation Engineer на промислових підприємствах. Більше десятка успішних проектів по світу. Так от, це, чи не найбільша помилка новачків хто приходе з традиційного програмування в світ Industrial Automation. Там усе зовсім не так, як здається з офісу з кавою і печеньками і традиційним підходом по снаряду )) Прийти з IA в Embedded набагто легше і простіше чим навпаки, як на мене. Хоча в мене був багаторічний бекграунд до цього в ембедед, тому можу бути не об’єктивним десь.

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

Десь 80-90% експірієнесед контрол інженерів знають і вміють усіх основних вендорів АВ, Сіменс — the must, і усякі Schneider, ABB, і т.п. в більшості своїй. А також усі основні допоміжні дисципліни, як то, SCADA, OPC UA, SQL, мережеві протоколи вендорів і т.п. Про залізо і вміння працювати руками — я вопще мовчу. Я якось показував фотки , як мої carpenter gloves за рік перетворються на розлохмачені тряпки )) Така собі робота «програміста» в цій сфері )) Сам був в шоці по первах, потім розумієш шо оте і є справжне життя, бо реальний драйв, а не просиждування штанів в конторі на мітінгах.

На мій погляд, це має вплив тільки на початковіх етапах становлення проекту.

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

хтось з розробників на якомусь етапі перебігу проекту мав визначити оту потребу в профільному специалісті

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

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

У мене навпаки, того реального життя з паяльником, високими частотами і напругами, програмуванням під мікроконтролери, FPGA і рівень ядра Windows, +12 в приміщенні і паяння на сплав Розе збірок літієвих батарей на кіловатт-годину запасу енергії, і все це за 100-200 баксів у місяць, вистачило у аспірантурі. Економічно і для здоров’я вигідніше працювати вище по стеку, а рецидиви бажання заліза на столі лікувати пет-проектами...

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

, того реального життя з паяльником,

вочевидь ви не зрозуміли про шо йшла мова. На промисловому підприємстві, у важкий промисловості, наприклад, регулярно напяливши steel toe, робу, каску гасаєш по по території або між цехами з лаптопом і купою кабелів. А carpenters gloves — тому що три пальці вільні і можна княпати у RSLogixx 5000 або TIA Portal і лазити по шкафах не боячись пообдирати руки. А ввечері точно не потрібні оті ваші тренажорки, велісапеди, біг трусцой і т.п. ))) Я в 55 років забігав на 15м відмітку в повній снарязі з компом навіть не збивши дихалку. ))

скільки у вас було різних проектів, з різними підходами, різними вимогами і т.п.

У хронологічному порядку:
Виготовлення вимірювального комплексу для дисертації, з мого боку чисто хардварна частина, але у тісному контакті з тими хто писав під мікроконтролер без ОС і FPGA.
Хозтема з розробкою зарядної станції для ЗСУ, знову все залізо і виготовлення прототипу.
Два різні PoC навколо Xen+Linux.
Один продакшн з Xen+Linux
Один PoC з SYS/BIOS
Один продакшн аутстафф на базі Linux, з повністю віддаленим залізом і кодом
Один великий продакшн з класичним низькорівневим ембеддедом
Наразі — продакшн з Linux.

Не розуміння що не буває однакових проектів в ембеддед.

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

вочевидь ви не зрозуміли про шо йшла мова

У мене по нулям досвіду саме з заводами, але ідея про «реальний драйв» знайома. Принаймні у науці вона мені не зайшла, бо за вдесятеро менші гроші мати 10% драйву і 90% умовних мітингів — це менш вигідно, ніж розділити мітинги для грошей окремо, хардварні пет-проекти для душі окремо.

У хронологічному порядку

Тобто в більшості своїй це не є ембедед у класичному розумінні — bare metal з усіма обі’язками. Зараз у такому більшість вакансій. А от потрапити в команду що сидить на реально низькому рівні майже не можливо.

я це і зазначив як проблему високорівневого ембеддеду

В цілому, згоден. Це більше верхній рівень, і тут завжди починається з бабягами нікчемушна боротьба на співбесідах, умовно кажучі, за «фреймворки» )) І якщо нема чарівних слів у резюме — давайдасвіданія, і пофігу скільки в тебе років досвіду і що воно усе по суті те саме на цьоиу рівні. І те що, наприклад, процесс демонізації в Юнікс ніяк не змінився за 50 років, нікого не піпче, так само як і те що С той самий. А те що більшість вже забули різницю між SYSV/BSD/POSIX не має значення )) Бо Лінукс — це стовп, хоча як приклад, у багатьох PLC вендорів що роблять залізо під CODESYS реалтайм ядро на BSD.
З досвідом те саме. Навпаки, навіть, з 10+ швидше знайдеш вакансії, ніж чим напишеш 20+. Я вже давно не пишу реальний досвід у роках, зупинився на 30++ ))

зазвичай намагаються знайти універсаліста

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

Такі проблеми виникають, головним чином, по причині неправильно обраного процесу розробки. Наприклад, в автомобільній техніці дуже важливі вимоги функційної безпеки (все більше і більше функцій в машині керується електронікою, перехід на електрику, правильний менеджмент батареї) і виходячи з цих вимог потрібно обрати відповідний процес розробки програмного та апаратного забезпечення та здійснювати повний цикл розробки у відповідності індустріальних стандартів, провести незалежний аудит якості продукту. Для відповідальних речей можна обрати ISO 26262 + ASIL D в плані функційної безпеки.

Я маю досвід і в ASIL і з AUTOSAR & Elektrobit і автомотів вцілому помацав.)) Це свій всесвіт який до ембедед має вже давно, м’яко кажучі, далеке відношення. Просто перейти в автомотів з нормального ембеддед, хоть ти тричи геній і нобелівський лауреат — неможливо. А шо там робиться в середені — то окрема тема. Як казали в нас — досвідчений автомотів софтвер інженер на автівках не їзде ))

Я маю досвід і в ASIL і з AUTOSAR & Elektrobit і автомотів вцілому помацав.)) Це свій всесвіт який до ембедед має вже давно, м’яко кажучі, далеке відношення. Просто перейти в автомотів з нормального ембеддед, хоть ти тричи геній і нобелівський лауреат — неможливо.

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

PLC до ембедед має, м’яко кажучі, далеке відношення. Хіба шо найм в самого вендора що виробляє PLC і внутрішний софт для них. Так, деякі вендори, наприклад, що під CODESYS, дозволяють погратися С/С++ в PLC. Але, проcто для інфи — в шатах, наприклад, уся PLC автоматика що має хоч якесь відношення до .gov має використовувати тільки ladder logic. Тому описаний перехід «в медицину» трохи не релевантний, якшо це, наприклад, вимірювач тиску, або інсулінова помпа, і т.п. А з точки зору Industrial Automation (control processing, PID, SCADA/HMI, etc) відмінностей не так шо б і багато на рівні тех. процесів. Скрізь ті самі 4-20 сенсори, актуатори (пневматичні, гідравлічні, або електричні), ті самі параметри PID регуляторів, HMI панелі, мережеві протоколи і LD. Нормальний технолог завжди забезпечить верхній рівень і теорію тих процессів. Саме програмування в IA не залежить від домену.
А коли я писав про труднощі переходу зі звичайного ембеддед до автомотів, я мав на увазі, шо без чарівних слів у резюме ASIL і AUTOSAR ніхто навіть дивитися не буде на те резюме. А що б набути такий досвід для резюме, треба спершу попрацювати в тому автомотів. )) Така собі закрита каста по ітогу )) Хоча з власного досвіду, 2-3 місяці повністю достатньо для того, шоб освоїти і вписатися в процес. І ніякого рокет-сайнс там нема. Це наліпший опис сучасного автомотів що я колись бачив )) www.reddit.com/...​tm_medium=web2x&context=3
Тому перехід З автомотів до іншого домену, при наявности 10+ років досвіду не маже бути чимось захмарним. А от навпаки... Те саме стосується і усіх інших варіантів міграції ембеддед-ембеддед по різних доменах. Так, якісь додаткові знання якоїсь конкретної прикладної сфери, то є, звічно великий плюс, але НЕ знання тіеї прикладнухи ніколи не було суттєвою перешкодою для переходу, хіба шо тільки в очах HR ))

PLC до ембедед має, м’яко кажучі, далеке відношення.

Має пряме відношення, тому що розрозбка мікроконтролерів та написання до них прошивок на С/С+ — це ембедед розробка.

Хоча з власного досвіду, 2-3 місяці повністю достатньо для того, шоб освоїти і вписатися в процес. І ніякого рокет-сайнс там нема. Це наліпший опис сучасного автомотів що я колись бачив )) www.reddit.com/...​tm_medium=web2x&context=3
Тому перехід З автомотів до іншого домену, при наявности 10+ років досвіду не маже бути чимось захмарним.

Стосовно переходу в інший домен ви написали з точки зору поточного стану маркету, а раніше це був не замкнутий круг із захмарними вимогами, бо саме для вас, як для спеціаліста з досвідом в автомотів, була задача менторити світчера з досвідом ембедед-розробки в іншому домені, а зараз є з кого перебирати.
І, так, автомотів це не рокет-сайнс, також про 10 років ви загнули, з мого досвіду спеціалісти з досвідом 3-6 років в розробці PLС та ICS переходили на складні проекти (наприклад, в медицинські чи в Nvidia) в порівнянні з якими автомотів який ви маєте на аутсорсі в GL — це примітивні цяцьки, і не тільки технологічно, а також з точки зору вимог стандартів.

НЕ знання тіеї прикладнухи ніколи не було суттєвою перешкодою для переходу, хіба шо тільки в очах HR

До повномаштабного рекрутери бомбили в LinkedIn кандидатів із знанням С/С+ і певною кількістю років досвіду без прив’язки до домену, технічне інтерв’ю могло бути зразу на 2а проекти, давали офер і брали взагалі на 3й проект. А стосовно кваліфікації рекрутерів аутсорсних компаній в ембедед-розробці, так, вона практично відсутня, і як приклад не тільки підхід до моніторингу резюме та як скрінінгові інтерв’ю проходять, а навіть періодично подають вакансії Embedded С в розділі C-level.

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

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

Linux це не зовсім ембед, хоча є окреми задачі, а ардуіно це скоріше навчальна система. До ембед зараз відносять дуже багато всього що до ембед лише торкається чи виконується на вбудованому залізі. Ембед це зазвичай нище за рівнем там де немає запобіжників, імхо.😁 Точніш створення «запобіжників» — це одна із ембед складових.😂

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

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

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

Високий поріг входу, мала кількість вакансій (і як результат медіана окладу нижче медіани ринку). Навіть java розробник матиме більший оклад. Інколи обмеження у віддаленій роботі (бо існує обмежена кількість дуже дорогих девайсів)

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

І правда і не правда. Бувають коливання ринку... на Джаву був бум, тоді навіть ми змушені були брати синьора за 6500. Потім був спав і також рівня людину взяли за 3000. Ембеддед так не скаче. Для віддаленого доступу були проблеми, але за часів ковіду все вирішилось. Більшість проектів зробило віддалені лабораторії. На деяких проектах були обмеження, тоді приїжджали за платою і потім з нею працюють з будь якої точки

мала кількість вакансій

+багато. Те що пише ТС в цьому репортажі (тим паче для 60+) більше мотиваційна казочка для студентів.

Високий поріг входу

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

А що не біль (окрім пат проекту)?

Там де нас нема!😂 мабудь на swift чи Java 😂

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

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

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

Для embedded треба трохи знати електроніку, помучитися із «залізом», а воно ламається і не працює, людина психує.

Коли CSS ламається ще й не так психуєш.

і в 60 років заробляють великі гроші

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

Тому що ембед — це клуб «анонімних ембедерщиків» 😏 вилікуватися неможливо😁 я і в 70 (як що Бог даси) буду щось паяти та фірмварити😂

Ну, бажаю щоб руки не тряслися :)))))) Зір то таке, лупа є ;-)

Ага, секта 😀 тільки інтровертна часто. Єдина секта, де сектанти одне одного не бачать :)

Чути достатньо 😁 в ембедедкиїв теревенів доволі😂

Від не зовсім справжніх ембеддерів, в основному.

Не можуть чи не хочуть ? Є ті хто хочуть заробляти і в 60. Просто чула думку, що є обмеження. В мене є колеги солідного віку і їх більше у ембеддед ніж у вебі

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

Залежить від знань та можливостей виконувати задачі. Бачила як очі горять і в 60. З точки зору компанії теж обмеження не бачила.

В мене є колеги солідного віку і їх більше у ембеддед ніж у вебі

бо коли вони починали ще не було вебу. А потім не перейшли до вебу, бо після с++ якось несолідно.

Вікові програмісти навчалися в часи коли програмування було системним і це досить сильно сформувало їх підхід до програмування в цілому, тому їм доволі тяжко ввійти до сучасного смеш ctrl-c ctrl-v стилю програмування та опен-пофігізму 😁

сучасного смеш ctrl-c ctrl-v стилю

Сучасний стиль дуже різним буває в залежності від домену, наприклад, з розбивкою на сторонні бібліотеки навіть перевірки числа на парність:
stackoverflow.com/...​-a-is-even-package-on-npm

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

Це ж було вже. Інтервю з цією пані вже виходило десь восени.

Вікторія подекуди пише статті в розділі «Блоги», де ділиться своїм досвідом (останній такий блог публікувався в червні минулого року). Інтерв’ю з нею публікується вперше.

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

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