Наверное, есть те хабровчане, которые читали статью про то, как не надо входить в хату, в которой я делился своим опытом смены профиля в разработке. Конкретнее с разработки под МК на Embedded Linux. Вкратце: опыт довольно болезненный и всё-таки полезный при условии, если учишься на совершенных ошибках.

Практически 6 лет моего опыта — это разработка на Си под микроконтроллеры, причем разные:

  • это всякие AVR, STM и т. д., под которые есть много кодовой базы и материалов

  • какие‑нибудь SOC от Texas Instruments, по которым есть инфа только на закрытых форумах, доки (с пробелами и неточностями) и примеры драйверов, из которых можно подчерпнуть много полезного.

Ну и Embedded Linux, куда же без него. И вот тогда мне казалось, что я пишу мало кода. Как же я ошибался...

В моей практике Embedded Linux оказался переходным звеном из мира низкоуровневой разработки в мир прикладного ПО и уже на этом промежуточном этапе было сильно меньше написания кода, в основном изучение драйверов, переделка уже имеющихся. Вспоминая времена разработки под МК, удивляюсь тому огромному количеству моего кода, которое отгружалось в проекты.

Если говорить уже о прикладном - тут ситуация стала еще "круче" в нескольких аспектах.

Во-первых, как вы могли догадаться, программирования стало еще меньше. Да, это всё легаси, которое постоянно улучшается, приобретает новый функционал и избавляется от багов. И программировать там особо не надо, но при этом развивать другие навыки, которые...

Во-вторых, ... связаны не с языком программирования, а (барабанная дробь) с системным администрированием! Да, один из продуктов компании - это собственно набор утилит, помогающий администрировать записи пользователей малого/среднего/крупного бизнеса. Ясен пень, что нужно уметь этим софтом пользоваться, чтобы понимать его работу. Конечно, раньше я мечтал о том, чтобы влиться в Linux-разработку, ориентироваться в командной строке, как рыба в воде, писать утилиты, но что бы настолько... Да, я в Linux-разработке, да, привык к интерфейсу командной строки, но количество написанных строк кода почему-то какое-то мизерное.

Как говорится в одном известном меме:

Ну и напоследок, навыки отладки пачки одновременно работающих утилит. Например твой сервис отправляет сокеты в один, который обменивается данными с контроллером домена и толкает другой, что-то кладущий в свою БД и общающийся с клиентом на другой машине. Чтобы это всё анализировать помимо обычных логов же используется много чего: и GDB, и Perf, и какой-нибудь tcpdump и много чего еще интересного. Забавная была трансформация от состояния "а куда вообще тут смотреть?" до "ща запущу нужные утилиты, и буду смотреть что от куда вытекает и куда перетекает". Менять привычки, конечно, сложно, особенно в отладке: раньше тебе хватало только логов и осциллографа, не то что сейчас :)

ну и как всё это отлаживать?
ну и как всё это отлаживать?

В текущей ситуации состоялась одна из моих самых важных трансформаций: не надо брезговать пользоваться готовыми решениями. Раньше профдеформация говорила мне: камон, ты же практически всё пишешь с нуля, давай с нуля и вот это вот напишем. И в целом она была недалека от реального положения дел. Ты завязан только на своём коде, и что‑то в него встраивать извне себе дороже. Сейчас же ситуация прямо противоположная: проще встроить готовый инструмент/библиотеку и уже вот это всё корячить под себя, будет банально дешевле.

А да, еще одна трансформация — это отношение к Python: если раньше я как‑то с высока на него смотрел, типа фу‑фу‑фу, питонисты — не тру программисты, то сейчас: «М‑м-м, какой удобный язык: и тестики на pytest'е как легко пишутся и автоматизация процессов, блин, как удобно. И как же я раньше жил без него?...». Раньше делая какую‑то автоматизацию, я пытался в bash , но потом бросил эту затею, так как в пайтоне реально удобнее. Иными словами, в голове надежно закрепилось понимание, что у каждого ЯП свои задачи и относиться к этому надо соответствующе.

В общем, кодинга стало меньше, скиллов работы с утилитами в CLI и изученных ЯП — больше. В связи с этим не перестаю задаваться вопросом:

Так кем же в итоге я стал?

Комментарии (38)


  1. DMGarikk
    27.06.2024 15:02
    +34

    Сейчас же ситуация прямо противоположная: проще встроить готовый
    инструмент/библиотеку и уже вот это всё корячить под себя, будет
    банально дешевле.

    он нас всех сдал!! теперь все узнают что мы только и делаем что обвязки для либ пишем...обработчик http подключаем к сериалайзеру, меняем два поля и через него сливаем обратно...а оно там само и tcp и роутинг и проверку форматов и поддержание сессии... а потом в отчете пишешь что потратил 100500 часов на борьбу с фрагментацией tcp и написание драйвера для оптоволокна

    Так кем же в итоге я стал?

    и кем? обычным программистом и стал с более расширенным кругозором


    1. Vanovsky714 Автор
      27.06.2024 15:02
      +9

      чёрт, получается, и себя сдал.....

      да, с вами не поспоришь)))


  1. muxa_ru
    27.06.2024 15:02
    +2

    приобретает новый функционал и избавляется от багов

    Типа добавляют новый функционал, без добавления новых багов?

    А так разве можно?


    1. Vanovsky714 Автор
      27.06.2024 15:02
      +1

      да, оговорочка вышла. Скорее нет, чем да)


  1. brownfox
    27.06.2024 15:02
    +5

    Так кем же в итоге я стал?

    Среднестатистическим прикладным Linux-разработчиком :)

    На самом деле, подход "используй готовое" - это именно то, что называют Unix Way, а системное администрирование и серверное программирование в юниксах почти всегда тесно связаны. Благо, юниксовые шеллы имеют богатейшие возможности по организации последовательной обработки данных и взаимодействия между процессами. Поэтому с нуля пишется то, что действительно уникально (и часто отдаётся в опенсорс, если может быть полезно другим и не стоило $1M в разработке).

    У меня история зеркальная по отношению к вашей - много лет занимался проектированием и разработкой больших корпоративных unix-систем, потом всё надоело, ушёл в стартапы, и внезапно столкнулся с программированием микроконтроллеров, открыв для себя много нового. Сейчас больше руковожу процессом и вернулся к верхнеуровневым системам, но хорошо понимаю, как должны работать устройства, которыми мы управляем, и как писать под них софт эффективно.


    1. Vanovsky714 Автор
      27.06.2024 15:02
      +3

      Наверное похожий на ваш случай я наблюдал 5 лет назад. Я тогда программировал на МК и в компанию пришел разработчик, который до этого занимался геймдевом. Для меня тогда это показалось странным, потому что органичным вроде бы кажется путь от низкоуровнего ПО к системному или прикладному для какой-нибудь ОС.

      Причем уйдя из геймдева он проработал пару лет в фирме, занимаясь Embedded Linux на BeagleBone, а затем - ушел в микроконтроллеры.

      Теперь я понимаю, что человеки видят развитие по-разному. И оказывается неважно, куда двигаться, в низкоуровневое ПО или наоборот - просто людям свойственно уходить от того, что приелось и пробовать то, что еще никогда не делал.

      P.S. Очегь рад, что вы многое подчерпнули из работы с МК


      1. brownfox
        27.06.2024 15:02
        +2

        И оказывается неважно, куда двигаться


        Главное, чтобы было ново и интересно. Ну и денежно, по возможности :)
        Тем более, что предыдущий опыт всё равно пригождается так или иначе.

        P.S. Из МК сталкивался как с чипами общего назначения (STM32, NRF52, WCH), так и специализированными (GrainMedia, HiSilicon). Нордики до сих пор нежно люблю.


  1. tuxi
    27.06.2024 15:02
    +2

    А насколько перспективна тема программирования для МК? Слышал неоднократно, что платят мало, геморра много и вакансий раз два и нету.


    1. Vanovsky714 Автор
      27.06.2024 15:02
      +2

      Да как раз нет, вакансий полно. Особенно сейчас, когда много проектов по импортозамещению и нужно переделывать софт под китайские аналоги. Или, например, сейчас распространненная тема - ПО для базовых станций, иностранных же нет, Так что вакансий много


    1. UranusExplorer
      27.06.2024 15:02
      +5

      платят мало, геморра много

      в сравнении с высокоуровневой прикладной разработкой все так.


      1. Vanovsky714 Автор
        27.06.2024 15:02
        +9

        Да, средний уровень ЗП всё-таки ниже, чем у прикладного ПО.

        По поводу геморра - от работодателя зависит. У одних (адекватных и с достатком ресурсов) ты будешь писать только софт и отлаживать с осциллографом и мультиметром в руках, т.к. для работы с железом есть схемотехники. У других - будешь многостаночником: схему нарисуй, плату разведи, сделай трассировку, напиши код, отладь в лабе, отладь у заказчика и получи за это 40 тыщ.


        1. brownfox
          27.06.2024 15:02
          +3

          Зависит от компании. У нас схемотехники отдельно, программисты МК - отдельно, конструкторы тоже отдельные люди, платят программистам МК на том же уровне, что и высокоуровневым фуллстекам, немного выше среднерыночных денег. Потому что всё работает на результат.

          То есть, конечно, прикладники могут найти место с зарплатой повыше, но команда, интересные задачи и изобилие свободы людей удерживают.


      1. Dmitry_604
        27.06.2024 15:02
        +3

        И это выглядит странно сейчас, с учетом того, что реально спрос на такую разработку в РФ реально вырос сильно, а знаний и усидчивости, насколько знаю по знакомым, требуется не меньше.


        1. Vanovsky714 Автор
          27.06.2024 15:02
          +2

          Да, выглядит очень странно, согласен. Но могу скзазать, что на фоне ускоренного импортозамещения зарплаты в этой сфере подросли, но всё равно не настолько, чтобы тягаться с другими айти отраслями


        1. UranusExplorer
          27.06.2024 15:02
          +1

          Там скорее психология руководства, которое воспринимают программистов как просто "инженеров" и в упор не могут понять, что на рынке одни стоят дороже чем другие.


          1. muxa_ru
            27.06.2024 15:02

            А инженеры ничем не отличаются и стоят все одинаково?

            А токари?

            А строители?


            1. UranusExplorer
              27.06.2024 15:02
              +1

              Это вы уже не мне вопросы задавайте, а тем кто жалуется "да за что этим программистам столько платить, перебьются!" (это то что своими ушами слышал, к счастью сбежал оттуда и сменил предметную область)


              1. muxa_ru
                27.06.2024 15:02

                Ну так это Вы написали

                воспринимают программистов как просто "инженеров" и в упор не могут понять, что на рынке одни стоят дороже чем другие

                А инженеры они на рынке все стоят одинаково?


                1. UranusExplorer
                  27.06.2024 15:02
                  +1

                  Да, инженеры тоже могут стоить по-разному, но причем здесь это? Вам хочется до слов докапываться, или вы что-то не поняли в написанном и надо прояснить? Речь о том, что многие руководители научных и производственных предприятий не могут понять, почему вдруг в той или иной локации среднерыночные з/п программистов могут быть в полтора-два-три раза больше чем у инженеров тех видов, что обитают у них в организации (если речь про производство оборудование или автоматизацию, обычно это электроники/конструктора/проектировщики/метрологи/наладчики), с сопоставимым опытом/квалифицией. И говорят что 'у меня иженеры по пятьдесят тысяч получают, с чего это вдруг я этим сто пятьдесят буду платить?! совсем охренели!". Что и приводит к той проблеме, о которой говорят здесь в комментариях. Почему они так считают - спрашивайте у них, а не у меня.


    1. gorod0k
      27.06.2024 15:02
      +2

      Подтверждаю. Начинал с МК. Немного занимался разработкой под большие сигнальные процессоры и ПЛИС. Сама по себе область очень интересная, но зарплаты ниже "средне-программистских", удаленка проблематична (зависит от сложности оборудования, но даже осциллограф домой притащить и паяльную станцию - уже неудобно получается).

      В профессиональном плане жалею, что в свое время не занялся веб-разработкой профессионально, сейчас вот переучиваюсь


      1. Vanovsky714 Автор
        27.06.2024 15:02

        У меня как-то были планы с МК перейти на программирование DSP-процессоров. Мой наставник на той работе мне много чего показывал, как там можно оптимизировать. Это вот самое низкоуровневое программирование ever. Чисто на ассемблере. Но, к сожалению, вопрос зарплаты порешал.


  1. Faxfox
    27.06.2024 15:02
    +1

    Есть бизнес, есть задачи бизнеса. Вы человек который решает задачи бизнеса, который с вашей помощью работает и зарабатывает.


  1. jidckii
    27.06.2024 15:02

    ПрограмТрансПереход


  1. SabMakc
    27.06.2024 15:02
    +3

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

    А на небольших проектах - и 1000 строк в день - далеко не предел. Особенно пока молодой и руки работают вперед головы )))


    1. Dmitry_604
      27.06.2024 15:02
      +2

      Вот именно что руки вперед, только со временем большая часть такого кода будет переписана или выкинута.


      1. Vanovsky714 Автор
        27.06.2024 15:02
        +2

        Мне кажется, в этом нет ничего страшного. Это нормальная практика


      1. urvanov
        27.06.2024 15:02
        +1

        Это во всех проектах так. Даже в больших


  1. saboteur_kiev
    27.06.2024 15:02
    +1

    Раньше делая какую‑то автоматизацию, я пытался в bash , но потом бросил эту затею, так как в пайтоне реально удобнее

    При хорошем владении обоими языками, не делаешь вывод что в пайтоне реально удобнее в автоматизацию. Есть вещи, которые проще и удобнее в баш, есть вещи, которые проще и удобнее в пайтоне. Есть даже что-то проще в перл, или реально накидать на Си или даже JS. Выбираешь под задачу, а при правильной формулировке. чатгпт помогает вместо чтения хелпа, посмотреть готовый пример под твои нужды.


    1. CrazyElf
      27.06.2024 15:02
      +1

      Всё так. Просто Питон мега-универсальный язык с тучей библиотек, поэтому если не хочется учить разные языки, то достаточно выучить Питон почти для любых задач. Ну, кроме мега-интерфейсных каких-то.


      1. brownfox
        27.06.2024 15:02
        +5

        Кроме задач, где критична производительность. Я в 2022 вынужден был переписать питоновскую миддлварь на плюсы, количество обрабатываемых событий в секунду скакануло почти на порядок. Но для прототипирования и некритичных по ресурсам задач питон действительно хорош.

        Хотя... многие программисты думают, что отлично знают этот язык, но штуки вроде asyncio или numpy вводят их в ступор :)))


        1. Vanovsky714 Автор
          27.06.2024 15:02
          +1

          На моей практике встречалось (уже не в Embedded, конечно), что на питоне подготавливался MVP какого-нибудь модуля/проекта/утилиты, и уже после проверки, он переделывался, например, на тот же Си (если это было необходимо)


          1. CrazyElf
            27.06.2024 15:02
            +3

            Ну, это правильно. R&D на Питоне гораздо проще/быстрее делать. Можно и MVP потом запилить, инструментов для лёгкого поднятия сервисов, дашбордов и прочего полно сейчас. А дальше да, нужно смотреть, есть ли смысл переписывать на "серьёзный" язык.


        1. svpcom
          27.06.2024 15:02
          +2

          Это они еще про Twisted не слышали :-)


        1. CrazyElf
          27.06.2024 15:02
          +1

          Ну, смотря какие задачи опять же. Если ML, то там Питон может просто вызывать разные модули, написанные на C++ и переписывать вообще всё на C++ смысла никакого нет, если основная работа идёт внутри этих уже оптимизированных модулей. А если речь про обслуживание веб-запросов, то понятно, что там лучше на Golang бэк написать. Я ж и говорю, Питон - язык широкого профиля. Для конкретных узких применений всегда найдётся специализированный на этом язык.
          P.S. На ML/DevOps позицию питониста обязательно спросят про Numpy, а веб-разработчика - про asyncio, это уж наверняка.


          1. brownfox
            27.06.2024 15:02
            +1

            Питон - язык широкого профиля. Для конкретных узких применений всегда найдётся специализированный на этом язык.

            Агитировать меня за python немного бессмысленно, я с удовольствием пользуюсь им с версии 1.5 и 1997 года :)

            Python - очень удачный "swiss army knife" c невысоким порогом вхождения и компромиссной производительностью для большинства задач. Вместе с тем, С++ - тоже язык достаточно универсальный, учитывая то, что большая часть "специализированных языков" написано на нём.

            В питоновском ML, насколько я знаю, и так большая часть функциональности реализована в виде быстрых библиотек на C/C++, поэтому вопросов с производительностью не возникает, по крайней мере там, где мы не касаемся GIL и реальной многопоточности.

            В нашей истории проблема с производительностью middleware вылезла, когда прототип на питоне впервые развернули как систему на 70+ объектов заказчика и она стала давать критичные задержки. Поэтому мы с коллегой ураганно писали боевую уже версию на плюсах. Но питоновский прототип позволил сделать это максимально быстро.

            > На ML/DevOps позицию питониста обязательно спросят про Numpy,
            > а веб-разработчика - про asyncio, это уж наверняка.

            P.S. Я два года назад несколько месяцев искал плюсоида со знанием python-а на уровне asyncio или питониста со знанием С++, STL и буста. Собеседования были эпично грустны...


            1. Vanovsky714 Автор
              27.06.2024 15:02
              +1

              искал плюсоида со знанием python-а на уровне asyncio или питониста со знанием С++, STL и буста. 

              Ну вы искали прям монстра кмк))) понятно, почему всё было грустно


              1. brownfox
                27.06.2024 15:02
                +1

                Ну, задача была разобраться в питоновском коде и переписать на плюсы. Питоновский код на asyncio, плосовый получился на связке restbed-redis. Нашёл двоих из 40, наверное. С одним договорился. Парень, кстати, без профильного высшего, но с правильной думалкой.

                Типовой разговор на собеседовании был именно на тему "уметь разобраться в неведомом". Вы знаете redis? Нет? Отлично! Вот вам задачка и неделя срока, сделаете на плюсах и на питоне :)))

                Вообще, IMHO, в команде R&D лучше иметь разносторонних универсалов, знающих 3-5 языков на среднем уровне (у меня их в запасе около 20, недавно считал), чем глубоких узких спецов, убивших 5 лет на изучение одного фреймворка. Фреймворк может смениться, а общие знания позволят изучить новое в короткий срок.


                1. Vanovsky714 Автор
                  27.06.2024 15:02

                  Круто, буду знать) надо бы ещё поднатаскаться в паре-тройке языков

                  Вообще да, не стоит ограничивать себя только одним инструментом