Наверное, есть те хабровчане, которые читали статью про то, как не надо входить в хату, в которой я делился своим опытом смены профиля в разработке. Конкретнее с разработки под МК на Embedded Linux. Вкратце: опыт довольно болезненный и всё-таки полезный при условии, если учишься на совершенных ошибках.
Практически 6 лет моего опыта — это разработка на Си под микроконтроллеры, причем разные:
это всякие AVR, STM и т. д., под которые есть много кодовой базы и материалов
какие‑нибудь SOC от Texas Instruments, по которым есть инфа только на закрытых форумах, доки (с пробелами и неточностями) и примеры драйверов, из которых можно подчерпнуть много полезного.
Ну и Embedded Linux, куда же без него. И вот тогда мне казалось, что я пишу мало кода. Как же я ошибался...
В моей практике Embedded Linux оказался переходным звеном из мира низкоуровневой разработки в мир прикладного ПО и уже на этом промежуточном этапе было сильно меньше написания кода, в основном изучение драйверов, переделка уже имеющихся. Вспоминая времена разработки под МК, удивляюсь тому огромному количеству моего кода, которое отгружалось в проекты.
Если говорить уже о прикладном - тут ситуация стала еще "круче" в нескольких аспектах.
Во-первых, как вы могли догадаться, программирования стало еще меньше. Да, это всё легаси, которое постоянно улучшается, приобретает новый функционал и избавляется от багов. И программировать там особо не надо, но при этом развивать другие навыки, которые...
Во-вторых, ... связаны не с языком программирования, а (барабанная дробь) с системным администрированием! Да, один из продуктов компании - это собственно набор утилит, помогающий администрировать записи пользователей малого/среднего/крупного бизнеса. Ясен пень, что нужно уметь этим софтом пользоваться, чтобы понимать его работу. Конечно, раньше я мечтал о том, чтобы влиться в Linux-разработку, ориентироваться в командной строке, как рыба в воде, писать утилиты, но что бы настолько... Да, я в Linux-разработке, да, привык к интерфейсу командной строки, но количество написанных строк кода почему-то какое-то мизерное.
Как говорится в одном известном меме:
Ну и напоследок, навыки отладки пачки одновременно работающих утилит. Например твой сервис отправляет сокеты в один, который обменивается данными с контроллером домена и толкает другой, что-то кладущий в свою БД и общающийся с клиентом на другой машине. Чтобы это всё анализировать помимо обычных логов же используется много чего: и GDB, и Perf, и какой-нибудь tcpdump и много чего еще интересного. Забавная была трансформация от состояния "а куда вообще тут смотреть?" до "ща запущу нужные утилиты, и буду смотреть что от куда вытекает и куда перетекает". Менять привычки, конечно, сложно, особенно в отладке: раньше тебе хватало только логов и осциллографа, не то что сейчас :)
В текущей ситуации состоялась одна из моих самых важных трансформаций: не надо брезговать пользоваться готовыми решениями. Раньше профдеформация говорила мне: камон, ты же практически всё пишешь с нуля, давай с нуля и вот это вот напишем. И в целом она была недалека от реального положения дел. Ты завязан только на своём коде, и что‑то в него встраивать извне себе дороже. Сейчас же ситуация прямо противоположная: проще встроить готовый инструмент/библиотеку и уже вот это всё корячить под себя, будет банально дешевле.
А да, еще одна трансформация — это отношение к Python: если раньше я как‑то с высока на него смотрел, типа фу‑фу‑фу, питонисты — не тру программисты, то сейчас: «М‑м-м, какой удобный язык: и тестики на pytest'е как легко пишутся и автоматизация процессов, блин, как удобно. И как же я раньше жил без него?...». Раньше делая какую‑то автоматизацию, я пытался в bash , но потом бросил эту затею, так как в пайтоне реально удобнее. Иными словами, в голове надежно закрепилось понимание, что у каждого ЯП свои задачи и относиться к этому надо соответствующе.
В общем, кодинга стало меньше, скиллов работы с утилитами в CLI и изученных ЯП — больше. В связи с этим не перестаю задаваться вопросом:
Так кем же в итоге я стал?
Комментарии (38)
muxa_ru
27.06.2024 15:02+2приобретает новый функционал и избавляется от багов
Типа добавляют новый функционал, без добавления новых багов?
А так разве можно?
brownfox
27.06.2024 15:02+5Так кем же в итоге я стал?
Среднестатистическим прикладным Linux-разработчиком :)
На самом деле, подход "используй готовое" - это именно то, что называют Unix Way, а системное администрирование и серверное программирование в юниксах почти всегда тесно связаны. Благо, юниксовые шеллы имеют богатейшие возможности по организации последовательной обработки данных и взаимодействия между процессами. Поэтому с нуля пишется то, что действительно уникально (и часто отдаётся в опенсорс, если может быть полезно другим и не стоило $1M в разработке).
У меня история зеркальная по отношению к вашей - много лет занимался проектированием и разработкой больших корпоративных unix-систем, потом всё надоело, ушёл в стартапы, и внезапно столкнулся с программированием микроконтроллеров, открыв для себя много нового. Сейчас больше руковожу процессом и вернулся к верхнеуровневым системам, но хорошо понимаю, как должны работать устройства, которыми мы управляем, и как писать под них софт эффективно.
Vanovsky714 Автор
27.06.2024 15:02+3Наверное похожий на ваш случай я наблюдал 5 лет назад. Я тогда программировал на МК и в компанию пришел разработчик, который до этого занимался геймдевом. Для меня тогда это показалось странным, потому что органичным вроде бы кажется путь от низкоуровнего ПО к системному или прикладному для какой-нибудь ОС.
Причем уйдя из геймдева он проработал пару лет в фирме, занимаясь Embedded Linux на BeagleBone, а затем - ушел в микроконтроллеры.
Теперь я понимаю, что человеки видят развитие по-разному. И оказывается неважно, куда двигаться, в низкоуровневое ПО или наоборот - просто людям свойственно уходить от того, что приелось и пробовать то, что еще никогда не делал.
P.S. Очегь рад, что вы многое подчерпнули из работы с МКbrownfox
27.06.2024 15:02+2И оказывается неважно, куда двигаться
Главное, чтобы было ново и интересно. Ну и денежно, по возможности :)
Тем более, что предыдущий опыт всё равно пригождается так или иначе.
P.S. Из МК сталкивался как с чипами общего назначения (STM32, NRF52, WCH), так и специализированными (GrainMedia, HiSilicon). Нордики до сих пор нежно люблю.
tuxi
27.06.2024 15:02+2А насколько перспективна тема программирования для МК? Слышал неоднократно, что платят мало, геморра много и вакансий раз два и нету.
Vanovsky714 Автор
27.06.2024 15:02+2Да как раз нет, вакансий полно. Особенно сейчас, когда много проектов по импортозамещению и нужно переделывать софт под китайские аналоги. Или, например, сейчас распространненная тема - ПО для базовых станций, иностранных же нет, Так что вакансий много
UranusExplorer
27.06.2024 15:02+5платят мало, геморра много
в сравнении с высокоуровневой прикладной разработкой все так.
Vanovsky714 Автор
27.06.2024 15:02+9Да, средний уровень ЗП всё-таки ниже, чем у прикладного ПО.
По поводу геморра - от работодателя зависит. У одних (адекватных и с достатком ресурсов) ты будешь писать только софт и отлаживать с осциллографом и мультиметром в руках, т.к. для работы с железом есть схемотехники. У других - будешь многостаночником: схему нарисуй, плату разведи, сделай трассировку, напиши код, отладь в лабе, отладь у заказчика и получи за это 40 тыщ.
brownfox
27.06.2024 15:02+3Зависит от компании. У нас схемотехники отдельно, программисты МК - отдельно, конструкторы тоже отдельные люди, платят программистам МК на том же уровне, что и высокоуровневым фуллстекам, немного выше среднерыночных денег. Потому что всё работает на результат.
То есть, конечно, прикладники могут найти место с зарплатой повыше, но команда, интересные задачи и изобилие свободы людей удерживают.
Dmitry_604
27.06.2024 15:02+3И это выглядит странно сейчас, с учетом того, что реально спрос на такую разработку в РФ реально вырос сильно, а знаний и усидчивости, насколько знаю по знакомым, требуется не меньше.
Vanovsky714 Автор
27.06.2024 15:02+2Да, выглядит очень странно, согласен. Но могу скзазать, что на фоне ускоренного импортозамещения зарплаты в этой сфере подросли, но всё равно не настолько, чтобы тягаться с другими айти отраслями
UranusExplorer
27.06.2024 15:02+1Там скорее психология руководства, которое воспринимают программистов как просто "инженеров" и в упор не могут понять, что на рынке одни стоят дороже чем другие.
muxa_ru
27.06.2024 15:02А инженеры ничем не отличаются и стоят все одинаково?
А токари?
А строители?
UranusExplorer
27.06.2024 15:02+1Это вы уже не мне вопросы задавайте, а тем кто жалуется "да за что этим программистам столько платить, перебьются!" (это то что своими ушами слышал, к счастью сбежал оттуда и сменил предметную область)
muxa_ru
27.06.2024 15:02Ну так это Вы написали
воспринимают программистов как просто "инженеров" и в упор не могут понять, что на рынке одни стоят дороже чем другие
А инженеры они на рынке все стоят одинаково?
UranusExplorer
27.06.2024 15:02+1Да, инженеры тоже могут стоить по-разному, но причем здесь это? Вам хочется до слов докапываться, или вы что-то не поняли в написанном и надо прояснить? Речь о том, что многие руководители научных и производственных предприятий не могут понять, почему вдруг в той или иной локации среднерыночные з/п программистов могут быть в полтора-два-три раза больше чем у инженеров тех видов, что обитают у них в организации (если речь про производство оборудование или автоматизацию, обычно это электроники/конструктора/проектировщики/метрологи/наладчики), с сопоставимым опытом/квалифицией. И говорят что 'у меня иженеры по пятьдесят тысяч получают, с чего это вдруг я этим сто пятьдесят буду платить?! совсем охренели!". Что и приводит к той проблеме, о которой говорят здесь в комментариях. Почему они так считают - спрашивайте у них, а не у меня.
gorod0k
27.06.2024 15:02+2Подтверждаю. Начинал с МК. Немного занимался разработкой под большие сигнальные процессоры и ПЛИС. Сама по себе область очень интересная, но зарплаты ниже "средне-программистских", удаленка проблематична (зависит от сложности оборудования, но даже осциллограф домой притащить и паяльную станцию - уже неудобно получается).
В профессиональном плане жалею, что в свое время не занялся веб-разработкой профессионально, сейчас вот переучиваюсь
Vanovsky714 Автор
27.06.2024 15:02У меня как-то были планы с МК перейти на программирование DSP-процессоров. Мой наставник на той работе мне много чего показывал, как там можно оптимизировать. Это вот самое низкоуровневое программирование ever. Чисто на ассемблере. Но, к сожалению, вопрос зарплаты порешал.
Faxfox
27.06.2024 15:02+1Есть бизнес, есть задачи бизнеса. Вы человек который решает задачи бизнеса, который с вашей помощью работает и зарабатывает.
SabMakc
27.06.2024 15:02+3Разница обусловлена не областью действия, а размерами проектов.
Чем больше проект - тем меньше пишется кода и тем больше изучается/дебажится существующего кода.А на небольших проектах - и 1000 строк в день - далеко не предел. Особенно пока молодой и руки работают вперед головы )))
Dmitry_604
27.06.2024 15:02+2Вот именно что руки вперед, только со временем большая часть такого кода будет переписана или выкинута.
Vanovsky714 Автор
27.06.2024 15:02+2Мне кажется, в этом нет ничего страшного. Это нормальная практика
saboteur_kiev
27.06.2024 15:02+1Раньше делая какую‑то автоматизацию, я пытался в
bash, но потом бросил эту затею, так как в пайтоне реально удобнееПри хорошем владении обоими языками, не делаешь вывод что в пайтоне реально удобнее в автоматизацию. Есть вещи, которые проще и удобнее в баш, есть вещи, которые проще и удобнее в пайтоне. Есть даже что-то проще в перл, или реально накидать на Си или даже JS. Выбираешь под задачу, а при правильной формулировке. чатгпт помогает вместо чтения хелпа, посмотреть готовый пример под твои нужды.
CrazyElf
27.06.2024 15:02+1Всё так. Просто Питон мега-универсальный язык с тучей библиотек, поэтому если не хочется учить разные языки, то достаточно выучить Питон почти для любых задач. Ну, кроме мега-интерфейсных каких-то.
brownfox
27.06.2024 15:02+5Кроме задач, где критична производительность. Я в 2022 вынужден был переписать питоновскую миддлварь на плюсы, количество обрабатываемых событий в секунду скакануло почти на порядок. Но для прототипирования и некритичных по ресурсам задач питон действительно хорош.
Хотя... многие программисты думают, что отлично знают этот язык, но штуки вроде asyncio или numpy вводят их в ступор :)))Vanovsky714 Автор
27.06.2024 15:02+1На моей практике встречалось (уже не в Embedded, конечно), что на питоне подготавливался MVP какого-нибудь модуля/проекта/утилиты, и уже после проверки, он переделывался, например, на тот же Си (если это было необходимо)
CrazyElf
27.06.2024 15:02+3Ну, это правильно. R&D на Питоне гораздо проще/быстрее делать. Можно и MVP потом запилить, инструментов для лёгкого поднятия сервисов, дашбордов и прочего полно сейчас. А дальше да, нужно смотреть, есть ли смысл переписывать на "серьёзный" язык.
CrazyElf
27.06.2024 15:02+1Ну, смотря какие задачи опять же. Если ML, то там Питон может просто вызывать разные модули, написанные на
C++и переписывать вообще всё наC++смысла никакого нет, если основная работа идёт внутри этих уже оптимизированных модулей. А если речь про обслуживание веб-запросов, то понятно, что там лучше наGolangбэк написать. Я ж и говорю, Питон - язык широкого профиля. Для конкретных узких применений всегда найдётся специализированный на этом язык.
P.S. На ML/DevOps позицию питониста обязательно спросят проNumpy, а веб-разработчика - проasyncio, это уж наверняка.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 и буста. Собеседования были эпично грустны...
Vanovsky714 Автор
27.06.2024 15:02+1искал плюсоида со знанием python-а на уровне asyncio или питониста со знанием С++, STL и буста.
Ну вы искали прям монстра кмк))) понятно, почему всё было грустно
brownfox
27.06.2024 15:02+1Ну, задача была разобраться в питоновском коде и переписать на плюсы. Питоновский код на asyncio, плосовый получился на связке restbed-redis. Нашёл двоих из 40, наверное. С одним договорился. Парень, кстати, без профильного высшего, но с правильной думалкой.
Типовой разговор на собеседовании был именно на тему "уметь разобраться в неведомом". Вы знаете redis? Нет? Отлично! Вот вам задачка и неделя срока, сделаете на плюсах и на питоне :)))
Вообще, IMHO, в команде R&D лучше иметь разносторонних универсалов, знающих 3-5 языков на среднем уровне (у меня их в запасе около 20, недавно считал), чем глубоких узких спецов, убивших 5 лет на изучение одного фреймворка. Фреймворк может смениться, а общие знания позволят изучить новое в короткий срок.Vanovsky714 Автор
27.06.2024 15:02Круто, буду знать) надо бы ещё поднатаскаться в паре-тройке языков
Вообще да, не стоит ограничивать себя только одним инструментом
DMGarikk
он нас всех сдал!! теперь все узнают что мы только и делаем что обвязки для либ пишем...обработчик http подключаем к сериалайзеру, меняем два поля и через него сливаем обратно...а оно там само и tcp и роутинг и проверку форматов и поддержание сессии... а потом в отчете пишешь что потратил 100500 часов на борьбу с фрагментацией tcp и написание драйвера для оптоволокна
и кем? обычным программистом и стал с более расширенным кругозором
Vanovsky714 Автор
чёрт, получается, и себя сдал.....
да, с вами не поспоришь)))